Level of Detail for Parts
2013-03-04, 2:54 (This post was last modified: 2013-03-08, 9:53 by Chris Dee.)
2013-03-04, 2:54 (This post was last modified: 2013-03-08, 9:53 by Chris Dee.)
Hi Y'all,
I hit a bottleneck in my performance optimization work with BrickSmith: LDraw parts have no concept of "level of detail."
If I open Datsville, I'm staring at 125,000,000 vertices. They aren't all necessary when drawing the entire model in an 800 x 600 window, but there isn't any meta-data to help me drop some of them.
This is half of the level-of-detail problem: for very low-resolution rendering of huge models, the parts are too detailed, burning GPU power. The flip side of this is that close up, the studs look like prisms and not cylinders because of the low vertex count.
This got me thinking: if parts (or sub-parts) had a level-of-detail scheme (with multiple versions of the parts for different resolutions) we could have our cake and eat it: for wide views a stud could be a cube or some other super-crude, super-cheap structure. At high res we could crank the vertex count, eliminating the need for viewers to do ad-hoc sub-part substitution.
Here's the question I have: how could/should a renderer decide _which_ level of detail to draw? I can think of a few heuristics:
- The levels of detail are arbitrary; the client program picks one based on current performance and context. In other words, when you say "export PNG" the highest level is always used. During rendering, the program steps down LOD one notch any time the framerate drops below 10 fps and cranks it up one notch any time it exceeds 30 fps.
- Levels of detail are based on scale. In other words, each level of detail specifies a range of pixels that an LDU covers. If the rendering scale is such that an LDU is less than "X" pixels, we go to the next LOD.
- (If LODs are based on scale, then we have to ask whether the cut-over points should be arbitrary or specified in the spec or library standards. There's a big technical win for programs if there aren't a million different cut-over points.)
Are the LODs advisory or required in their cut-over points (for programs that understand LOD)? Thoughts?
My hope with LOD is that with a little bit of work on a very small number of sub-parts, we could make a big difference. For examlpe, just by creating an octagon low-LOD stud, we could cut 90,112 vertices from every 32x32 baseplate - there are only 3 sub-parts that would need modification in this case. I think the strong factoring of the part library could be a big win here.
Cheers
Ben
I hit a bottleneck in my performance optimization work with BrickSmith: LDraw parts have no concept of "level of detail."
If I open Datsville, I'm staring at 125,000,000 vertices. They aren't all necessary when drawing the entire model in an 800 x 600 window, but there isn't any meta-data to help me drop some of them.
This is half of the level-of-detail problem: for very low-resolution rendering of huge models, the parts are too detailed, burning GPU power. The flip side of this is that close up, the studs look like prisms and not cylinders because of the low vertex count.
This got me thinking: if parts (or sub-parts) had a level-of-detail scheme (with multiple versions of the parts for different resolutions) we could have our cake and eat it: for wide views a stud could be a cube or some other super-crude, super-cheap structure. At high res we could crank the vertex count, eliminating the need for viewers to do ad-hoc sub-part substitution.
Here's the question I have: how could/should a renderer decide _which_ level of detail to draw? I can think of a few heuristics:
- The levels of detail are arbitrary; the client program picks one based on current performance and context. In other words, when you say "export PNG" the highest level is always used. During rendering, the program steps down LOD one notch any time the framerate drops below 10 fps and cranks it up one notch any time it exceeds 30 fps.
- Levels of detail are based on scale. In other words, each level of detail specifies a range of pixels that an LDU covers. If the rendering scale is such that an LDU is less than "X" pixels, we go to the next LOD.
- (If LODs are based on scale, then we have to ask whether the cut-over points should be arbitrary or specified in the spec or library standards. There's a big technical win for programs if there aren't a million different cut-over points.)
Are the LODs advisory or required in their cut-over points (for programs that understand LOD)? Thoughts?
My hope with LOD is that with a little bit of work on a very small number of sub-parts, we could make a big difference. For examlpe, just by creating an octagon low-LOD stud, we could cut 90,112 vertices from every 32x32 baseplate - there are only 3 sub-parts that would need modification in this case. I think the strong factoring of the part library could be a big win here.
Cheers
Ben