Limit detail for procedural textures
It seems like this has a different cause then what I thought, please look at the comments for that!
When you create node trees with a lot of procedural textures the viewport (only for Eevee) gets quite slow. Because of the fact that this changes depending on how far you are zoomed in on the object, I'm assuming this is the case because more detail is being generated the further you zoom in.
In this exaturated example you can see that it does seem to depend on your zoom level:
The proposal is to have a new option under the simplify panel which would allow you to limit the detail generated based on your zoom level. This would mainly be needed for Eevee because cycles doesn't seem to have any issues with this. The UI could look like this:
This option would then control when the clipping starts. If this value was zero no clipping would happen. The distance should behave the same way it already does with the camera clipping.
When the clipping does start, it remains at the last level of detail that was generated.
I do not know for sure that the detail of these textures is generated that way, this is just what I'm assuming it works like based on the way it behaves. If it functions differently I'd be happy to update this proposal to take that into account.
6 Comments
More visible pixels means more calculations. In EEVEE, the pixel drawing is the slowest, in Cycles, the geometry/ray processing is the slowest - not the pixel drawing. So, when you zoom in on the object, it gets bigger on screen, so you get more pixels to draw... thus slower in EEVEE, not so much in Cycles. You may verify this by making a large grid of objects to fill the screen whether zoomed in or out. Still an issue? Then indeed EEVEE could benefit from ad-hoc texture-baking. Please check.
* @Ivo * Pretty much this. Shaders are run per-pixel, so it's not 'generating more detail' when you zoom in, it's just processing more pixels.
"ad-hoc texture-baking" sounds super complicated for very little gain though. Far more reliable to just buy a better GPU or simplify your shader manually.
What I'd suggest instead is to implement the viewport pixel doubling feature for Eevee like it works for Cycles.
* @Piotr Adamowicz * Good to know, sounds like that would be the best idea then.
In regards to this issue something like a debug mode could help. This would work by showing the memory usage on each node so you could better identify where to optimize your materials.
All for any realtime optimizations. Eevee can take a few lessons from game engine rendering tech. LOD's, texture resampling, resolution caps, culling, and more. Including this idea.
Yes ! With the Car Paint from Extreme PBR, viewport gets slow if you are too close to the object, making editing really difficult. Definately needed !