hi...

is there any way to port POV to opengl?


Thanks

Post a reply to this message

Draggy <dra### [at] gmailcom> wrote:
> is there any way to port POV to opengl?

  No.

-- 
Hanki elämä, hanki Linux.
                                                          - Warp

Post a reply to this message

In article <web.42c1137fc739b361d9bc26010@news.povray.org>, 
dra### [at] gmailcom says...
> hi...
> 
> is there any way to port POV to opengl?
> 
Or for a more complex explanation that Warps. No, because OpenGL only 
simulates raytracing using a) triangle meshes, not mathematical formula, 
b) its textures are pre-created, c) its reflection and other light 
features are mapped to objects, not generated by physical models and d) 
pretty much all of it is done using a painter type algorithm, which, 
instead of following a beam of light to see 'what' and 'if' it hit 
something, simply cuts away everything that shouldn't be 'visible' and 
ignores it. Item (d) is why you have to fake reflections, since OpenGL is 
incapable of determining 'if' let alone 'what', 'how many', or 'to what 
degree' light bounces of other objects, before being seen by the camera 
position.

Think of it this way. POVRay sets up a room, some lights and a camera, 
then snaps a photo. OpenGL and DirectX is a guy sitting in a room with an 
exacto knife, who splashes paint over several thousand sheets of paper, 
then uses the knife to 'cut out' every bit that isn't part of the final 
result, pastes them all on on top of the other, *then* takes a photo of 
the result. While this can 'look' very realistic, given a lot of patience 
and careful preparation, some things are impossible and you can't simply 
come back to the same room and stick a camera 'behind' the objects or 
move any lights. Doing so messes up any reflections or other 'effects' 
that have to be carefully 'adjusted' to still look right. I.e., you have 
to cut up entirely new bits, paint them all, then 'hope' you didn't mess 
something up which leaves the table top reflecting the floor, instead of 
the lamp over top of it and similar mistakes. Even OpenGL programs that 
'do' allow that do so by 'precalculating' where the reflections should 
be, then feeding a fake image of that reflection to the OpenGL system as 
a texture. I.e., it uses POVRay style calculations to figure out, "sort 
of", what it should look like, then glues the result to the wall, table, 
mirror, etc. that needs it.

POVRay is an complete machine show with an industrial lathe and a full 
employment of welders. OpenGL is a guy with a box of legos, a few tubes 
of paint and maybe some modelling clay to smooth the more obvious blocky 
bits. Its quite literally a complete impossibility to shoehorn POVRay 
into the later. Though, someone did work on a version that supported a 
'preview' system. It worked by taking the real math, manufacturing a 
bunch of approximate fakes, then showing a cheap imitation of the final 
result. I suspect it never worked too well, or for all objects. Some, 
like isosurfaces could take almost as long to produce a bad imitation, 
than to produce the real thing. This is why things like Moray, etc. that 
'do' use OpenGL, to give a rough idea of what the final result will be, 
don't even try to show some objects, but just stuff a big box, that is 
close to the estimated size expected, in their place.

-- 
void main () {
  If Schrödingers_cat is alive  
    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message

Draggy wrote:
> hi...
> 
> is there any way to port POV to opengl?
> 
> 
> Thanks
> 
> 
Actually I had something simpler in mind.  I have a powerful POV mesh builder at 
my disposal that can generate mesh2 objects, which are potentially exportable to 
other formats.  Getting a piece of software to actually carry this out is 
another matter.  I've seen lots of software for porting 3DS, DXF, etc. to POV 
meshes but not the reverse.

--------------
David Wallace
TenArbor Consulting
"Just In Time Cash"
www.tenarbor.com
1-866-572-CASH

Post a reply to this message

On Tue, 28 Jun 2005 05:08:15 EDT, "Draggy" <dra### [at] gmailcom> wrote:
> is there any way to port POV to opengl?

If that's helpful: http://www.daylongraphics.com/other/povray/patches/

ABX

Post a reply to this message

Warp wrote:
> Draggy <dra### [at] gmailcom> wrote:
> 
>>is there any way to port POV to opengl?
> 
> 
>   No.
> 
Warp and what about DirectX?

Post a reply to this message

Saul F. Luizaga <sau### [at] netscapenet> wrote:
> Warp and what about DirectX?

  Why would it be any easier to convert a pov scene to DirectX than it is
to OpenGL?

-- 
Hanki elämä, hanki Linux.
                                                          - Warp

Post a reply to this message

Warp wrote:

> Saul F. Luizaga <sau### [at] netscapenet> wrote:
> 
>>Warp and what about DirectX?
> 
> 
>   Why would it be any easier to convert a pov scene to DirectX than it is
> to OpenGL?
> 


I don't know too much about programming Warp, that's why I ask you, 
since you're an exoert C/C++ programmer I think you should know. So 
isn't a esay task hah... but it will be a useful feature don't you 
think, as a preview one I mean.

Post a reply to this message

In article <42c40043$1@news.povray.org>, sau### [at] netscapenet says...
> Warp wrote:
> 
> > Saul F. Luizaga <sau### [at] netscapenet> wrote:
> > 
> >>Warp and what about DirectX?
> > 
> > 
> >   Why would it be any easier to convert a pov scene to DirectX than it is
> > to OpenGL?
> > 
> 
> 
> I don't know too much about programming Warp, that's why I ask you, 
> since you're an exoert C/C++ programmer I think you should know. So 
> isn't a esay task hah... but it will be a useful feature don't you 
> think, as a preview one I mean.
> 
DirectX is just a different 'shell' or front end over the same triangle 
mesh technology. Its like asking someone if it would be easier to convert 
their toothbrush into a straight razor or a knife. Odds are pretty god, 
given the basic nature of both, that neither will be acceptable.

-- 
void main () {
  If Schrödingers_cat is alive  
    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message

Saul F. Luizaga <sau### [at] netscapenet> wrote:
> I don't know too much about programming Warp, that's why I ask you, 
> since you're an exoert C/C++ programmer I think you should know. So 
> isn't a esay task hah... but it will be a useful feature don't you 
> think, as a preview one I mean.

  In general, converting pov-scenes to *any* other formats is a very
difficult task.
  For some explanations, see
http://tag.povray.org/povQandT/filesQandT.html#povtootherformatsdifficulty

-- 
Hanki elämä, hanki Linux.
                                                          - Warp

Post a reply to this message

Warp wrote:
> Saul F. Luizaga <sau### [at] netscapenet> wrote:
> 
>>I don't know too much about programming Warp, that's why I ask you, 
>>since you're an exoert C/C++ programmer I think you should know. So 
>>isn't a esay task hah... but it will be a useful feature don't you 
>>think, as a preview one I mean.
> 
> 
>   In general, converting pov-scenes to *any* other formats is a very
> difficult task.
>   For some explanations, see
> http://tag.povray.org/povQandT/filesQandT.html#povtootherformatsdifficulty
> 
Thank you

Post a reply to this message

David Wallace <42c23c0c@news.povray.org> Wednesday 29 of June 2005 08:19

> Actually I had something simpler in mind.  I have a powerful POV mesh
> builder at my disposal that can generate mesh2 objects, which are
> potentially exportable to
> other formats.  Getting a piece of software to actually carry this out is
> another matter.  I've seen lots of software for porting 3DS, DXF, etc. to
> POV meshes but not the reverse.

It would be very nice to have the riverse imho. 
- export from PovRAY
- OpenGL
- better bounding (in example - of very complex objects - by mesh) 

-- 
Rafa� Maj

Post a reply to this message

ABX wrote:
> On Tue, 28 Jun 2005 05:08:15 EDT, "Draggy" <dra### [at] gmailcom> wrote:
> 
>>is there any way to port POV to opengl?
> 
> 
> If that's helpful: http://www.daylongraphics.com/other/povray/patches/
> 
> ABX


If I were to create a mesh (or mesh2) object within SDL, can this patch render 
it using hardware acceleration and save the CPU for other parts of the scene? 
Or will it have to wait for 3.7's multithreading and pass the threads for mesh 
handling to the GPU?

--------------
David Wallace
TenArbor Consulting
"Just In Time Cash"
www.tenarbor.com
1-866-572-CASH

Post a reply to this message

David Wallace <dar### [at] earthlinknet> wrote:
> If I were to create a mesh (or mesh2) object within SDL, can this patch render 
> it using hardware acceleration and save the CPU for other parts of the scene? 
  How exactly do you assume that the GPU will be able to render the
procedural textures applied to the mesh?
  What happens if this texture and reflection and/or refraction? What
happens if there's media inside the mesh?
  What happens if there's a primitive in front of the mesh, partially
obscuring it? How will the GPU be able to tell which parts to render
and which don't?
  How will the GPU handle antialiasing, especially at the borders of the
mesh, where it should be antaliased against whatever is behind (ie the
rest of the scenery)?
  How will the GPU handle special lighting, such as area lights?

> Or will it have to wait for 3.7's multithreading and pass the threads for mesh 
> handling to the GPU?

  There are no "threads for mesh handling" in POV-Ray 3.7. Each thread
renders one square of the image (when it's done, it starts rendering the
next free square).

-- 
Hanki elämä, hanki Linux.
                                                          - Warp

Post a reply to this message

David Wallace wrote:

> If I were to create a mesh (or mesh2) object within SDL, can this patch 
> render it using hardware acceleration and save the CPU for other parts 
> of the scene? Or will it have to wait for 3.7's multithreading and pass 
> the threads for mesh handling to the GPU?

Repeat after me:

Povray is apples GPU is oranges. Under no circumstance can you squeeze 
an orange and expect apple juice. (Raytracing is a completely different 
beast from scanline renderers. GL would be fine for previews, but not 
the final render. You would have to define shaders and textures to work 
with the scanline renderer built inside your GPU. At best, this could do 
a pretty decent job of faking what POV-Ray does, but will not under any 
circumstances be able to render portions of a POV-Ray engine. If you 
want to use scanline techniques, I'd suggest looking for scanline 
renderers.
-- 
~Mike

Things! Billions of them!

Post a reply to this message

Warp wrote:
> David Wallace <dar### [at] earthlinknet> wrote:
> 
>>If I were to create a mesh (or mesh2) object within SDL, can this patch render 
>>it using hardware acceleration and save the CPU for other parts of the scene? 
> 
>   How exactly do you assume that the GPU will be able to render the
> procedural textures applied to the mesh?
>   What happens if this texture and reflection and/or refraction? What
> happens if there's media inside the mesh?
>   What happens if there's a primitive in front of the mesh, partially
> obscuring it? How will the GPU be able to tell which parts to render
> and which don't?
>   How will the GPU handle antialiasing, especially at the borders of the
> mesh, where it should be antaliased against whatever is behind (ie the
> rest of the scenery)?
>   How will the GPU handle special lighting, such as area lights?
> 
> 
>>Or will it have to wait for 3.7's multithreading and pass the threads for mesh 
>>handling to the GPU?
> 
> 
>   There are no "threads for mesh handling" in POV-Ray 3.7. Each thread
> renders one square of the image (when it's done, it starts rendering the
> next free square).
> 

What I'm really after is Hardware-Accelerated Mesh Geometry: the capacity to 
take advantage of the specialized commands in GPUs (shaders) and/or CPUs (3DNow, 
SSEn, etc.) that have been developed to accelerate rendering of such objects, 
especially in games.  Textures are a separate operation.

Can such operations be integrated into raytracing, at least at the object 
geometry level?

--------------
David Wallace
TenArbor Consulting
"Just In Time Cash"
www.tenarbor.com
1-866-572-CASH

Post a reply to this message

David Wallace <dar### [at] earthlinknet> wrote:
> What I'm really after is Hardware-Accelerated Mesh Geometry: the capacity to 
> take advantage of the specialized commands in GPUs (shaders) and/or CPUs (3DNow, 
> SSEn, etc.) that have been developed to accelerate rendering of such objects, 
> especially in games.  Textures are a separate operation.

  What do you mean textures are a separate operation?

  What you see from a mesh is precisely its texture (which has been
lightened/darkened according to lighting calculations). The mesh has
to have *some* texture in order to be seen.
  It's not like POV-Ray could somehow render the mesh with OpenGL and
afterwards apply the procedural texture to it.

-- 
Hanki elämä, hanki Linux.
                                                          - Warp

Post a reply to this message

Warp wrote:
> David Wallace <dar### [at] earthlinknet> wrote:
> 
>>What I'm really after is Hardware-Accelerated Mesh Geometry: the capacity to 
>>take advantage of the specialized commands in GPUs (shaders) and/or CPUs (3DNow, 
>>SSEn, etc.) that have been developed to accelerate rendering of such objects, 
>>especially in games.  Textures are a separate operation.
> 
> 
>   What do you mean textures are a separate operation?
> 
>   What you see from a mesh is precisely its texture (which has been
> lightened/darkened according to lighting calculations). The mesh has
> to have *some* texture in order to be seen.
>   It's not like POV-Ray could somehow render the mesh with OpenGL and
> afterwards apply the procedural texture to it.
> 

OpenGL determines the mesh object's location in space, then passes that data to 
the traditional raytracer, which in turn determines the texture, highlights, 
reflection, etc.

--------------
David Wallace
TenArbor Consulting
"Just In Time Cash"
www.tenarbor.com
1-866-572-CASH

Post a reply to this message

David Wallace <dar### [at] earthlinknet> wrote:
> OpenGL determines the mesh object's location in space, then passes that data to 
> the traditional raytracer, which in turn determines the texture, highlights, 
> reflection, etc.

  In order to do that, the raytracer would need to know the exact
intersection point and the normal vector of the triangle. Transferring
this information for each pixel (in fact, many times for each pixel
if antialiasing is being used) from the 3D card to the CPU might not
be the fastest operation possible.

  Besides, that's not the only thing that had to be done. The raytracer
would need to know if there's another surface in front of the mesh in
the current pixel, it will need to perform shadow-ray testing (which
has to include the mesh itself) and if the mesh is semi-transparent
or has a reflective texture, it will have to send more rays (I think
it would not be possible to use the 3D card for these deeper
recursions). Also if the mesh is reflected in another surface it
will need to be raytraced.

  Calculating the intersection between the ray and the mesh isn't the
slowest operation involved. It's very questionable whether a 3D card
would help speeding up the process at all.

  (When a 3D card draws a mesh all by itself, it doesn't have to move
data to the CPU, it will use its own hardware-accelerated texturing
functions and will not have to worry about shadows, reflections and
so on. That's why it's fast that way.)

-- 
Hanki elämä, hanki Linux.
                                                          - Warp

Post a reply to this message