LDraw.org Discussion Forums

Full Version: LDraw App for iOS
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
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:
[Image: dragon-left.png]

Right:
[Image: dragon-right.png]
Jim DeVona Wrote: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.
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.
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.
Orion Pobursky Wrote: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
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.
I feel the need to defend OpenGL Smile

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.
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).
Pages: 1 2