Hi Y'all,
I have some numbers from hacking today. For a test file I grabbed Datsville r369, which has 127,691 parts. In BrickSmith I did a release build and turned off all culling tricks (so I was measuring the real cost of the whole model) as well as v-sync (so I was viewing the sustained throughput of the GPU with no fps loss due to waiting for vsync to come around). My box is an old Mac Pro Xeon, so it's more or less a core 2 at 2.8 ghz with a Radeon HD 4870.
I ran the model with sustained mouse rotation to measure total throughput of the GPU (e.g. how fast you'd have animation with scrolling) with 5 versions of the part library, designed to simulate "lower LOD sets":
- Original - the part library unmodified.
- Octastuds - the part library with the p/8 directory copied into p
- Studless - Octastuds, but then with the entire contents of stud.dat, stud2*.dat, and stud6*.dat blanked out.
- Boxed - Octastuds, plus many parts in the brick, technic brick, tile, and plate categories replaced with a single box5 sub-directive with the same size as the original part.
- Boxed no lines - same as above, but with all line directives programmatically removed by Bricksmith.
Here are the #s
ORIG: 241280493 vertices, 1.71 fps
OCTA: 149097204 (38%), 2.72 fps
STUDLESS: 89809425 (62%) 4.28 fps
BOXED: 58574196 (75%) 6.65 fps
BOXED, NO LINES: 41683162 (82%) 9.04 fps
A few notes:
- the boxed version uses 75% CPU, boxed no lines uses 100% of CPU - in other words, only by cutting the vertex count down by 75-82% did the GPU unloaded enough for CPU speed to matter.
- while the original is pretty unusable, the boxed no line version, at 9 fps on older hw is pretty tolerable.
- real numbers would have been better - the model is so zoomed out that bricksmith can opportunistically not draw tiny parts if allowed. But clearly there's a big fps win here, almost entirely proportional to vertex count.
Finally, the actual visual output isn't that different between the full, boxed, and boxed no line versions - they're all sort of a low-rez highly aliased mess...as is expected from just drawing a huge model at low zoom. So losing 82% of the vertices doesn't actually cause big visual problems.
My next step is to produce a much more careful "studless, boxed" variant of the library - something that could be part of the library someday.
Pics:
Original full datsville
https://www.dropbox.com/s/i26c1ey5cv51no...20full.png
Boxed parts
https://www.dropbox.com/s/187knlrv8b2373...0lines.png
Boxed parts, lines stripped.
https://www.dropbox.com/s/j0g0p4jpg912pc...0lines.png
Cheers
Ben
I have some numbers from hacking today. For a test file I grabbed Datsville r369, which has 127,691 parts. In BrickSmith I did a release build and turned off all culling tricks (so I was measuring the real cost of the whole model) as well as v-sync (so I was viewing the sustained throughput of the GPU with no fps loss due to waiting for vsync to come around). My box is an old Mac Pro Xeon, so it's more or less a core 2 at 2.8 ghz with a Radeon HD 4870.
I ran the model with sustained mouse rotation to measure total throughput of the GPU (e.g. how fast you'd have animation with scrolling) with 5 versions of the part library, designed to simulate "lower LOD sets":
- Original - the part library unmodified.
- Octastuds - the part library with the p/8 directory copied into p
- Studless - Octastuds, but then with the entire contents of stud.dat, stud2*.dat, and stud6*.dat blanked out.
- Boxed - Octastuds, plus many parts in the brick, technic brick, tile, and plate categories replaced with a single box5 sub-directive with the same size as the original part.
- Boxed no lines - same as above, but with all line directives programmatically removed by Bricksmith.
Here are the #s
ORIG: 241280493 vertices, 1.71 fps
OCTA: 149097204 (38%), 2.72 fps
STUDLESS: 89809425 (62%) 4.28 fps
BOXED: 58574196 (75%) 6.65 fps
BOXED, NO LINES: 41683162 (82%) 9.04 fps
A few notes:
- the boxed version uses 75% CPU, boxed no lines uses 100% of CPU - in other words, only by cutting the vertex count down by 75-82% did the GPU unloaded enough for CPU speed to matter.
- while the original is pretty unusable, the boxed no line version, at 9 fps on older hw is pretty tolerable.
- real numbers would have been better - the model is so zoomed out that bricksmith can opportunistically not draw tiny parts if allowed. But clearly there's a big fps win here, almost entirely proportional to vertex count.
Finally, the actual visual output isn't that different between the full, boxed, and boxed no line versions - they're all sort of a low-rez highly aliased mess...as is expected from just drawing a huge model at low zoom. So losing 82% of the vertices doesn't actually cause big visual problems.
My next step is to produce a much more careful "studless, boxed" variant of the library - something that could be part of the library someday.
Pics:
Original full datsville
https://www.dropbox.com/s/i26c1ey5cv51no...20full.png
Boxed parts
https://www.dropbox.com/s/187knlrv8b2373...0lines.png
Boxed parts, lines stripped.
https://www.dropbox.com/s/j0g0p4jpg912pc...0lines.png
Cheers
Ben