Raytracing in OpenGL or Vulkan?

Question

I was looking at this glass ball rendering with an image inside of it (zoom out to see the glass ball), and noticed that it looks like they simulate the refraction of light as it crosses from inside of the glass ball to the air outside. I know that you can achieve this either by rendering to a texture and then using that texture on the surface of the transparent object, or moving the vertices of objects inside/behind the transparent object, but both of those methods are problematic in my situation.

I want to simulate the transition between two spaces where light bends differently (If you will, you can think of it kind of like I'm entering a worm hole and ending up at another location), and you should be able to smoothly transition between the two spaces without being able to see the transition. For the rendering, the boundary between the two spaces can simply be treated as a refracting surface, and I would like to use ray tracing to achieve this refraction, where I only trace a single refracting ray and no reflecting ray. For this, I have some questions:

1. Is it possible to trigger OpenGL to render a new image consisting of just one pixel for the refracted ray in the main function in the fragment (pixel?) shader? This would allow me to rely on a lot of functionality that already exists in OpenGL which I imagine that I would otherwise have have to implement myself, such as testing intersections between the ray and polygons in the scene, and interpolation of vertex values to the point on the polygon that was hit. If I could trigger OpenGL to render a new image, this would also make it easier to get a more consistently rendered image, as I want to avoid getting an image that changes discontinuously when I transition from being on one side of the boundary to being on the other side of the boundary.

2. If it is not possible to trigger the rendering of a new, single-pixel image in the main function in the fragment shader in OpenGL, does Vulkan, which is supposed to be more powerful, offer this possibility?

3. If I can't trigger OpenGL or Vulkan to render a new image in the main function in the fragment shader, do I have to manually calculate which polygon the refracted ray hits and where on it it hits, or can I still get OpenGL/Vulkan to do that automatically for me somehow? If I have to calculate this manually, how can I do that most easily? Does OpenGL/Vulkan provide me with some functions that can make this process easier for me?

4. Also, for the refracted ray, can I make OpenGL/Vulkan call the main function in the fragment shader with the appropriate interpolated values for all variables (like it does normally) for each successive hit, or do I have to interpolate those manually somehow too? Again, does OpenGL/Vulkan provide me with some functions that can make this process easier for me if I have to do it manually?

Answer 1

Is it possible to trigger OpenGL to render a new image consisting of just one pixel for the refracted ray in the main function in the fragment (pixel?) shader?

OpenGL does not know what your data is. It only knows what you tell it. It knows that you've bound some buffers and submitted some commands to render with them. It doesn't keep track of that information after it has processed those commands.

In short, it doesn't know what your scene is. So even if a fragment shader could provoke rendering (which it cannot), it wouldn't know what to render.

If it is not possible to trigger the rendering of a new, single-pixel image in the main function in the fragment shader in OpenGL, does Vulkan, which is supposed to be more powerful, offer this possibility?

No.

What Vulkan has is an (optional) raytracing rendering pipeline. It involves building data structures that represent "the scene" in some way, as well as dealing with a bunch of different shader stages that can create, test, and manipulate rays.

This is not a simple system and it doesn't work at all like the standard rasterization graphics pipeline. It's also Vulkan (or D3D12) only, as the complexities of it are too great for OpenGL as an API to handle.