LDraw.org Discussion Forums
How I learned to stop worrying and love Ldraw. (Subtitle: questions for programmers) - Printable Version

+- LDraw.org Discussion Forums (https://forums.ldraw.org)
+-- Forum: LDraw Programs (https://forums.ldraw.org/forum-7.html)
+--- Forum: LDraw Editors and Viewers (https://forums.ldraw.org/forum-11.html)
+--- Thread: How I learned to stop worrying and love Ldraw. (Subtitle: questions for programmers) (/thread-7286.html)

Pages: 1 2 3 4 5


How I learned to stop worrying and love Ldraw. (Subtitle: questions for programmers) - Paul Griffin - 2012-12-17

I hope this is in the "right" section; if not, mods, give the noob a thousand e-lashes.

I'm working on a 3D app right now, and have had way too much "fun" in working with the Ldraw file format. I would not call my work anywhere close to compliant with the Ldraw spec, but suffice to say, I've made some progress...and along the way, rediscovered linear algebra, projections, angles, and more.

Here's a pic of what I've got working so far.
[Image: 6AcZJ.png]

Now, for my questions:

-How do you approach non-certified BFC files? Do you check for bowtied parts? Do you treat it as uncertified even if it only contains subparts/primitives? Unfortunately, due to resource limitations, I cannot simply duplicate every noncertified polygon I come across, so I've had to learn to process said polygons as if they are two-sided (which has NOT been fun). I cannot recall, but somewhere between 2997/2998 and 6581/6582, I encountered flipped polygons, bowtied polygons, and more...enough that I have a headache from all that checking.

-Do you have any recommendations on how to perfect normal smoothing? If I find two triangles meet at an angle 180 += 30, I consider them to be part of a curve and I smooth them proportionally to the triangle corner angles. I seem to get a little too much smoothing out of that, but I need to be able to catch at least 180+=22.5 to smooth the stubs (plus using the 48 versions isn't an option).

-How accurate are the ldraw parts? This may be a very bold statement to make, but I do plan to perform intelligent part snapping based solely on the polygons I extract from a ldr file.

-Legally: Can "The Lego Group" prevent me from selling an app I make (provided that I do not use their trademark)? If I want to use the ldraw parts library, what's the recommended way to share it? It seems that, aside from parts/756.dat parts/s/2336s35.dat, I could distribute the zip myself. (Edit: nevermind per #2. I see there's a link for CCAL-compliant parts).

-is there anything you wish you had known when you started working on your program?

Thanks in advance Smile


Re: How I learned to stop worrying and love Ldraw. (Subtitle: questions for programmers) - Nicola - 2012-12-17

Hello, i'm a noob too, but here's my 2 cents before the veterans of the forum reply:

1) non certified part, for what i've understood, are to be considered 2 poligon, facing opposite side. I've asked the very same question as i encountered the problem Smile replies are here.

2) i implemented smoothing using conditional lines, and LDView author did the same. Basically instead of relaying on angles, you smooth two faces when they're connected by a conditional line. The results looks good (you can see my renderer here)

3) didn't understand Smile

4) i'm no lawyer Smile

5) mmm nothing i could think of. Except for bowtied quads and non bfc parts, the file format and the specification are straightforward and without surprise, if a little naive. At the beginning i was hoping the vertex and face count would stay reasonably low for small models, but that was not the case. Even the smaller parts have studs and curved innards and for small/medium builds the vertex count just explodes to tens or hundreds of thousands.


Re: How I learned to stop worrying and love Ldraw. (Subtitle: questions for programmers) - Paul Griffin - 2012-12-17

1. Hmm...well I looked again at the specs and I think I got my answer. If the subfiles are parts, I don't need to worry about it. I'm flattening parts before I render them (so I can have a single VBO per part), so this should help me minimize the amount of double-sided rendering I do (which doubles the GPU usage)

2. Huh; I did not think about that. I can definitely think of cases where there wouldn't be conditional lines but you'd want smoothing (e.g, the interior of a funnel). Speaking of conditional lines, do you just brute force them and draw them one at a time? There's got to be a faster way to handle them...

3. Yea, probably the wrong category to ask such a question in. I know they recommend using ldraw units whenever possible, so here's to hoping that most parts just naturally "fit" together.

5. BFC...From CW to INVERTNEXT to matrix determinants...*sigh*. And I still haven't caught all the cases as of yet, as you can likely see in the rear wheel. Per the polygon count...1k polygons per piece (when you flatten them) is a fair estimate. My "test bench" has 800K - 1M polygons, so minimizing the polygon count is pretty important.


Re: How I learned to stop worrying and love Ldraw. (Subtitle: questions for programmers) - Travis Cobbs - 2012-12-18

Paul Griffin Wrote:2. Huh; I did not think about that. I can definitely think of cases where there wouldn't be conditional lines but you'd want smoothing (e.g, the interior of a funnel). Speaking of conditional lines, do you just brute force them and draw them one at a time? There's got to be a faster way to handle them...

As it happens, LDView implements two different smoothing algorithms:
  • The first is as described above, and is used by the interactive 3D part of LDView. It does indeed produce very good results for most parts, but doesn't for some parts (like the minifig heads). It also requires an angle threshold, because certain geometry (for example, a sharp cone), cannot be properly smoothed, no matter what you do.
  • The second is similar, but instead of using conditional lines to detect smooth surfaces, it uses edge lines to detect creases (along with an angle threshold). LDView uses this algorithm for its POV export. This is closer to a typical "smooth all adjacent faces whose difference in angle is less than x degrees" algorithm, but the edge lines give it extra data that these types of algorithms typically don't have, so the angle threshold can be set relatively high while still producing good results.
Unfortunately, the two algorithms work on completely separate input data, so I can't directly compare them in the real-time 3D part of LDView, and they're both what I would call non-trivial. So, to be honest, I'm not sure which is best, but my gut feeling is that the algorithm I use for POV export is better. (Having said that, I don't think it does any better on minifig faces than the other algorithm, although I haven't thoroughly investigated this.)


Re: How I learned to stop worrying and love Ldraw. (Subtitle: questions for programmers) - Travis Cobbs - 2012-12-18

Paul Griffin Wrote:-How do you approach non-certified BFC files? Do you check for bowtied parts? Do you treat it as uncertified even if it only contains subparts/primitives? Unfortunately, due to resource limitations, I cannot simply duplicate every noncertified polygon I come across, so I've had to learn to process said polygons as if they are two-sided (which has NOT been fun). I cannot recall, but somewhere between 2997/2998 and 6581/6582, I encountered flipped polygons, bowtied polygons, and more...enough that I have a headache from all that checking.

If you look at the BFC spec, you will see that it's perfectly valid to have a BFC certified file with non-BFC certified sections, so BFC certification isn't actually on a file-by-file basis, but a line-by-line basis. LDView determines the BFC status of every line while loading, and sends all the non-BFC-certified lines to a separate section, where both sides are rendered and lit. All the rest are rendered based on the final BFC state determined by the BFC certification. LDView enables OpenGL's two-sided lighting and disables back-face-culling for non-certified geometry. I'm sure this could be done in OpenGL ES 2 with a proper shader if you wanted. However, it probably makes more sense to just treat non-certified polygons as two back-to-back polygons, because my experience has been that there are more and more BFC-certified parts as time goes by.

LDView does check for bow-tie quads. These can be auto-corrected in non-BFC geometry. In BFC geometry, bow-tie quads are an outright error, so LDView disables BFC for them if it detects them (and then corrects). (I don't think the official library has any bow-tie quads in BFC-certified portions of files.)


Re: How I learned to stop worrying and love Ldraw. (Subtitle: questions for programmers) - Roland Melkert - 2012-12-18

I also use vbo per highlevel part in my software, the main downside of that is some models use mirroring of (sub)models which will mess up the normals. You can compensate for that by ether switching winding or flipping normals.

Personally I (for the time being) choose to NOT support that kind of modelling (it's not possible in real LEGO too) in order to prevent all the extra state changes and or realtime corrections etc.

Anyhow this might be what's messing up that rear wheel.


On the auto click/snapping issue, I've been preparing myself to add such functionality too my software for awhile now. The main reason I haven't yet is I too want it too be as much automatic as possible. Although I have had some ideas which seem workable in the end I still often end up needing some extra information (which can partly be generated from primitives though).

So unless you are some kind of math genius I don't think 100% mesh based connection handling is feasible (especially on current tablet hardware).

Having said that things might change if ALL parts would be BFC compliant (IMHO determine what's inside and outside is a big thing in generating connection information).


Re: How I learned to stop worrying and love Ldraw. (Subtitle: questions for programmers) - Roland Melkert - 2012-12-18

Paul Griffin Wrote:-Legally: Can "The Lego Group" prevent me from selling an app I make (provided that I do not use their trademark)? If I want to use the ldraw parts library, what's the recommended way to share it? It seems that, aside from parts/756.dat parts/s/2336s35.dat, I could distribute the zip myself. (Edit: nevermind per #2. I see there's a link for CCAL-compliant parts).

I think this is something the steerco can help you with more, but personally I think the main reason LEGO Group doesn't really care about LDraw is the fact it's free and has a fairly limited user group.

For this reason the recent popping up of paid LDraw software is worrying me somewhat.

But again this is really a steerco issue, and the above is only my own opinion.


Re: How I learned to stop worrying and love Ldraw. (Subtitle: questions for programmers) - Philippe Hurbain - 2012-12-18

Quote:Having said that things might change if ALL parts would be BFC compliant (IMHO determine what's inside and outside is a big thing in generating connection information).
It might still take a while... and it will still not solve the inside/outside issue. Eg. studs laying on a flat surface.


Re: How I learned to stop worrying and love Ldraw. (Subtitle: questions for programmers) - Roland Melkert - 2012-12-18

It (probably) wouldn't fix everything but when all is bfc you could do 'better' collision detection, or at least in the way I was thinking of doing it.


Re: How I learned to stop worrying and love Ldraw. (Subtitle: questions for programmers) - Tim Gould - 2012-12-18

I don't think collision detection is a good idea (or at least, I will not be turning it on).

Many times I stress elements in my models. It works in brick, but in CAD there is an overlap of the parts. And I mean something that happens in almost every model I have ever designed.