Hi Roland,
I have a parking garage MOC - a single MPD file with 32 sub-sections that is currently 23,019 parts.
If you can accept a scene that is a collection of MPD files in single directory, the airport to which the garage belongs is currently 34,963 parts.
The garage renders at about 8 fps, and the whole airport renders at about 4.5 fps. On the same machine, Datsville (the version I have is around 39k parts?) runs at 5.5 fps.
Email me at bsupnik at gmail dot com and I can send them to you.
Re: performance, I found a few things with Bricksmith:
* A shader-based pipeline wasn't faster than fixed-function for the same basic work.
* CPU time is proportional to the number of bricks, not the number of vertices.
* When using the programmable pipeline and instancing techniques, BrickSmith is vertex-count bound, not CPU bound. It's not even close -- even with culling and transparent part sorting, I see CPU use of 15-25% while maxed out on fps with 30-40k parts. In this case the interesting number isn't the part count but the vertex count those parts yield. This is with a 4870 - a newer GPU would help the vertex-count bottleneck.
I wrote this up when I finished some perf measurements...
http://www.hacksoflife.blogspot.com/2013...smith.html
cheers
Ben
I have a parking garage MOC - a single MPD file with 32 sub-sections that is currently 23,019 parts.
If you can accept a scene that is a collection of MPD files in single directory, the airport to which the garage belongs is currently 34,963 parts.
The garage renders at about 8 fps, and the whole airport renders at about 4.5 fps. On the same machine, Datsville (the version I have is around 39k parts?) runs at 5.5 fps.
Email me at bsupnik at gmail dot com and I can send them to you.
Re: performance, I found a few things with Bricksmith:
* A shader-based pipeline wasn't faster than fixed-function for the same basic work.
* CPU time is proportional to the number of bricks, not the number of vertices.
* When using the programmable pipeline and instancing techniques, BrickSmith is vertex-count bound, not CPU bound. It's not even close -- even with culling and transparent part sorting, I see CPU use of 15-25% while maxed out on fps with 30-40k parts. In this case the interesting number isn't the part count but the vertex count those parts yield. This is with a 4870 - a newer GPU would help the vertex-count bottleneck.
I wrote this up when I finished some perf measurements...
http://www.hacksoflife.blogspot.com/2013...smith.html
cheers
Ben