Roland Melkert Wrote:Isn't the amount of shared vertices too low to justify all the uniqueness tests with smoothed meshes ? Although it's only done once some parts (especially base plates) can take quite some time to determine all unique vertices. This becomes even more worrying when texture coordinates get involved.
I'm not sure since I haven't written the code; but it's a necessary step for smoothing - the unique-ing comes for free. I'm hoping a good vertex hash map or tree will solve that problem. (Time would be O(N) or O(NlogN).
If search time is a problem, another option would be to uniqe/smooth the sub-models first and then assume no sharing in the main models. For example, the 1024 studs on 3811.dat all come from stud.dat. If stud.dat is pre-unique and pre-smoothed (very cheap) this data can be recycled as-is. But I am going to try brute force first as it fits the architecture of BrickSmith better.
Quote:Yes, occlusion testing might help with this issue, but it isn't easy to implement as far I've looked into it.
Agreed - occlusion culling is difficult even in games where very specific data can be pre-computed offline to make the tests work well. Given an ever-changing user composition I don't see a win. :-(
Quote:I use a single set of VBO's per brick (triangles, edges, indices), these have no color component at all. I just issue a plain glColor before the drawelements call.
How do you handle parts like 122c01, where the the plate is user-colored, the wheels are red, and the axle is..metalic I guess? In BrickSmith the color is tagged as a mix of red, metalic, and user-set. If you pass immediate mode color I would think you'd need (at a minimum) 3 draw calls and some side data to tell you which part of the VBO gets which color.
Cheers
Ben