OMR Model Render

[Orion Pobursky]

A progress bar would be a great idea, but my attempts to create one have failed as it has decreased the loading speed significantly. I will have to check StackOverflow for some pointers.

The 'Feet' issue might be due to the debth buffer issue mentioned earlier. I have also observed it with other large models which are not on wheels.

How is the general feeling of prioritization? Right now my list is:

1) Fix rendering issues (this includes what you mention here, but also the UV calculation as you can see there are still many warnings generated in the log)
2) Stud logos (while studs can easily be enabled by setting a parameter, my experience is that the file size doubles and rendering time doubles as well. I am working on a light-weight alternative)
3) Control buttons to set up camera, lights, etc.
4) Progress bar
5) Better support of transparency.
6) Support of illumination parts (such as glow-in-the-dark ghosts, etc.)
7) Distance-based blur for a more realistic rendering
8) Textures
9) Geometry culling (such as removing studs that cannot be seen)


And of course, everyone is welcome to take up a task and create pull requests - it is all open source / license free

This thread is getting unwieldy. I'm going to start a new one.

[Lasse Deleuran]

I have pushed a new commit to the source code which speeds up rendering time significantly for older hardware by not generating textures, but rather load them asynchronously as images.

Rendering transparent parts using a custom shader still fails spectacularly. 


There are multiple issues here. 

One is of precision. I am writing depths in pixel colors, which is far from ideal when there are multiple layers of faces hitting the same pixel.

Another issue is the stud and anti-stud geometries. For obvious reasons we do not have the disc on the bottom of a stud. However. This asymmetry causes the renderer to think the missing geometry should be rendered completely light or dark, depending on wether the missing geometry is facing toward or away from the camera.

Still. The biggest issue is with precision an transferring enough data to perform direct volumetric rendering:


Many days have gone studying and testing... many more are to be spent.

But imagine if we suddenly had realistic transparent LEGO part rendering without raytracing... it would be a game changer!

[Lasse Deleuran]

I have added dat.GUI to set up the scene - see sample_physical.htm and call "scene.setUpGui()".

With this, I would like to revisit the state of the physical renderer:

1. Fix rendering issues This seems to be at a tolerable level. Right now the largest issues seem to come from line 2's partially overlapping line 5's.
   
2. Stud logos DONE using textures
   
3. Control buttons to set up camera, lights, etc. DONE using dat.GUI
   
4. Progress bar DONE using animated construction
   
5. Better support of transparency. WIP. From my prodding in the rendering communities, this seems to be very hard, and perhaps worthy of a research paper if I can create real-time realistic rendering of transparent elements
   
6. Support of illumination parts (such as glow-in-the-dark ghosts, etc.) MISSING
   
7. Distance-based blur for a more realistic rendering MISSING
   
8. Textures DONE: All 3 types of projection, as well as inline textures. Only issue is clamping where the standard clamping from three.js materials stretches textures to edges.
   
9. Geometry culling (such as removing studs that cannot be seen) WIP I am looking into the use of InstancedMesh for quicker rendering using less ressources.
   

I am currently looking into performance optimizations, such as #9 on the list. What is the general feeling for the readiness of this code base? Are there aspects you would like to see me improve further before proposing a release?

[Lasse Deleuran]

With inline textures now being officially part of the standard (see https://forums.ldraw.org/thread-24058.html ), I have removed the warning when using them.

The next improvement will likely be to include glow-in-dark effect for those parts as a recent development gave me a nice and somewhat easy way of getting this implemented.

Are there other issues that you would like to see fixed for OMR rendering?

[Roland Melkert]

With inline textures now being officially part of the standard (see https://forums.ldraw.org/thread-24058.html ), I have removed the warning when using them.

Are there already models actually using !DATA in the omr?

I seem to remember you experimenting with this, but I believe it used one of the older versions of the proposal (the one with 'sub-subfiles').

Or maybe the better question is: are there currently any models in the OMR which depend on unofficial textured parts?

[N. W. Perry]

Are there already models actually using !DATA in the omr?

I seem to remember you experimenting with this, but I believe it used one of the older versions of the proposal (the one with 'sub-subfiles').

Or maybe the better question is: are there currently any models in the OMR which depend on unofficial textured parts?

One of mine does, at least: https://forums.ldraw.org/thread-7689-pos...l#pid35244

[Lasse Deleuran]

Are there already models actually using !DATA in the omr?

I seem to remember you experimenting with this, but I believe it used one of the older versions of the proposal (the one with 'sub-subfiles').

Or maybe the better question is: are there currently any models in the OMR which depend on unofficial textured parts?

Yes, I started implementing it back when the proposed standard said "0 FILE... 0 !DATA START" and since I uploaded some files between then and now, the latest version of the code is now able to parse both of these as well as the Studio version of inlined textures.

Output can be either to this latest LDraw format version or to Studio. See This model as an example:



When pressing "Download" the OMR version refers to the stickers as separate parts. These can be downloaded in the table below in either "LDraw" or "Studio" versions. The LDraw versions are structured as follows:

Code:

0 FILE sticker_30342_1.dat
0 Sticker 1 for 30342
0 Name: sticker_30342_1.dat
0 Author: Sticker Builder
0 !LICENSE Redistributable under CCAL version 2.0 : see CAreadme.txt
0 BFC CERTIFY CCW

0 !TEXMAP START PLANAR -8 0.5 -39 -8 0.5 39 8 0.5 -39 sticker_30342_1.dat.png
0 !: 3 16 8 0 -39 8 0 39 -8 0 39
0 !: 3 16 8 0 -39 -8 0 39 -8 0 -39
0 !TEXMAP END
1 16 0 0 0 8 0 0 0 0.5 0 0 0 39 box5.dat

0 !DATA sticker_30342_1.dat.png
0 !: iVBORw0KGgoAAAANSUhEUgAAAQAAAABACAIAAAB6Pz7pAAAAAXNSR0IArs4c6QAAAARnQU1BAACx
0 !: jwv8YQUAAAAJcEhZcwAAEnQAABJ0Ad5mH3gAACRfSURBVHhe7X1ZrCXXdd3ZZ6jpjm/s1wO7m5M4
...

I will update some of the stickers to not use Texmap before I submit this model.

[Orion Pobursky]

With inline textures now being officially part of the standard (see https://forums.ldraw.org/thread-24058.html ), I have removed the warning when using them.

The next improvement will likely be to include glow-in-dark effect for those parts as a recent development gave me a nice and somewhat easy way of getting this implemented.

Are there other issues that you would like to see fixed for OMR rendering?

There's nothing on my end other than time to modify and test the OMR to use buildlinginstructions.js instead of brigl.

I'm gonna try to include the option to have either the instructions style render or the photoreal render. That's not an issue with your code.

[Lasse Deleuran]

There's nothing on my end other than time to modify and test the OMR to use buildlinginstructions.js instead of brigl.

I'm gonna try to include the option to have either the instructions style render or the photoreal render. That's not an issue with your code.

Alright. The switch between the two renderers is just matter of setting the option "physicalRenderingAge" to 0 or 1 as seen in sample_physical.htm and sample_view.htm, respectively.

[Orion Pobursky]

Alright. The switch between the two renderers is just matter of setting the option "physicalRenderingAge" to 0 or 1 as seen in sample_physical.htm and sample_view.htm, respectively.

Now that I've done the legwork to clean up the code base, I'm almost ready to roll out to the OMR. The last issue would be to improve the lighting model in physical render mode. Looks kinda dark to me. Any suggestions?

The model viewer under the "Tools" menu uses the current code which is pretty much identical, lighting-wise, to Scene.js. You'll have to switch to physical render mode with the "eye" button.

[Lasse Deleuran]

Now that I've done the legwork to clean up the code base, I'm almost ready to roll out to the OMR. The last issue would be to improve the lighting model in physical render mode. Looks kinda dark to me. Any suggestions?

The model viewer under the "Tools" menu uses the current code which is pretty much identical, lighting-wise, to Scene.js. You'll have to switch to physical render mode with the "eye" button.

Well done! My proposal for decreasing the darkness is to bump the intensity parameter of the Hemisphere light:

new THREE.HemisphereLight(... 0.65);

to

new THREE.HemisphereLight(... 0.85);

[Orion Pobursky]

Well done! My proposal for decreasing the darkness is to bump the intensity parameter of the Hemisphere light:

new THREE.HemisphereLight(... 0.65);

to

new THREE.HemisphereLight(... 0.85);

I switched from a hemisphere light to an ambient light and two directional lights. I'm pretty satisfied with the result so I'll probably implement on the OMR soon.