 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
<ber### [at] iname com> wrote:
> I agree completely. Unfortunately, for this to be possible would require
> either a change of the POV license or a special exception.
Why? The POV license doesn't have any restrictions on how you can
generate .pov files, just on how you can use the POV-Ray program and
source code. As long as the simulator doesn't take any POV source code,
there would be no problem.
You could also build OpenGL preview capability into POV itself...the
result would be more flexible and a lot more popular. ;-)
--
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
<><
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> use the tools that work best for you). POV is a rendering engine: its
> function is to take a scene description and output an image or a
> sequence of images, since a cloth simulator outputs a mesh (or a set of
> points) it has no place inside a rendering engine and should be used as
> an external tool.
While I understand what you mean from a conceptual point of view,
there are clear advantages for making it built-in. Clothray, working
"internally" has the ability to use ANY simple or complex POV-Ray
object as obstacle for the cloth. Of course, external processing
would be the ideal way, but how could you keep such advantages
externally ?
Maybe, someday, POV-Ray 4's more modular architecture could allow
that, by calling relevant parts of the engine. But, until then...
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff wrote:
> And why shouldn't cloth be part of the scene description? Just
> because it's reduced to a mesh? Then what about height fields and
> bezier patches? I see the scene language as just another way of
> accessing the render engine, and think that this type of thing has
> every right to be there...it just makes the language more
> flexible.
It could, but that would mean recomputing the cloth at each render which
would be very slow. The difference between a cloth and an height field
or a bezier patch is that those are converted to a mesh on the fly and
then this mesh is used for the render, whereas the cloth is output to a
file as a mesh and then you need to restart pov to render this mesh.
Jerome
--
* Abandon the search for truth, * mailto:ber### [at] inamecom
* Settle for a good fantasy. * http://www.enst.fr/~jberger
*********************************
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fabien Mosen wrote:
> While I understand what you mean from a conceptual point of view, there
> are clear advantages for making it built-in. Clothray, working
"internally"
> has the ability to use ANY simple or complex POV-Ray object as
> obstacle for the cloth. Of course, external processing would be
> the ideal way, but how could you keep such advantages externally ?
>
> Maybe, someday, POV-Ray 4's more modular architecture could allow that,
> by calling relevant parts of the engine. But, until then...
>
And provided the license is changed to allow it, yes I agree. OTOH it is
possible to use certain simplifications in an external simulator that
allow it to compute faster than an internal one could ever hope to
achieve...
Jerome
--
* Abandon the search for truth, * mailto:ber### [at] inamecom
* Settle for a good fantasy. * http://www.enst.fr/~jberger
*********************************
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff wrote:
> Why? The POV license doesn't have any restrictions on how you can
generate
> .pov files, just on how you can use the POV-Ray program and source
> code. As long as the simulator doesn't take any POV source code, there
> would be no problem.
Exactly, but to do what he said, you would have to take the POV source
code for intersection with objects...
Jerome
--
* Abandon the search for truth, * mailto:ber### [at] inamecom
* Settle for a good fantasy. * http://www.enst.fr/~jberger
*********************************
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Then I say, make it built-into POV and make a macro to output the cloth to a
file.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
<ber### [at] inamecom> wrote:
> Exactly, but to do what he said, you would have to take the POV source
> code for intersection with objects...
No you wouldn't...supporting every single POV feature would be too much
work, but interaction with the basic objects and a simple description
language wouldn't require any POV source.
--
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
<><
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
<ber### [at] inamecom> wrote:
> It could, but that would mean recomputing the cloth at each render which
> would be very slow.
What about cloth simulation *requires* this? It could easily be kept as
a persistent object, like the particle_system patch, or have data stored
in a temporary file, like radiosity or photon mapping.
> The difference between a cloth and an height field or a bezier patch
> is that those are converted to a mesh on the fly and then this mesh
> is used for the render, whereas the cloth is output to a file as a
> mesh and then you need to restart pov to render this mesh.
Again, why? A cloth object patch could easily convert to a mesh on the
fly. No need to output a mesh to a file or restart POV.
What is different about cloth that it can't be done like height fields,
bezier patches, or the particle_system?
--
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
<><
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff wrote:
> <ber### [at] inamecom> wrote:
>
> > It could, but that would mean recomputing the cloth at each render which
> > would be very slow.
>
> What about cloth simulation *requires* this? It could easily be kept as
> a persistent object, like the particle_system patch, or have data stored
> in a temporary file, like radiosity or photon mapping.
Cloth is simulated over time - a static model is not. If cloth were implemented in
POV, you would have to specify how much time you want to step the simulation before
doing the rendering. Too little time means that the cloth hasn't finished falling
and covering the area. Too much time and the cloth could have fallen right off your
surface. If you were to create an animation with cloth, you would have to simulate
from the start of the cloth simulation to the proper point in the scene. Unless you
have some way of rendering multiple scenes in POV without stopping, you'd have to
recalculate that each frame and it would take longer each time.
Having said all that, it's possible to write the cloth simulation as part of POV or
as a separate utility. The problem with a separate utility is that you have to
re-implement all of the POV shapes in the utility. Incidently, the cloth-surface
intersection calculations are the same ones used for ray-surface intersection
already implemented in POV, so all the existing shapes could be supported for the
cloth to drape over.
David Buck
dav### [at] simberoncom
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3AA0CFB4.F8F047C3@simberon.com>, David Buck
<dav### [at] simberoncom> wrote:
> Cloth is simulated over time - a static model is not. If cloth were
> implemented in POV, you would have to specify how much time you want
> to step the simulation before doing the rendering.
My particle_system patch is also a dynamic system...you specify the
number of iterations to use and the amount of time it spans.
> Too little time means that the cloth hasn't finished falling and
> covering the area. Too much time and the cloth could have fallen
> right off your surface. If you were to create an animation with
> cloth, you would have to simulate from the start of the cloth
> simulation to the proper point in the scene. Unless you have some
> way of rendering multiple scenes in POV without stopping, you'd have
> to recalculate that each frame and it would take longer each time.
You mean rendering without constantly re-parsing the scene? That isn't
possible yet, but you can render multiple images without recomputing the
entire cloth system each time. Either save the system to a file at each
frame with a save_file keyword, like radiosity or photon mapping, or
assign it to a persistent variable that is saved from frame to frame.
--
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
<><
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
