-
Notifications
You must be signed in to change notification settings - Fork 68
Improve the drop-in-replacement engine aspect #84
Comments
Wonderful suggestions! Converting Textures are only loaded to the GPU on initialization of the renderer, so async loading of textures aren't easy to support with the current implementation. I think it's a good idea to get full async texture support. I'll look into it and see what it'll take, but I was having difficulties in the past because of how we're packing textures inside a WebGL Array Texture. At the very least we can prevent crashing. Texture repeating also isn't supported yet (#59) since it's a little tricky to implement in the ray tracing shader. But there is a way to do it. I suppose this is a high priority? |
Not for me ATM; it would be nice, but it is not urgent; I can mirror textures myself and use these... |
In the meantime, as long as there are missing features from the renderer, I created a wiki page which lists what's supported. https://github.com/hoverinc/ray-tracing-renderer/wiki/Three.js-Compatibility This should serve as a reference to what should currently work, so there's less confusion about what's supported and what's not. We could link to this page in the readme in the Limitations section. Does it look okay to you? Is there something you'd change or add? |
And also, I'll be working on the PR in the next week that fixes anything that crashes the renderer. You mentioned
Are there any other cases you discovered that flat-out crash the renderer? |
Great news! However, if you do make an update, I can imagine 2 things that might be easy to add as well:
|
Somehow I managed to miss this message; great idea! Looks good.... |
Context
This engine is intended to be used as a drop-in replacement to Three.js’s
WebGLRenderer
.Problem
It tends not to work as a drop-in replacement out-of-the-box, because the renderer crashes when:
THREE.Geometry
instead of aTHREE.BufferGeometry
.This might cause people who try to replace the
WebGLRenderer
withRayTracingRenderer
to drop out early, because 'it does not work as promised' out-of-the box.This would be a shame, because if you get it up and running, it works great.
Solution
In my engine I have provided a few simple workarounds for these issues by pre-processing the
THREE.Object3D
before I attach it to the scene; this is an excerpt from the code:Proposal
As I can imagine that I am not the only one experiencing these issues, and intercepting these cases is probably not rocket science, I wonder if you would be open to intercept any
THREE.Geometry
instances and convert these toTHREE.BufferGeometry
.As for the invalid materials, I would suggest to replace invalid instances with a
placeholderMaterial
, which could be specified in theparams
upon startup.The text was updated successfully, but these errors were encountered: