Chris Dee Wrote:I agree, tools should be able to tell what a sub-folder represents. We could either add fixed name configuration file localised to each folder, so long as it does not have a .dat extension or (my preference) add a single file in the ldraw root folder. Does anyone know if any of the tools would whinge if they found a file with an extension that is not .dat in an ldraw folder?
I'm not (yet) convinced of the need for LOD folders for parts, but the inclusion of parts/s/ and parts/textures (when that is implemented in the official library) would allow that.
Hi Chris,
My thoughts were similar to Santeri's: a single list of LOD sub-folders in a top level file, similar to the color config file.
Re: the need for parts, the burden is on me to prove it. I have only run real numbers tests on octastuds so far (and it was the easiest test to do since the parts existed already).
Let me see what it would take for me to get real numbers for the difference between simply going "studless" and starting to remove pieces of part structure. (This is where we would need to sub-folder the parts themselves).
Two data points are pushing me toward this test:
1. My 60k part test is still stuck at 6.6 fps on not-amazing-but-not-unreasonable hardware, and it is hard limited by vertex count. So to get smooth scrolling/rotating we need at least another 50% reduction in vertex count. (And that would still be 15 fps scrolling - not the smooth 30 fps we'd like.)
2. 60k parts isn't a lot of parts. Alice Finch's hogwarts is apparently about 400,000 bricks - that is, 6x more parts than my biggest test case so far.
So not only is our current vertex perhaps 2.5x too big to be realtime, our test cases are 6x smaller than what real-world builders are making. My goal is to allow BrickSmith to edit this kind of huge model in real time... so I'm looking for a 15x reduction in vertex count. :-) I think for this we need to start cutting muscle and not just fat, metaphorically speaking - we need to be able to _temporarily_ drop significant geometry like brick interiors.*
I imagine having four levels of detail:
high - corresponds to using the /48 studs.
default - what we have now
low - corresponds to using the /8 studs.
draft - no studs, no tubes, maybe interiors missing.
An app could render at low, default or high depending on zoom level, but then when the user goes to spin the model, temporarily use draft rendering to keep the UI responsive.
Anyway, I'll post some numbers when I get them. :-)
Cheers
Ben