This could be a feature down the line I suppose, but yes I would probably help. At the moment I think updating the rendering pipeline might be more important.
Design Raytracing Renderer
- Thread starter manu3d
- Start date
found the video.
acterhd
New Member
I thinking about ray tracing support in Terasology.
But some embarrassing moments ... the problem is that to build HLBVH need sorting. To date I have not found any sort (Morton code) method for the OpenGL, CUDA only with interop (only hardcore?), OpenCL version also exists, but it turned out that does not work.
But alas terasology written in Java, where CUDA is impossible, and cross-platform is critical.
But some embarrassing moments ... the problem is that to build HLBVH need sorting. To date I have not found any sort (Morton code) method for the OpenGL, CUDA only with interop (only hardcore?), OpenCL version also exists, but it turned out that does not work.
But alas terasology written in Java, where CUDA is impossible, and cross-platform is critical.
One stepping stone could be to implement ray-traced shadows, initially only for the main light. It will still require a fair amount of effort, but it considerably restricts the complexity of the algorithm needed as rays only need to check if the hit something or not: they do not need to look at the characteristics of what they hit. Given the limitations of our current shadows implementation working this out would be a very good first step in the world of raytracing and a very useful proof of concept.
That video is really convincing, I just wonder if it is possible to get a decent framerate with it...
@acterhd The newer OpenGL has the Compute Shader, which is very similar to what cuda and opencl can do. And it should also be possible to query the user's pc if the graphics card can do compute shaders, so that would fit cross-compatibility.
@acterhd The newer OpenGL has the Compute Shader, which is very similar to what cuda and opencl can do. And it should also be possible to query the user's pc if the graphics card can do compute shaders, so that would fit cross-compatibility.
I should mention Terasology still uses OpenGL 2.1 plus a few extensions. Of course offering parallel rendering implementation using more modern OpenGL specifications would be welcome and has been discussed a number of times: it's all a matter of human resources.
One thing that would potentially fragment the workload is to think in terms of capability-oriented rendering nodes. Right now the nodes in the rendering engine assume a set of capabilities established through checks done in LwjglGraphics.checkOpenGL(). What could be done is to move those checks on rendering engine and module initialization. Depending on what capabilities the engine/module finds it could provide different implementations of the same rendering node, i.e. one taking advantage of a more modern OpenGL release. This way we could potentially migrate the rendering engine node-by-node rather than in one big step.
That been said, shaders are currently provided by the Terasology distribution as resources and are all relying on OpenGL 2.1. To do a more piece-meal migration nodes would have to become responsible for publishing or obtaining the shaders they require.
Also the UI is currently not integrated with the renderer and I don't know how easy/fragmentable it would be to migrate it to a more modern OpenGL release. So, in that context I don't know how easily it would be to leave OpenGL 2.1. behind.
It's all possible though, it would certainly be a good thing! =)
One thing that would potentially fragment the workload is to think in terms of capability-oriented rendering nodes. Right now the nodes in the rendering engine assume a set of capabilities established through checks done in LwjglGraphics.checkOpenGL(). What could be done is to move those checks on rendering engine and module initialization. Depending on what capabilities the engine/module finds it could provide different implementations of the same rendering node, i.e. one taking advantage of a more modern OpenGL release. This way we could potentially migrate the rendering engine node-by-node rather than in one big step.
That been said, shaders are currently provided by the Terasology distribution as resources and are all relying on OpenGL 2.1. To do a more piece-meal migration nodes would have to become responsible for publishing or obtaining the shaders they require.
Also the UI is currently not integrated with the renderer and I don't know how easy/fragmentable it would be to migrate it to a more modern OpenGL release. So, in that context I don't know how easily it would be to leave OpenGL 2.1. behind.
It's all possible though, it would certainly be a good thing! =)
Thank you @acterhd for your research!
If it can be of any consolation, people tend to overestimate what they can do in one year and underestimate what they can do in ten.
Let me know if you'd like to contribute to the current work on the renderer. There currently is a PR available for review if you feel like starting slowly.
If it can be of any consolation, people tend to overestimate what they can do in one year and underestimate what they can do in ten.
Let me know if you'd like to contribute to the current work on the renderer. There currently is a PR available for review if you feel like starting slowly.
Spotted this via Reddit, seemed relevant: https://raytracedminecraft.wordpress.com
Looking at the last 2 videos, I don't see the improvements I'd expect from a raytracer. For example (soft) shadows (I don't see shadows at all?), light sources, reflective/refractive surfaces with rough textures. Also DX12 is... pretty restrictive on OS+Graphics Card, but hopefully it can inspire with ideas.