LDraw.org Discussion Forums

Full Version: OMR Model Render
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
(2019-09-04, 7:31)Lasse Deleuran Wrote: [ -> ]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.
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. 

[Image: yVgBKsj.png]
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:

[Image: QOnHPkQ.png]
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!
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?
Pages: 1 2 3 4 5 6