 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Saul F. Luizaga <sau### [at] netscape net> 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)
--
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).
--
- 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.
--
- 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.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
