I’ve downloaded a test build of the level of detail plugin this morning on Graphicall.org. And I’ve thought it works quietly. But why the LOD doesn’t work on render, especially with cycles ?
I know, the levek of detail is presented as a BGE’s plugin, but in development time, it would be interesting to consider an other use of the level of detail, especially for big landscapes in animation. It’s a good way to improve render time in these very complex scenes.
After testing it, I can say how the LOD developed for the next version of Blender, will be very very useful for animation. So why is he restricted in the BGE, while it could be bigger than it is.
… uhm, the LOD is game engine only. You could make a case for it being minimally useful for blender internal, but for cycles it won’t matter at all, given cycles is more concerned with resolution than polycount.
You can literally render BILLIONS of polygons in Cycles (albeit using instaces) without much of a performance impact so I don’t think a LOD system would reaally make sense for Cycles.
I’ve read some articles on pixar animation, especially for cars (witch isn’t the first youth) and they use LOD for plants for example. So I thought it could be usefull for animation, because, even if the polycount doesn’t really matter in cycles, it has some impact to the render time.
I’ve made this very simple scene (25 samples, 1080p), and for a few difference, polycount doesn’t any matter, but with 6 subdivision surfaces the render time has doubled, so it still have a really impact for an animation. Because each second more in render time represent 25 seconds more for a second of movie, so for this very simple scene it represent around 3 hours more on render time for only one minute of film. So what should it do for a big landscape with fluid sim, trees, rock, particle instances?
The effect that the number of polygons in Cycles is regardless a lot smaller than what is seen in a rasterizer/raytracer hybrid like BI, throw a 2-3 million polygon Suzanne into BI and it will really bog down in terms of rendertime. In Cycles, you really don’t see that near as much because it’s a pure raytracer and it’s generally rasterization technology that struggles with the high counts.
Also, I don’t know if this is an adequate analog for what Cycles will do in an entire scene of 2 million polygons because the only reason you would need to really jack up the polygon count on small subsurfed meshes like that would be is if you’re using displacement.
That still leaves the question on if an LOD system is desired, the one thing I could see it being a clear desire for (either through levels or adaptive subsurf), is to allow complex scenes to use less memory (which the potential savings here could be pretty high if the difference between the maximum and minimum detail levels are in the millions), but another developer may first have to expand Kupoman’s LOD system for the BGE to make it work in the render engine, which isn’t as critical as getting it to work in the viewport and BGE as those systems require high performance to run smoothly.
The render time doubles because BVH building time increases. Redo your test with 100 or 200 semples. There will be just a minor difference in render time.
Pixar (at least at the time) used a rendering method that does benefit significantly from reducing geometric complexity, but this is not the case with Cycles.
I’ve made this very simple scene (25 samples, 1080p), and for a few difference, polycount doesn’t any matter, but with 6 subdivision surfaces the render time has doubled, so it still have a really impact for an animation. Because each second more in render time represent 25 seconds more for a second of movie, so for this very simple scene it represent around 3 hours more on render time for only one minute of film. So what should it do for a big landscape with fluid sim, trees, rock, particle instances?
After a certain treshold, an increase in polygons for rendering becomes almost irrelevant. In your simple test, the dominant factor was most likely building the BVH, which can potentially be cached and reused every frame. Also, in a scene with thousands of instances of trees and rocks, the BVH will only have to be built once per instance type. As it has been mentioned, using instancing you can render many billions of polygons with little overhead.
In my opinion… better have it and not use it than wish to having and not been able to have it. Do you get my point? Maybe for many project you wont need a LOD system but it would be very handy for specific scenes in case you need it.
Yeah but we also must consider the question, who will develop/implement it? If you can do it then go right ahead but I don’t think precious developer time should go towards something that would be used in less than 10% of all renders.
Basically , LOD is made by creating duplications of objects and putting a decimate modifier on it.
In BGE, camera position is not predictable. It is controlled by player of the game.
When you create an animation, motion path of camera is known. You can put decimate modifier on far objects and control ratio value by a driver related to camera position. So you can already do it.
In fact I don’t like decimate at all. But the video you shared is interesting, I’ll focus on it later (in the evening I’ve some difficulties to concentrate myself).
The LOD interested me because it allows us to use really different meshes. For example, I can make a grass mound (I hope it’s the right word) with every blade made with separate planes for HiRes, and a simple textured plane for LowRes.
