Jude Parrill Wrote:I think at this scale, you need to start looking at removing geometry programmatically. For example, if you have a brick that is part of a wall that is covered both on top and bottom, you can remove all studs and bottomside detail, and even close up, it will still look right.
What you are describing is similar to occlusion culling. But:
- I do not think this will solve the problem I am trying to solve. For the size of models and scale of drawing, often even the visible surfaces represent "too much stuff"...I have to accept lower quality output.
- Because Bricksmith (and other LDraw apps) are often editors and not viewers, they can't use occlusion algorithms that require heavy pre-processing of the data. BrickSmith needs to be responsive when a user moves a brick. Thus if it can't determine visibility in more-or-less real-time, visibility determination isn't an option. I definitely don't have enough CPU power to do occlusion culling on every single stud in a model.
Quote:After all, isn't this why we have BFC? If the camera is looking at the "back side" of some primitive/reference, why draw it?
LOD and BFC solve different but related problems.
- BFC reduces the number of pixels shaded by the graphics card when surfaces are not already submitted in front-to-back order, but it does not decrease the number of vertices submitted.
- LOD reduces the number of vertices submitted but does not change the number of pixels shaded.
For very large models at low zoom, BrickSmith is definitely _vertex_ bound - BFC won't make any difference.
Quote: I think you're better off writing algorithms that detect whether or not something can be seen and if so, which side, and then drawing/not drawing based on that. You're absolutely right that you're going to end up with a lot of unneeded/unseen geometry in really any size file, and rendering it is pointless/a waste of resources. Even with just a single part, at any given time, only half (at most) of it's geometry is visible. Writing algorithms to cull this unseen geometry is (I believe) going to be key to solving your performance issues.
Per above, I do not think this is feasable for an editor with real-time part editing/movement and real-time camera movement. :-( This is why I am coming to the LDraw community to discuss geometrically simplified model sets.
cheers
Ben