This happens automatically in renderers with a texture tile cache. Which is basically all of them other than Cycles, something I’ve been complaining about for probably 5-7 years at this point. With a tilecache you split the texture into mipmaps, with individual chunks per mipmap(usually 64px) and load only the sections of the map that are being used, at only the largest mipmap level that is actually needed. This optimizes memory usage of all of the following cases:
Texture is simply higher res than it needs to be
Full texture resolution is only needed in part of the map
There are meaningfully large blank spaces in the UV map (“meaningfully large” meaning the size of a single tile at the needed mipmap; if a tile contains no UVs it will never be loaded)
Texture is actually just a solid color and could be reduced to 1px (optional, checked when building the cache)
Note that 2 and 3 are impossible to optimize with any sort of user-controlled “max size” option.
The Cycles devs continue to not bother with this, it’s literally been on a “would be nice to have” list since 2014 or so. I’m not aware of any other remotely serious production renderer that lacks this feature.
Yes, such a tile texture downscaling sounds amazing.
However, I just create a feature suggestion on right-click-select about my original idea, about setting a manual downscaling per material:
After it’s already technically there (only globally), it’s maybe a low hanging fruite to implement.
I think it’s fare more realstic that we are getting this feature, than the tiling downscaling, in the next time.
So, maybe you want to upvote my suggestion
Overall from this conversation, it seems to me like the best approach with Cycles is to have actual geometry. Sounds like poly-count doesn’t scare Cycles nearly as much as render-time subdivision.
As I mentioned above, I feel that revisiting how Cycles handles render-time subdivision is long overdue and would be a nice catch-up to how other render engines handle things.
The “elephant” demo scene (mouse sitting in front of fireplace) can’t be rendered on any of my 3 laptops in Cycles because 1 background vase has too many polygons. It renders fine in eevee.
Raw polygon count does not have much impact on Cycles in terms of rendering speed. 10 million polygons for instance will see samples put onto the screen at the same rate as 10,000 polygons (with the only wildcard being any added complexity in the shading or the lighting).
In fact, the only way you would have your speed docked is if Cycles gained the ability to cache geometry and textures in cases where you do not have enough RAM (and then you rendered scenes that can’t completely fit in RAM).
MNEE is continuing to see limitations removed (at least for the initial purpose of shadow caustics). rBdc55e095e6f2 (blender.org)
In short, to get caustics from things like glass balls no longer requires filter glossy to be above 0 (but having the value set is still recommended for accuracy as the example image shows).
I hadn’t bothered with filter glossy whilst testing, but now you mention it.
No filter
Filter 0.0001
And the difference is clear. I tested .0001, .001, .01, .1, 1.0, and 10. There is no discernible difference in the caustics with any value above 0. But 0 and any value above there is.
I don’t see a difference with a sphere though (though much prettier than without shadow caustics)
Does anyone know when ACES will be included in an accessible (non-Compositor) way, such as in Color Management ➔ View Transform, as an alternative to Filmic, or maybe a Filmic upgrade that uses ACES?
The latest Octane update already offers ACES without the need to set it up separately.
My hunch it’ll be done for the LTS version. Which is it 3.3, 3.4? Don’t remember the exact release cycle.
As far as I’ve seen most of the work is already done in that direction. The most important part is to make Blender fully color agnostic and fully support OCIO v2. Which is happening as far as I understand. Then it doesn’t matter which color workflow you want to use: Filmic, ACES or whatever else.
But ACES is going to be packaged with Blender, I believe.
I don’t think it should take that much longer to finish implementing OCIO and ACES support. All signs are there that BI is working in that direction. The announcement of highly realistic video short. Cycles rewrite. ACES and OCIO patches were worked on more actively in the past couple months. Brecht encourage Cycles Spectral renderer devs to start pushing patches to merge these branches eventually. I see lots of things are aligning in this direction.
If they miss next LTS window release with these features still absent it’ll be a really bad situation where they miss a big opportunity to turn even more industry heads to the Blender. So I think they’ll do all they can for this to happen.
Full ACES support may not be the only thing related to color that may go in.
Eary’s patch may actually bring a transform that is better than ACES for those who don’t need to integrate CG work into film. This is essentially what Troy_S initially wanted Filmic to be, but the community was not ready as concepts like albedo were not well understood.
It’s really not about color transforms. It’s about making sure Blender doesn’t have anything hard coded color regarding color pipeline and supporting OCIO v2. Once it’s done you can use any color config you prefer. Having ACES or Troy’s new transform packaged is just a plus. But if it wasn’t you’d just have to download it yourself and point to a new config in the settings.
In the end everyone benefit from OCIO support by Blender.
It’s expected to see Filmic doesn’t work with wide gamut. But seeing ACES also doesn’t work with wide gamut should make you having some second thought about your assumption of ACES being “better”.
And here is the wide gamut EXR encoded in CIE XYZ D65:
Yes you don’t need the ACES 2065-1 colorspace for wide gamut file exchange.
