Hi Guys,
A few comments on file conventions vs. meta commands.
First: I think we can all agree that either a file naming convention or a meta-command could serve as a vehicle for primitive substitution, for the purpose of changing the level of detail of output. And while I am advocating meta commands over file naming conventions, I do believe that a directory scheme is better than hard-coding a stud -> stu2 in a file parser. :-)
Second: why I care. I believe that cutting the vertex count of large models is the major barrier to real-time preview of seriously-huge-ldraw-creations. Here are some numbers: the Datsville model that Allen sent me to do stress testing has 3960 pieces, and results in 63.6 _million_ vertices when drawn in full. This is an insane number of vertices -- it's almost 100x the number of pixels on screen, thus the vertex count is perhaps overkill by 100x and way outside the range of what GPUs are optimized for.
By substituting octa-studs for the normal ones, we cut the vertex count to 38.04 M studs a 40% improvement in vertex count that basically gives us a 40% improvement in framerate. That's huge! I ran the same scheme on a 64k part model that I built and found that it normally produces 122 million vertices (ouch) and cuts to 81 million with octa-studs - another big reduction.
So substituting meshes with lower detail is a big perf win, but even with octa-studs, we're still way vertex heavy. There has to be a way to draw an entire lego town into a 900 x 900 window without burning 38M vertices. :-)
So I think we have to be looking at additional ways to LOD substitute, e.g.
- more decimations of the stud, e.g. can we have simple quad-studs? These would look lousy but if a stud is covering 3 screen pixels, I think we'll be okay. :-) And we're cutting the stud geometry count in half again (and we saw already that studs do produce a huge amount of vertices).
- how about dropping studs entirely? We know that studs are small, so even if a 32x32 baseplate is big (10" on a side) and thus must be drawn at low zoom, the studs themselves turn to noise at some point.
I can think of other ways to cheat LOD...for example, we could drop the tubes inside bricks - this is a different kind of LOD reduction because it's not just "crude", it's actually "wrong" if viewed closely. But there's a lot of brick interior that is never seen in a huge model - when doing a real-time rotation of a large model at low zoom, we can live without these things. We could even drop the _interiors_ of bricks for a lowest-res, crudest-but-quite-fast rendering.
So my question is - if we are going to introduce a file naming scheme, how would we cope with
- a whole set of resolutions for studs.
- how would a program know what stud resolutions are available.
- if there are other decimation schemes to reduce LOD, how are they accessed?
- can the schemes be combined? E.g. can we have a brick with no studs _and_ no interiors?
My fear with the file naming convention is that when we go to expand it later, we're going to be boxed in by the limits of what can be done with file paths. And at 38 M vertices with octa-studs, I think we need to be able to go several steps further under _some_ rendering schemes.
(Consider also high-res rendering for the close-up....we'd like LOD to go both ways!)
Anyway, if we can really get that kind of flexibility out of file paths, I'm not against it. But I would like to see something that allows us to go further with LOD and doesn't require rewriting clients every time we push LOD farther.
Cheers
Ben
A few comments on file conventions vs. meta commands.
First: I think we can all agree that either a file naming convention or a meta-command could serve as a vehicle for primitive substitution, for the purpose of changing the level of detail of output. And while I am advocating meta commands over file naming conventions, I do believe that a directory scheme is better than hard-coding a stud -> stu2 in a file parser. :-)
Second: why I care. I believe that cutting the vertex count of large models is the major barrier to real-time preview of seriously-huge-ldraw-creations. Here are some numbers: the Datsville model that Allen sent me to do stress testing has 3960 pieces, and results in 63.6 _million_ vertices when drawn in full. This is an insane number of vertices -- it's almost 100x the number of pixels on screen, thus the vertex count is perhaps overkill by 100x and way outside the range of what GPUs are optimized for.
By substituting octa-studs for the normal ones, we cut the vertex count to 38.04 M studs a 40% improvement in vertex count that basically gives us a 40% improvement in framerate. That's huge! I ran the same scheme on a 64k part model that I built and found that it normally produces 122 million vertices (ouch) and cuts to 81 million with octa-studs - another big reduction.
So substituting meshes with lower detail is a big perf win, but even with octa-studs, we're still way vertex heavy. There has to be a way to draw an entire lego town into a 900 x 900 window without burning 38M vertices. :-)
So I think we have to be looking at additional ways to LOD substitute, e.g.
- more decimations of the stud, e.g. can we have simple quad-studs? These would look lousy but if a stud is covering 3 screen pixels, I think we'll be okay. :-) And we're cutting the stud geometry count in half again (and we saw already that studs do produce a huge amount of vertices).
- how about dropping studs entirely? We know that studs are small, so even if a 32x32 baseplate is big (10" on a side) and thus must be drawn at low zoom, the studs themselves turn to noise at some point.
I can think of other ways to cheat LOD...for example, we could drop the tubes inside bricks - this is a different kind of LOD reduction because it's not just "crude", it's actually "wrong" if viewed closely. But there's a lot of brick interior that is never seen in a huge model - when doing a real-time rotation of a large model at low zoom, we can live without these things. We could even drop the _interiors_ of bricks for a lowest-res, crudest-but-quite-fast rendering.
So my question is - if we are going to introduce a file naming scheme, how would we cope with
- a whole set of resolutions for studs.
- how would a program know what stud resolutions are available.
- if there are other decimation schemes to reduce LOD, how are they accessed?
- can the schemes be combined? E.g. can we have a brick with no studs _and_ no interiors?
My fear with the file naming convention is that when we go to expand it later, we're going to be boxed in by the limits of what can be done with file paths. And at 38 M vertices with octa-studs, I think we need to be able to go several steps further under _some_ rendering schemes.
(Consider also high-res rendering for the close-up....we'd like LOD to go both ways!)
Anyway, if we can really get that kind of flexibility out of file paths, I'm not against it. But I would like to see something that allows us to go further with LOD and doesn't require rewriting clients every time we push LOD farther.
Cheers
Ben