LDraw.org Discussion Forums

Full Version: Decreasing poly count on models
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3
Ok i have this question: suppose that i want to make a low poly version of a model (made of N parts), suitable for real time graphics for example in a videogame, how could i substantially reduce the amount of vertex and polygons while keeping as much details as possible? I'm not interested in keeping internal structure, just to obtain a lowpoly model.

One thing that came to mind was to remove all studs from the parts (they're relatively small in a model, expecially when seen from apart, and take up a lots of vertex/poly), and it would be easily done by removing all stud*.dat primitives. Also removing all greeble on the bottom of bricks would help a lot (but it's harder as, afaik, they're not primitives?).
Another thing could be to remove all internal, non visible parts, but how to do it algorithmically is bejond me.

So can anyone point to some algorithm or want to share some idea ?
Actually, the tubes on the bottom of parts (like the generic 2x4 brick and 2x4 plate) use stud primitives also (stud4.dat for that diameter tube). Unless you're viewing the model from a long way away, though, it's not going to look at all like LEGO if all the studs have been removed.
You could play around with bump mapping or tessellation to replace the studs. Biggest problem would be to generate the needed textures.
Yes removing studs doesn't look great (you can do it easily in POVray). Even at a long distance your brain just finds it off. I build pretty studless models, but leaving off the few that remains ruins the LEGO effect.

But... I reckon replacing studs by cleverly chosen textures _might_ work alright at a distance.

Tim
yeah maybe using some ad-hoc shader to simulate studs would do, but it's not that easy..
and what about removing inner bricks? anyone has ideas?
The LDBoxer tool might help you remove some more polys.

http://home.swipnet.se/simlego/ldraw/ldb...dboxer.htm
I'm working to solve this problem (reduce faces number).
I have an idea which need to be improved.

first, you merge all files which are used by your model.
second, you display your model with an unique color (example: white; no light effet).
trird, you display a closed mesh which represents all possible points of view (another color: blue).
next you place your point of view at the position of the tested face (normal to the face) with an angular vision of 180° (don't display the tested face).

So, if there are blue pixel, the face is visible from the mesh of possible points of view.
That's an interesting algorithm, i tried to come up with something similar..
So if i understood correctly, basically you sit on every face of the model, and look up the normal. if you see any "blue", that means the face is also visible from the "blue" (so must be kept), otherwise if you see only white, you can conclude you're an inner face and can be removed.
One thing that came in mind is how you compute the "point of view" mesh. In the simplest case, it could be a sphere enclosing the whole mesh, am i right? But i feel that it's more complex than that. If you have a convex model, there can be points that are never visible from the "outside sphere", but are still on the surface, and you could possibly see it "navigating inside" the model.

The only other problem is performances (it should render a frame for each face in the model), but of course the whole algorithm can be precomputed beforehand so not really a big deal.

Have you implemented anything yet ?
Nicola Wrote:One thing that came in mind is how you compute the "point of view" mesh. In the simplest case, it could be a sphere enclosing the whole mesh, am i right? But i feel that it's more complex than that. If you have a convex model, there can be points that are never visible from the "outside sphere", but are still on the surface, and you could possibly see it "navigating inside" the model.

Although I can't prove it, I'm fairly certain that any external face must have an even (including zero) number of faces between it and the viewer. So your convex face can be found by counting intersections.

I'd like, one day, to make a program that can "auto BFC" a part by this method by tracing a ray and flipping surfaces as needed. But it's slow and thus not a routine you'd like to do every load. Do it once and prepackage a BFCd library.

Tim
Hi Y'all,

This topic may be of interest to LDraw viewers too since it's easy to get geometry bound.

This might be a silly idea, but for some parts you could calculate its axis aligned bounding box and then rendering an ortho view of the part (projected onto the bounding box) to a texture that becomes a normal map; then draw the bounding box with the normal map in-game. The idea is that you'd be "baking" studs, greebles and other small detail into a texture, which is something the game engine may be prepared to cope with.

(Commercial games use this technique in real production - you model a low polygon final object, then add 3-d detail, then 'bake' the 3-d detail back onto the low detail.)

One of the wins here is quality: when studs get very small you get a ton of aliasing due to tiny triangles - even 16x FSAA doesn't go that far. But geometry faked with a texture is subject to mipmapping, giving you good down-sampling to small sizes.

In BrickSmith I am experimenting with replacing primitives with their bounding box based on the size of the part in screen space in real-time - so it's a dynamic LOD scheme, not a net reduction. But in the case with a large number of parts, it's a win: zoomed in, parts are culled off-screen, and zoomed out, many small parts are reduced to bounding boxes, while the big parts are preserved. But the results are medium-quality at best...it's done for performance reasons.

cheers
Ben
Pages: 1 2 3