LDraw App for iOS

[Renaud Breard]

Hello,
My application for iOS (iPad and iPhone running iOS 5 or newer) is in AppStore today. It's a very basic application now, you can view a ldraw file full and step by step. It's called brickView. Files can be loaded from "iTunes files sharing" or from other application (ex : mail, dropbox ...), from safari I have some issues that depend how the web server send the file.
brickView is a free App, development is not my job, and development of brickView is just a hobby. I have developed it because I want to view my ldraw models on my iPad, but there is not app until now for that.
I hope that you have fun with brickView if you try it...

Renaud

[Jim DeVona]

Great work! It works seamlessly with the few models I've opened so far. Conveniently, I already keep my LDraw models in Dropbox. Opening them in BrickView works as expected. Models load pretty quickly (at least the relatively small ones I've tried) and the spin/zoom/pan touch controls work exactly as expected based on other apps. Here's a screenshot:



The alert that appears when you open a model containing parts not in the embedded library is reasonable. (Another reason to make it easy to include such parts as sub models.)

I hope this encourages other LDraw software authors to consider developing for iOS too. It most certainly is feasible, as Renaud has shown.

[Orion Pobursky]

And here's the obligatory iPad shot.

I stress tested it. Works well. Wouldn't load the Super Star Destroyer

Also, it throws up a missing parts error even if the parts are imbedded in the MPD. I'm curious if this is due to the "/" in name of some of the submodel. I'll do some further testing.

[Steffen]

since I'm on the Android side of the world, I cannot checkout your app,
but it looks very, very nice!

The problem with the Apps like Apple and Google intend to push them into the market is, IMHO,
that they break the universal structure of the internet.
Instead of using HTML5 to simply design a webpage, companies like newspapers seem to instead prefer
to have programmers write specific apps for iOS and Android (and, maybe tomorrow, another App technology X
and another App technology Y and another App technology Z).
So I see the universality of the internet drown and drown by these developments.
That's the reason why I would prefer a more OS-independent approach over an OS-specific one:
I would prefer to have some webpage, embed some (admittedly, ugly) JavaScript into it,
and use WebGL to paint the 3D object. Doing it this way could be seen by any browser supporting
these technologies, and the browser would take care of doing this as quickly as possible on its given hardware,
not the content supplier.

Just wanted to share this thought, it is mainly an extended version of this:
http://forums.ldraw.org/showthread.php?t...22#pid1022

[Jim DeVona]

I understand and in principle agree with your objection to the proliferation of native apps for jobs better served by web pages. However, not all jobs are better served by web pages. Do you think it would be better to shoe-horn the functionality of sophisticated native apps like MLCad, Bricksmith, or LDView into a web browser? If not, then why the different attitude about desktop and mobile platforms?

Anyway, to be clear, I am enthusiastic about the prospect of web-based LDraw viewers too. I just think there are plenty of reasons and plenty of room for both approaches.

[Jean-Philippe Ouellet]

Such a universal application as you described is in the works.



Edit: Finally got a chance to try your app. Quite nice indeed. One question though, is it rendering conditional lines?

[Steffen]

Yes, the discussion pro and contra apps is not a black/white one.
I see your arguments and agree. Of course, not everything is possible in a web browser or should be done there.
I just wanted to emphasize the 2 sides of the medal.

[Ramón Figueroa-Centeno]

Aloha,

Very nice! It works well in my iPad.

Now, it would be nice to be able to delete models from within the app, without going to iTunes.

Mahalo,

Ramón

[Jean-Philippe Ouellet]

I believe I found a bug.

I loaded the very awesome 75174p01c01.dat and rotated it such that one transparent wing overlaps the other transparent wing.

From a side view, I would expect the back wing to be visible through the front wing (both wings are transparent) however this is only true when viewing from one side, not the other:

View from right side of dragon (as expected):


View from left side of dragon (back wing invisible behind front wing):

[Orion Pobursky]

This may actually be a side effect of how the model is lit. Notice that the right side is darker than the left side.

[Jim DeVona]

Note that this bug is found in Bricksmith, too. Confuses me all the time when parts seem to disappear behind the transparent canopy of starfighter models. Basically, through transparent parts you can only see parts that are specified earlier in the file; the transparent part seems "opaque" to parts specified after it in the file. (I reported this to Allen in 2008, who indicated that this is a consequence of how OpenGL computes transparency.)

Left:


Right:

[Orion Pobursky]

I reported this to Allen in 2008, who indicated that this is a consequence of how OpenGL computes transparency.

Well, LDView (I used the OSX version) doesn't exhibit this error so it is most likely not due to OpenGL.

[Jim DeVona]

Right. In any case, I see the same transparency/sorting behavior in brickView and Bricksmith. My understanding is that the fix is a matter of drawing transparent parts last, but I don't really know the details of how different renderers are implemented, so I'll leave that discussion to others.

[Travis Cobbs]

On the Effects tab of LDView's preferences dialog there is a Transparency box, and in this box is Sort check box (which is enabled by default). If you uncheck the check box, LDView will exhibit similar behavior to that described above, although in LDView all transparent shapes are always drawn last, so they can never occlude opaque geometry, only other transparent geometry.

The Sort check box causes all transparent geometry in the entire model to be put into one huge list of triangles (as the last step of the file load). Then, each frame, these triangles are sorted (mosty) back to front. (I say mostly, because doing a really good job of sorting them takes more time, and usually doesn't produce a very visible difference in quality. Additionally, since triangles are free to intersect, it's not actually possible to fully sort them unless intersecting triangles are first chopped up.) There are other more advanced ways to draw transparent geometry that don't require all the transparent triangles to be sorted every frame, but they're much more high-tech.

[Allen Smith]

Well, LDView (I used the OSX version) doesn't exhibit this error so it is most likely not due to OpenGL.

Yes, this is due to OpenGL. LDView can do a better job hiding the problem because it has the luxury of reorganizing elements with no additional architectural consequence. In an editor, the order of elements still matters once you've opened the file. I could certainly do on-the-fly deferral of the drawing of transparent parts, but it's all sufficiently irritating to do so that I've always pursued lower-hanging fruit first.

Allen

[Orion Pobursky]

Yeah Travis explained it. I didn't know that he "massaged" the file to prevent this. It's odd that something like this exists in such a widely used spec.

[Roland Melkert]

I feel the need to defend OpenGL

It's not a shortcoming of OpenGL it's a shortcoming of the chosen render technique by the developer. The use technique is fine for solid meshes and performs the fastest for such models. But when you know there is transparency in a model you need to change rendering technique to take care of this. This is the case in any API (also e.g. DirectX )

Like Travis pointed out the 'simplest' way is by sorting the data from back to front so the blending of colors gets done correctly automatically. But this sorting can be costly, there are other solutions floating around on the net including using extra buffers and very complicated shaders. But in the end it's always a quality vs speed thing.

In LDCad I use part level sorting, which is faster then sorting all triangles but less 'nice' in the case of overlapping parts etc. But in the end you barely notice such 'glitches'. Also the used sorting algorithm can be of huge influence depending on the amount of data.

[Renaud Breard]

Thank you for all feedback, i known that brickView is very imperfect, i will try to improve it in the future.

For transparency i known that actually it's do not work correctly and i will try to correct it. Actually, transparent part are draw at end, but not correctly sorted.
I have found a bug not reported here, on iPhone only, if you display the models list and back to main view without selecting a model, step buttons become inactive.
For part not found in mpd, Orion can you send me the file that show this error, or a link to it (my mail : brickview at gling-glo dot com). On development version i have log and can see what append for missing part.
I'm not very happy with alert for missing part, in next release i will replace this alert by displaying an icon, and clic on icon will display the list of part not found.
For file management i will add support to save file (for models opened from another app) and delete or rename for files in application documents folder.
On my current dev version, i have added support for BFC, but i am a little disappointed since drawing performance with BFC is not very improved. I have added also some code for correct matrix with row or column at 0, and check for identical vertex in quad and triangle, but i think that is not really the job of viewer, in next release i will to put part library in binary format, and correct error during conversion (but i will keep correction code in brickView for part and primitive from outside the embedded part library).