 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I keep on watching the speed at which real time GPU ray tracing / light
transport technology advances.
It seems quite amazing.
So, let's say hypothetically at what version POV-ray would have to fork so that
its SDL is entirely covered by NVIDIA Vulkan Ray Tracing API as of today ?
I am currently reading that tutorial
https://nvpro-samples.github.io/vk_raytracing_tutorial_KHR/
the tutorial specifies : plain colors, textures, diffuse and specular
reflections, lighting. no transparency for now.
Seems we are in povray 1.0 territory.
I will browse the reference to see if there are now more documented features
since the tutorial webpage date is May 2020)
The goal being to make both rendering pipelines meet where the least of code is
required for the glue.
I think i will try a hello world by converting biscuit.pov into Vulkan TLAS/BLAS
and trying a render.
To be honest, I think it is a matter of a couple of years that fast GPU assisted
ray traced
render is achieved at the levels of POV Ray 3.6, since in December 2020 Nvidia
was already implementing caustics (using POV-Ray as a reference on the matter by
the way)
https://developer.nvidia.com/blog/generating-ray-traced-caustic-effects-in-unreal-engine-4-part-1/
let's be clear rendering time is the top factor in the game now. Always has
been.
As a reference and a dean in the game of RAY tracing, I think that porting
POV-Ray SDL to the recent hardware advancement is fair game, could be done as a
tribute, that NVIDIA could even handle in part, but that's more of a political
issue, and it's just an humble advice, since the workload could be quite big.
It is probable the that NVIDIA engineers browse POV-Ray codebase.
Maybe there is a possibility to make the Vulkan ray tracing capabilities grow in
tandem with those of povray. so that porting would be easier.
If there is one thing that would be an absolute hit, it is a povray 4.0 renderer
that renders in an instant, even if some SDL directives have to be ignored for
that at the moment.
What do you think ?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2022-11-04 à 15:40, rodv92 a écrit :
> I keep on watching the speed at which real time GPU ray tracing / light
> transport technology advances.
> It seems quite amazing.
>
>
>
> So, let's say hypothetically at what version POV-ray would have to fork so that
> its SDL is entirely covered by NVIDIA Vulkan Ray Tracing API as of today ?
>
> I am currently reading that tutorial
> https://nvpro-samples.github.io/vk_raytracing_tutorial_KHR/
>
> the tutorial specifies : plain colors, textures, diffuse and specular
> reflections, lighting. no transparency for now.
> Seems we are in povray 1.0 territory.
>
> I will browse the reference to see if there are now more documented features
> since the tutorial webpage date is May 2020)
>
> The goal being to make both rendering pipelines meet where the least of code is
> required for the glue.
>
> I think i will try a hello world by converting biscuit.pov into Vulkan TLAS/BLAS
> and trying a render.
>
>
> To be honest, I think it is a matter of a couple of years that fast GPU assisted
> ray traced
> render is achieved at the levels of POV Ray 3.6, since in December 2020 Nvidia
> was already implementing caustics (using POV-Ray as a reference on the matter by
> the way)
>
>
https://developer.nvidia.com/blog/generating-ray-traced-caustic-effects-in-unreal-engine-4-part-1/
>
> let's be clear rendering time is the top factor in the game now. Always has
> been.
>
> As a reference and a dean in the game of RAY tracing, I think that porting
> POV-Ray SDL to the recent hardware advancement is fair game, could be done as a
> tribute, that NVIDIA could even handle in part, but that's more of a political
> issue, and it's just an humble advice, since the workload could be quite big.
>
>
>
> It is probable the that NVIDIA engineers browse POV-Ray codebase.
> Maybe there is a possibility to make the Vulkan ray tracing capabilities grow in
> tandem with those of povray. so that porting would be easier.
>
> If there is one thing that would be an absolute hit, it is a povray 4.0 renderer
> that renders in an instant, even if some SDL directives have to be ignored for
> that at the moment.
>
> What do you think ?
>
>
>
>
GPU render assume that everything will use the same code : The code for
a mesh of polygons. That assumption comes from the obligation to use the
same code for all cores.
POV Ray use many primitives. All of the primitives need to use their own
code. So, a GPU version of POV Ray could only deal with one primitive
type at a time. Render all the spheres, then, render all the boxes, then
the torus, then the cones and cylinders, then...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain Martel <kua### [at] videotron ca> wrote:
> > I keep on watching the speed at which real time GPU ray tracing / light
> > transport technology advances.
> > It seems quite amazing.
> GPU render assume that everything will use the same code : The code for
> a mesh of polygons. That assumption comes from the obligation to use the
> same code for all cores.
> POV Ray use many primitives. All of the primitives need to use their own
> code. So, a GPU version of POV Ray could only deal with one primitive
> type at a time. Render all the spheres, then, render all the boxes, then
> the torus, then the cones and cylinders, then...
Well that, or code a fork that converts all the primitives into polygon meshes
before rendering. Or just add in mesh alternatives for all of the primitives in
case someone wants to use them... It probably can't be that hard to copy most
of the primitives into macro-driven mesh alternatives, especially since most of
them could just be rendered as parametric surfaces that are made with triangle{}
or mesh{} or mesh2{} objects, not the parametric{}. Then you could just use
the same macro code and pass in the relevant equations for x, y, and z as
arguments.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
