How I learned to stop worrying and love Ldraw. (Subtitle: questions for programmers)

[Paul Griffin]

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.


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

[Nicola]

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 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

4) i'm no lawyer

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.

[Paul Griffin]

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.

[Travis Cobbs]

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.)

[Travis Cobbs]

-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.)

[Roland Melkert]

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).

[Roland Melkert]

-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.

[Philippe Hurbain]

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.

[Roland Melkert]

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.

[Tim Gould]

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.

[Roland Melkert]

Don't worry like most stuff in my software it will be optional / an extra tool only. Anyway I'm still in the 'thinking' / 'unsure how to' stage, that's why I'm currently working on flexparts (With those I exactly know what I want )

[Tim Gould]

What you could do, is have a "check for clashes" button that scans the model and highlights any part that overlaps another part. That way you would be able to test for mistakes, without worrying about efficiency.

Tim

[Paul Griffin]

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.

Ah hah! Bloody normals. I assumed that with double-sided lighting on, I would simply need to change which face I cull. It turns out I needed to change OpenGL's preference on winding! Thanks!

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).

Well I don't mean to brag... JK.

I will attempt it, but time will only tell what kind of divide and conquer algorithm is needed to avoid an O(n^2) when n (our average polygon count) is 1000. Not to mention that's for collision detection, not snapping...

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).

Indeed. You would be able to calculate the overlap and "push" the pieces to their proper fit positions. The information wouldn't be as good with two-sided faces.

[Paul Griffin]

And I was just being lazy by flagging a piece as uncertified as soon as I ran into an offending command...

I'm still not sure if I should do the polygon duplication. I failed at it once (I forgot to duplicate subfile polygons), but it seems to only increase the total number of polygons rendered in the scene by 3-3.6% (based on the 8460/8800, 800-1k piece models). I'll have to think of what other side effects it could have.

I've been only checking uncertified parts for bowtied quads...guess I'll decide later if I should use that info to "un"certify a part.

Edit: I know next to nothing about shaders...all my work has been ES 1.1 work.

[Paul Griffin]

Well I'll most definitely talk with the steerco before I sell something that automatically consumes 20 MB of this site's bandwidth. Y'know, "don't bite the hand that feeds you"-kind of stuff.

I am aware that The Lego Group might not have stepped in *yet* because of the limited fan base and general availability of free versions (including their own LDD). And I highly doubt that my software will have the appeal of "Tyco" or "Mega Blocks". But I will have an LLC set up before anything gets sold.

[Travis Cobbs]

Edit: I know next to nothing about shaders...all my work has been ES 1.1 work.

I actually don't know anything about shaders either; LDView doesn't use any, and I haven't had the opportunity to learn. It seems that most new projects use them, so I suspected you might. I don't think ES 1.1 supports two-sided lighting (although I could be wrong about that).

[Willy Tschager]

-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).

Please read:

http://www.ldraw.org/article/281.html#2_..._a_program

and also:

http://www.ldraw.org/article/227.html

On a personal note I'd like to add, that you might author a simple part (there are plenty to pick from Duplo) and get it certified through the PT before you start charging for an app - just to get a feeling how much effort the 100+ part authors have put into the creation of a 5000+ parts library offered for free. Or read the last sentence on this page.

w.

[Travis Cobbs]

Note that BrickPad currently costs $0.99, and as far as I know Ken followed the above guidelines.

[Ken Drew]

Note that BrickPad currently costs $0.99, and as far as I know Ken followed the above guidelines.

And if I haven't, please let me know.

[Steffen]

I am feeling like Willy here:
Creating your program of course is some effort, and of course you can charge for it,
but you're building your "cash generator" onto our volunteer work...
hmmmmmm........ What about a donation to ldraw.org? Like 50% of all earnings?
The money is needed for server space...
However, this could immediately create the impression that ldraw.org is a commercial product,
and this immediately would call TLG to action...

[Ken Drew]

I am feeling like Willy here:
Creating your program of course is some effort, and of course you can charge for it,
but you're building your "cash generator" onto our volunteer work...
hmmmmmm........ What about a donation to ldraw.org? Like 50% of all earnings?
The money is needed for server space...
However, this could immediately create the impression that ldraw.org is a commercial product,
and this immediately would call TLG to action...

I agree that a paid app is "off the backs" of volunteer work and that a donation would be appropriate.

FYI, Apple does not pay app developers right away. There is a month (and possibly 2 or more) delay on earnings.

I would suspect that the attention of TLG would depend on the relationship between a paid app developer and ldraw.org.

[Travis Cobbs]

I would like to point out that one reason I never ported LDView to iOS was because it would cost me $100 per year to do so, and I didn't feel that any possible revenue from the app, no matter what I charged, would ever recoup that $100 per year. (Another big reason was that I was already not spending enough time on LDView.)

At $0.99 (the lowest price a non-free iOS app can have), I would need 141 new customers per year just to break even, and given the number of downloads of the freely avaiable LDView for Windows/Mac/Linux that I have, I just didn't see that happening. And I believe that charging more would decrease the number of customers enough the lower to total revenue.

Now that BrickPad is available, and quite nice, I see even less point in an LDView for iOS release. Of course, Ken's sales figures are private, but I would be very surprised if he's making much profit.

[Steffen]

I completely agree with you.

As a PS:
I still hope that we can avoid to even create OS specific applications for iOS or Android,
and instead use the WebGL possibilities like here:
http://forums.ldraw.org/showthread.php?t...32#pid7232
This keeps up the Internet principle: create something that everybody on every platform can read.
Remember the days when these icons appear all over the web?

[Ken Drew]

I would like to point out that one reason I never ported LDView to iOS was because it would cost me $100 per year to do so, and I didn't feel that any possible revenue from the app, no matter what I charged, would ever recoup that $100 per year. (Another big reason was that I was already not spending enough time on LDView.)

At $0.99 (the lowest price a non-free iOS app can have), I would need 141 new customers per year just to break even, and given the number of downloads of the freely avaiable LDView for Windows/Mac/Linux that I have, I just didn't see that happening. And I believe that charging more would decrease the number of customers enough the lower to total revenue.

Now that BrickPad is available, and quite nice, I see even less point in an LDView for iOS release. Of course, Ken's sales figures are private, but I would be very surprised if he's making much profit.

While I won't go into specific numbers, I have easily recouped my development membership. Revenue also pays for servers and hosting. A monthly donation to ldraw.org is also planned (awaiting PayPal) which will be an undisclosed percentage of my monthly revenue. What is and will be left over is profit. Some of this profit goes to help by testing devices, which if not done in my experienced opinion, is a mistake if you are making an iOS app.

Can I quit my job? HELL no. Does it fund a portion of a LEGO hobby. Yes. Do I make a profit? Yes. Does is suck an untold amount of time away from LEGO (and family)? Yes. Would I do it again? Maybe...

And realistically, this may all change with Paul's introduction of another LDraw viewer/modeler in the App Store. It seems that Renaud's brickView didn't survive. I'm not sure of the details but it is no longer in the App Store (at least in the US store).

[Ken Drew]

I completely agree with you.

As a PS:
I still hope that we can avoid to even create OS specific applications for iOS or Android,
and instead use the WebGL possibilities like here:
http://forums.ldraw.org/showthread.php?t...32#pid7232
This keeps up the Internet principle: create something that everybody on every platform can read.
Remember the days when these icons appear all over the web?

In theory yes, I agree. In practice, WebGL isn't available on all devices. If and when it does, I wonder about performance (and access and usability in a browser, and connectivity...) on the non-desktop devices. Will Android allow it (not sure if it already does)? Will Apple allow it? Not sure, and for me, Apple devices are my preference.

Web apps have yet to deliver for me...

[Allen Smith]

Apple has made it impossible for anyone to produce pure hobby software for iOS. A developer for Apple devices must either commit to funding the hobby out-of-pocket indefinitely (which, at $100/year, is a substantial outlay), or must worry about how to monetize it.

Even worse is that Apple, at any point and for any contrived "reason," may vaporize your hobby project with no forewarning or recourse on your part. After that, your work is completely wasted, as its is technically impossible to distribute it without Apple's dispensation. And of course, there's no remuneration for your lost work.

Due to these considerations, I haven't been able to justify any iOS hobby development. One might also take these factors into account when shopping for a mobile device. There's at least one platform that doesn't work like this.

Allen

[Roland Melkert]

This is exactly the reason I'm not a big Apple fan, android isn't much better though. And it seems MS wants to go the someway with it's '8' monstrosity (which is a gateway drug imho).

[Paul Griffin]

Apple has made it impossible for anyone to produce pure hobby software for iOS. A developer for Apple devices must either commit to funding the hobby out-of-pocket indefinitely (which, at $100/year, is a substantial outlay), or must worry about how to monetize it.

Even worse is that Apple, at any point and for any contrived "reason," may vaporize your hobby project with no forewarning or recourse on your part. After that, your work is completely wasted, as its is technically impossible to distribute it without Apple's dispensation. And of course, there's no remuneration for your lost work.

Due to these considerations, I haven't been able to justify any iOS hobby development. One might also take these factors into account when shopping for a mobile device. There's at least one platform that doesn't work like this.

Allen

I agree with what you said, but only for as long as you ignore jailbreaking. I already am an iOS developer (albeit in jailbreak circles only so far) and for me it did start as a hobby. Nowdays, the $100/year cost is just considered a maintenance cost. Good grief, I pay more than that a year on site hosting.

[Tim Gould]

I don't think that charging will make any difference to TLG. But... See http://forums.ldraw.org/showthread.php?t...91#pid7391

Tim

[Paul Griffin]

Oh, it's paid? Did I just forget that I purchased it, or was it free at some point?

I apologize in advance if I do end up stomping on your work. But this idea has been in my head for a year now and won't go away until it's built. And now that I have found some spare time...

One way or another, I do not have any intention of thanklessly procuring ldraw materials nor charging an exorbant amount that would keep whatever I make out of the reach of kids (*cough* you know which one). In fact, my intention is to try to make something that is within the reach of kids, from both a price and usability standpoint.

I know these are hard words to trust from someone who only has 11 (now 12!) posts here, but I hope to develop that trust with time.

[Allen Smith]

If you follow the jailbreak community, you know that Apple has done pretty much everything in its considerable power to stop it. And you also know that they have been succeeding. There is no available jailbreak for any device Apple is currently selling. There is never any guarantee that jailbreaks will continue to be found, or that there will be any measure of reliability once they are. (Since Apple has been extremely successful in preventing jailbreakers from installing the system software versions of their choice, if you bork your jailbreaked device, it's borked forever. You can't just do a clean reinstall.) I have a jailbroken iPad. And based on that experience, yes, I'm ignoring jailbreaking. It was the most effective advertisement for Android I have ever seen.

As to the $100 per year: sure, if it were just a "maintenance cost" to pay for hosting services which could be comparison-shopped, I wouldn't have a problem. But it is not. It is a monopolistically-imposed entrance fee which buys you temporary permission to develop on Apple hardware.

Allen

[Ken Drew]

Oh, it's paid? Did I just forget that I purchased it, or was it free at some point?

I apologize in advance if I do end up stomping on your work. But this idea has been in my head for a year now and won't go away until it's built. And now that I have found some spare time...

It has been a paid app since the end of August.

No need to apologize. I understand how you can have a code worm in your head that must be purged.

[Tim Gould]

It was the most effective advertisement for Android I have ever seen.

Apple's monopolistic control freak behaviour (see eg. iTunes) is one of the main reasons I've never gone down the convenient "It is *nix and a pretty OS all in one" Mac route. Even though it would be kind of convenient.

Tim

[Allen Smith]

…android isn't much better though.

I have only seen evidence which contradicts that assertion. I can install any software I want on my Android device, including software that I have developed with no permission or knowledge from Google. I can distribute that software directly on the Internet without going through any app store, and users can install it freely on their Android devices with no out-of-box modification of their software. In other words, it works just like my desktop computer. That's my definition of an open system.

On iOS, the App Store is a distribution monopoly. Conversely, Android was designed to allow people the freedom to acquire software any way they like. Google Play is a convenient way to do so, but it is by no means the only legitimate way, or even the only convenient way.

Allen

[Paul Griffin]

Good point(s). And, yes, the lack of a current jailbreak is even affecting my income quite substantially (like 25%). But the lack of a current jailbreak can be attributed to laziness and noncooperation. I'm fairly confident that all the pieces are available for an iOS 6 untethered jailbreak, but to only two guys.

[Allen Smith]

Sure, but what about an iOS 6.1 unthethered jailbreak? What happens if Apple just hires those two guys? What happens if those two guys get run over by a bus? What if they have kids and run out of time to pore over machine code looking for security exploits? Are you smart enough to do it yourself? What if Apple sues them all under the DMCA? (Recall, the Library of Congress specifically declined to make an exception for tablet jailbreaking.)

Most people will reasonably give up after one of those questions. Even if there are enough really smart people to keep jailbreaking alive in perpetuity, it will never be consistently reliable or up-to-date on the latest hardware. Without a change of values at Apple, it will never be a legitimate distribution model.

Allen

[Roland Melkert]

If so it's more open then I thought, but concerning android I was more hinting on the joint at the hip with Google thing. And that's just another ms/apple to me

[Paul Griffin]

Progress is coming along nicely; I've got a part browser and a color browser fully functional. Can't wait until I get this to be a full-fledged editor. But it's amazingly complicated to fit so many options on the screen on an iPhone.

I've even got the following model running at 10+ fps:

[Philippe Hurbain]

Eagerly waiting for Android port

[Paul Griffin]

Time to resurrect a dead thread! Yippee!

I've been working on this project as I've had time over the last 1.5 years (yadda yadda life gets tough), but have made a lot of steady progress recently. So, here's to sharing more photos.

I built the following models inside the app (on an iPad, of course)




aand...the following screenshots were taken inside the app.




Sadly, I still need to build up support for three key components: submodel editing, step editing, and part snapping - but I'm quite pleased with how it's going! Perhaps you'll see it before December!

[Orion Pobursky]

Nice work! Looking forward to release.

[Clay Loveless]

Paul, as it's been a few months, I'm curious about the status of your app. The screenshots look great! Any chance you're near a release?

[Paul Griffin]

Hey Clay, thanks for asking. I'm still making progress, albeit it has slowed down. Girlfriend, a well-paying job, etc. However, I have every intention to finish this! I've done my best to make simple, intuiutive, and good-looking, and I can't wait to get this out there.

Not too long ago, I had only three major tasks to complete: submodel editing, step editing, and parts snapping. Submodel editing works and step editing is at about 90% in the storyboard phase (a good UI precedes any coding), but my snapping algorithm is still theoretical in nature and involves things like range trees that I've never dealt with before.

If I had no distractions at all, I could probably have this done in a month, but I know that won't happen. Who knows, I may simply decide to release before I can figure out snapping. In all fairness, it still works really well without it! I've built 600pc models (e.g. Horizon Express engine) without too much issue...

[img size=1024x768]http://i.imgur.com/5m4Em1X.jpg[/img]