LDraw.org Discussion Forums

Full Version: 3D Part Preview added to Parts Tracker
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5 6 7 8 9 10 11
(2019-07-24, 13:54)Lasse Deleuran Wrote: [ -> ]WebGL only renders transparent triangles correctly when they are drawn before the stuff behind. This is the reason why I am separating transparent and opaque stuff in the code base. Unfortunately I do not know how to fix this issue without either making all transparent geometries not culled, or do some crazy inefficient sorting before rendering.

So what do you guys think? Is this a big enough issue to reduce efficiency by not culling transparent elements, or should it just be left like this?

I've never used WebGL, but for rasterizer-based 3D rendering in general (and OpenGL in specific), you typically need to draw the transparent objects last, not first. That's the only way opaque geometry behind them will be visible through them. Furthermore, you typically want to render the transparent geometry from back to front, not from front to back. Once again, that's so that the transparent stuff in back is visible through the stuff in front. (There is a technique called depth peeling that allows you to render transparent geometry in arbitrary order, but it has a maximum number of overlapping transparent polygons that can be drawn correctly.)

LDView sorts transparent polygons by default (although it does so in multiple threads), and the performance is usually acceptable, since the total number of transparent polygons is usually manageable. Certainly for displaying parts, sorting should be plenty fast. One thing that might improve the results for parts without requiring sorting is to disable Z-buffer writes during transparent polygon drawing. (Leave depth testing enabled, but don't update the depth buffer during transparent drawing.) With non-lit transparent polygons that are the same color, this would (I think) completely fix the problem. If two different colored transparent polygons overlap, the result could be wrong (although it might still be better than what you have now; you'd have to test).
(2019-07-24, 17:12)Travis Cobbs Wrote: [ -> ]I've never used WebGL, but for rasterizer-based 3D rendering in general (and OpenGL in specific), you typically need to draw the transparent objects last, not first. That's the only way opaque geometry behind them will be visible through them. Furthermore, you typically want to render the transparent geometry from back to front, not from front to back. Once again, that's so that the transparent stuff in back is visible through the stuff in front. (There is a technique called depth peeling that allows you to render transparent geometry in arbitrary order, but it has a maximum number of overlapping transparent polygons that can be drawn correctly.)

LDView sorts transparent polygons by default (although it does so in multiple threads), and the performance is usually acceptable, since the total number of transparent polygons is usually manageable. Certainly for displaying parts, sorting should be plenty fast. One thing that might improve the results for parts without requiring sorting is to disable Z-buffer writes during transparent polygon drawing. (Leave depth testing enabled, but don't update the depth buffer during transparent drawing.) With non-lit transparent polygons that are the same color, this would (I think) completely fix the problem. If two different colored transparent polygons overlap, the result could be wrong (although it might still be better than what you have now; you'd have to test).
You are right. It must be drawn back-to-front. And thanks for the pointers. I will look into the depth buffer fix and other algorithms to improve this aspect. 

My biggest issue is performance. I am used to write in C++, so the performance aspects of this all being written in Javascript (and GLSL) is an adventure!
Ok, Steffen, I relent (mostly because I figured out how to do it without affecting non-WebGL clients). You can now click the image to get the 3d View and browsers without WebGL will behave normally.
(2019-07-28, 4:54)Orion Pobursky Wrote: [ -> ]Ok, Steffen, I relent (mostly because I figured out how to do it without affecting non-WebGL clients). You can now click the image to get the 3d View and browsers without WebGL will behave normally.
Convenient, thanks!
Otherwise, I can't 3D view some obsoletized shortcuts, such as https://www.ldraw.org/cgi-bin/ptdetail.cgi?s=4100338 (blank window). Not that it bothers me much, but...
(2019-07-23, 23:51)Orion Pobursky Wrote: [ -> ]Seems to work on my phone. Try a ctrl-shift-r to reload the cached scripts.
I have found the hack of adding unused query parameters with the timestamp of files works fairly well to avoid browser caching of updated files.

So instead of "file.js", the URL is "file.js?t=2019-07-30-13-44.

The need comes especially from mobile platforms. As an example. I am unable to hard refresh on iPhone standard browser without deleting all browser data.
(2019-07-28, 14:44)Lasse Deleuran Wrote: [ -> ]The need comes especially from mobile platforms. As an example. I am unable to hard refresh on iPhone standard browser without deleting all browser data.

Fir mobile safari it easy. Just long press on the reload button and choose "reload without content blockers". This'll refresh everything for the page.
(2019-07-28, 19:42)Orion Pobursky Wrote: [ -> ]Fir mobile safari it easy. Just long press on the reload button and choose "reload without content blockers". This'll refresh everything for the page.
OK. That is the last time I'm taking advice from google. I ended up implementing the timestamp trick site-wide to prevent this issue!  Confused
I have added stud logos to the following stud types in the library (the change is pushed to the latest version of the master branch of buildinginstructions.js):

studp01
studel
studa
stud10
stud15
stud17
stud13
stud6


Unfortunately this has surfaced some issues. I recall having read that stud logos should not be mirrored, even when found on mirror geometries. If I can find where this is written, then I can try to "unmirror" logos that are shown.

The issues are documented here: https://github.com/LasseD/buildinginstru.../issues/22

And I am copying them below:


Adding logos on studp01.dat reveals issue with stud rotation on u1454p01.dat
https://www.ldraw.org/parts/official-par...d=u1454p01
See: https://brickhub.org/p/u1454p01



Adding logos on stud15.dat reveals issues with stud rotation on 92947.dat
See: https://brickhub.org/p/92947



Adding logos on stud17.dat reveals the following issues:
For 6042.dat:
https://www.ldraw.org/parts/official-par...artid=6042
using:
https://www.ldraw.org/parts/official-par...=s/6042s01
Logos are only present in the top studs. They all face the same direction ('L' toward the sideways stud section). With s/6042s01.dat being used mirrored, the logos are incorrectly shown.
See: https://brickhub.org/p/6042
For 6032.dat:
https://www.ldraw.org/parts/official-par...=s/6042s01
using:
https://www.ldraw.org/official-part-look...032s01.dat
There should be a logo in the inner stud (The letters 'L' and 'O' are visible in the left side of the real part due to a molding point, while the right inner stud contains an encircled 'C'). Due to no logo being completely visible on the real part, my vote is for not changing the LDraw part to use stud17.dat.
See: https://brickhub.org/p/6032



Adding logos on stud13.dat shows an issue with 4773a.dat where mirroring and rotations result in stud logos being shown wrongly.
See: https://brickhub.org/p/4773a


Adding logos on stud6.dat shows an issue with 17485.dat where rotations result in stud logos being shown wrongly.
https://www.ldraw.org/parts/official-par...rtid=17485
See: https://brickhub.org/p/17485


Edit: If you do not see logos in the brickhub pages, then please visit https://brickhub.org/i/p.php?model=457 (a random parts list) and press the "LEGO" button in the settings below. After this the logos should appear on parts pages as well. I am currently looking into getting this functionality copied to the parts pages so you don't need this workaround.
The 3D part preview seem to be case sensitive.

I made three new files, 3815bpw1c01 - 3815bpw3c01.
They all had code like this:
Code:
1 16 0 0 0 1 0 0 0 1 0 0 0 1 3815b.DAT
1 16 0 12 0 1 0 0 0 1 0 0 0 1 3816bpw3.DAT
1 16 0 12 0 1 0 0 0 1 0 0 0 1 3817bpw3.DAT
None of them showed up in the 3D viewer.

Then I changed two files: 3815bpw1c01 - 3815bpw2c01
Code:
1 1 0 0 0 1 0 0 0 1 0 0 0 1 3815b.dat
1 16 0 12 0 1 0 0 0 1 0 0 0 1 3816bpw2.dat
1 16 0 12 0 1 0 0 0 1 0 0 0 1 3817bpw2.dat
and now they are visible in the 3D viewer.

I left the third file 3815bpw3c01 unchanged.
Ah, this explains why sometimes I see nothing... That said, file names in official library are supposed to be lower case and referenced this way (but a lot of file contain capital letters). LDPE issues a warning for that.
Pages: 1 2 3 4 5 6 7 8 9 10 11