Reducing part complexity

[Mike "Pomax" Kamermans]

hey all,

now that I have a working JavaScript .dat to .obj converter for using LEGO parts in a WebGL context, I was wondering whether anyone had already tried implementing a complexity reduction algorithm for parts meshes.

At several thousand vertices per part, some of these parts might be better rendered as reduced meshes with some bump/texture mapping that fakes some of the more intricate details (like teeth on cogs, or profile on an axle joiner), not to mention help load larger models, as WebGL only allows ~65k vertices per scene.

Has anyone experimented with this yet?

- Mike

[Travis Cobbs]

The only thing I am aware of is swapping out studs. If you replace the "d" in stud*.dat with "2", you will get lower-resolution versions (with 8 facets instead of 16 for the circle). Most (all?) stud*.dat files have stu2*.dat versions. That's what the "Low quality studs (faster)" option does in LDView.

[Roland Melkert]

Did you 'compress' the messes? Meaning removing all duplicates through indices.

If not this easily reduces most parts by 20% or so. Could take ages on large meshes though (depending on hardware etc) even with lookup tricks etc. Before comparing you can safely round all coordinates to 4 or 3 decimals depending on your quality wishes.

[Steffen]

Another optimization is to check visibility _before_ the conversion from ldr to obj.
For example, studs which are covered by non-transparent bricks which are built on top of them
need not to be exported to the result mesh.
For example, if you build a wall for a house from bricks, none of the studs would be visible in most usecases.
For example, what jumps to my mind is implementing a big lookup table (probably, best, a hashmap) which tells
"if I put THIS brick in THIS position onto THAT brick, then THESE studs can be left away".

[Nicola]

I had this idea too, but the implementation is very hard. The lookup table you suggest is not very practical, becouse it would be huge and difficult to mantain (there are too many combinations). The alternative is using some occlusion detection algorithm, but they're complex on their own,time consuming and not 100% perfect.

I think the best solution to reduce vertex count is vertex merging (that is, removing one of two vertices if they're very close), that i do in BRIGL, and replacing/removing primitives. That is, you create a second set of primitive with much fewer vertices, or eventually leaving them out altogheter (for example removing stud completely). As Travis says, there's already a second set of primitives for studs.

[Travis Cobbs]

When LDView does primitive substitution, the lowest quality setting does in fact do this for all circular primitives, reducing them to match an 8-sided circle instead of the standard 16-sided circle. I had forgotten about that. You can't really go below 8-sided with generic LDraw primitives without introducing problems. (And obviously, the x-16 primitives can't even go down to 8.)