 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Anyone had a chance to play with this much? I was just taking a look at
it recently at http://tofbouf.free.fr/clothray/index_en.html
Looks schweet..
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas Charron wrote:
>
> Anyone had a chance to play with this much? I was just taking a look at
> it recently at http://tofbouf.free.fr/clothray/index_en.html
>
> Looks schweet..
Well, as the author of this patch, the answer is... hum... yes.
If you have the (great) chance to speak french (or have a little
understanding of it), you can look at:
http://tofbouf.free.fr/clothray/tut01.html
There's a tutorial (not finished yet)...
It will probably be translated in english after the end of this IRTC
round...
Just an example of what can be achieved....
Bouf.
Post a reply to this message
Attachments:
Download 'dblmesh.jpg' (26 KB)
Preview of image 'dblmesh.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Oh, that's a nice one! I like the structure of the cloth.
Marc-Hendrik
Post a reply to this message
|
|
| |
| |
|
|
From: Thomas Charron
Subject: Re: Clothray cloth simulation patch..
Date: 19 Feb 2001 12:35:34
Message: <3a915966@news.povray.org>
|
|
|
| |
| |
|
|
VERY nice. I'm definatly looking forward to this.. :-) It would have
assisted in my most-likely-wont-be-finished-in-time entry, where I modeled a
hanging cloak in sPatch for a guy wearing some chainmail.. :-) Out of
curiousity, will you be releasing a version merged into Megapov? I remember
reading something about it in p.u.p., but I can't seem to find the thread
anymore in my newsreader.. :-(
"Christophe Bouffartigue" <Chr### [at] nanterre marellifr>
wrote in message news:3A90C3DA.3545FEC4@nanterre.marelli.fr...
> Thomas Charron wrote:
> > Anyone had a chance to play with this much? I was just taking a
look at
> > it recently at http://tofbouf.free.fr/clothray/index_en.html
> > Looks schweet..
> Well, as the author of this patch, the answer is... hum... yes.
> If you have the (great) chance to speak french (or have a little
> understanding of it), you can look at:
> http://tofbouf.free.fr/clothray/tut01.html
> There's a tutorial (not finished yet)...
> It will probably be translated in english after the end of this IRTC
> round...
> Just an example of what can be achieved....
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris, have you given any thought to contacting the other POVers who are
working on cloth right now? It would be ideal if all of the implementations
could be merged, preferably as you have implemented it, in-POV.
As the French say: A+ :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christophe Bouffartigue wrote:
> Well, as the author of this patch
I have a question: How similar is this to what Chris Huff did with his in-POV
particle simulations?
Did you do something similar with just spring forces & such?
> Just an example of what can be achieved....
Nice!!, very nice
--
Bye,
Pabs
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Pabs wrote:
>
> I have a question: How similar is this to what Chris Huff did with his in-POV
> particle simulations?
> Did you do something similar with just spring forces & such?
Well, actually, except for the syntax and the particles creation, it's
very similar: just forces applied to "particles".
Bouf.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tony[B]" wrote:
>
> Chris, have you given any thought to contacting the other POVers who are
> working on cloth right now? It would be ideal if all of the implementations
> could be merged, preferably as you have implemented it, in-POV.
If you think about Jerome's Cloth Simulator, the 2 projects had the same
purpose: an IRTC image. But, our programming skills are different, and I
went the "easy (and lazy) way": patching an already existant code, and
reusing POV's intersection routines.
Another issue is that my patch is an extremely specialized patch, and I
don't think that this kind of thing has to be implemented in POV. Always
the same thing: POV is a renderer, not a modeller.
I think Jerome's implementation is much more versatile than mine, but he
has to rewrite a lot of code (and know a lot of math) to provide new
object collision detection.
What would be ideal is a POV cloth simulator (like Jerome's), with a POV
object (script langage) as input, and OpenGl Preview, wind description
as a pigment, cloth description "a la mesh2" (that would allow any shape
for the cloth, not only rectangular), contraints (hanging points, for
instance), .... and so many things, and finally a mesh file as output,
that can be used directly in POV...
> As the French say: A+ :)
:)
A+
Bouf.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3a91ca30$1@news.povray.org>, Pabs <"pabs3"@ no spam thanx
dot crosswinds.net> wrote:
> I have a question: How similar is this to what Chris Huff did with
> his in-POV particle simulations?
> Did you do something similar with just spring forces & such?
Probably extremely similar, just using different spring forces and with
the particles linked to each other in a different way...with cloth, a
particle is always linked to specific neighboring particles, but with my
patch, particles are affected by any nearby particles.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas Charron wrote:
>
> Out of
> curiousity, will you be releasing a version merged into Megapov? I remember
> reading something about it in p.u.p., but I can't seem to find the thread
> anymore in my newsreader.. :-(
I promised to merge clothray with next version of my POVMan patch (which
will be based on MegaPov 0.7), but haven't got time to do it. Hopefully
this week (or weekend). I'll make note in p.u.p., when it's ready.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3A92255A.8DF771CE@nanterre.marelli.fr>, Christophe
Bouffartigue <Chr### [at] nanterremarellifr> wrote:
>Another issue is that my patch is an extremely specialized patch, and I
>don't think that this kind of thing has to be implemented in POV. Always
>the same thing: POV is a renderer, not a modeller.
As someone who types everything and can't draw, I disagree with this.
For me, POV *is* a modeler, and anything POV can do to help me model is
good. This cloth patch looks awesome to me, based on the results it is
producing.
Jerry
--
http://www.hoboes.com/jerry/
"Give a man a fish and you feed him for a day. Teach him to fish, and you've
depleted the lake."--It Isn't Murder If They're Yankees
(http://www.hoboes.com/jerry/Murder/)
Post a reply to this message
|
|
| |
| |
|
|
From: Jérôme M Berger
Subject: Re: Clothray cloth simulation patch..
Date: 23 Feb 2001 09:27:35
Message: <3A967356.501@iname.com>
|
|
|
| |
| |
|
|
Christophe Bouffartigue wrote:
> What would be ideal is a POV cloth simulator (like Jerome's), with a
> POV object (script langage) as input, and OpenGl Preview, wind
> description as a pigment, cloth description "a la mesh2" (that
> would allow any shape for the cloth, not only rectangular),
> contraints (hanging points, for instance), .... and so many things,
> and finally a mesh file as output, that can be used directly in
> POV...
>
I agree completely. Unfortunately, for this to be possible would require
either a change of the POV license or a special exception. Moreover, *I*
wouldn't want to do it until POV is written in C++ (which should allow a
much easier reuse of code)
Jerome
--
********************************* Jérôme M. BERGER
* 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jerry wrote:
> As someone who types everything and can't draw, I disagree with
> this. For me, POV *is* a modeler, and anything POV can do to help
> me model is good. This cloth patch looks awesome to me, based on
> the results it is producing.
>
As someone who also types everything and nearly can't draw, I have to
disagree. POV is most definitely *not* a modeller (this doesn't mean
that you have to use a modeller to create objects or scenes, you just
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.
All this of course is my own personal opinion and anybody is free to
disagree.
Jerome
--
********************************* Jérôme M. BERGER
* 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3A9### [at] inamecom>, "Jérôme M. Berger"
<ber### [at] inamecom> wrote:
> 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.
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.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3A9### [at] inamecom>, "Jérôme M. Berger"
<ber### [at] inamecom> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Jérôme M. Berger" wrote:
> 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
--
********************************* Jérôme M. BERGER
* 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
--
********************************* Jérôme M. BERGER
* 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
--
********************************* Jérôme M. BERGER
* 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3A9### [at] inamecom>, "Jérôme M. Berger"
<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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3A9### [at] inamecom>, "Jérôme M. Berger"
<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:
> In article <3A9### [at] inamecom>, "Jérôme M. Berger"
> <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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff 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.
>
This assumes you're doing an animation and want the cloth to evolve from
frame to frame. I was speaking more of several test renders of the same
scene for which having the cloth computed once ond for all is clearly
better.
> 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?
Unless I'm very much mistaken, you do recompute the particle_system for
each render don't you? (I don't mean each frame in an animation here)
This is too slow in my opinion, so you need to be able to perform the
cloth simulation once and save the result in a file (a mesh is the most
logical form of output here, though not the only one). Maybe the
particle system renders faster than cloth, otherwise I would argue that
particle systems should probably be implemented as an outside utility too...
The ability to transform a bezier patch into a mesh is just a trick to
make the render faster. The point isn't what internal structure pov uses
to render a particular piece of data, but how the data is generated in
the first place.
I'll return the question about height-fields to you: what is the
difference between hfs and cloth that would justify the cloth to be
generated in pov while the hf is generated by an outside program?
(Again, the fact that pov transforms the hf into something very similar
to a mesh for rendering is irrelevant here, the point is that the data
itself is generated by an outside utility).
Jerome
--
********************************* Jérôme M. BERGER
* 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:
> In article <3A9### [at] inamecom>, "Jérôme M. Berger"
<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.
Since, as you said yourself, it would require too much work, the only
*practical* way of actually *doing* it is by taking the code from pov.
Jerome
--
********************************* Jérôme M. BERGER
* 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3AA### [at] inamecom>, "Jérôme M. Berger"
<ber### [at] inamecom> wrote:
> > 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.
> This assumes you're doing an animation and want the cloth to evolve from
> frame to frame.
No, it doesn't!
> I was speaking more of several test renders of the same scene for
> which having the cloth computed once ond for all is clearly better.
It certainly is (unless you are adjusting the cloth, of course...). And
there is no problem with storing it to a file and using the file for
test renders, or even with quitting and restarting POV-Ray.
> Unless I'm very much mistaken, you do recompute the particle_system for
> each render don't you? (I don't mean each frame in an animation here)
Yes, I do, because I haven't implemented the save_file and load_file
features yet. But it is certainly possible to save the state to a file
and restore it when needed, it just needs to be implemented.
> This is too slow in my opinion, so you need to be able to perform the
> cloth simulation once and save the result in a file (a mesh is the most
> logical form of output here, though not the only one).
But you can't continue the cloth simulation from mesh data...the most
logical output would be to save the whole cloth simulation. If it was an
external utility and you were producing an animation, you would have to
output a lot of POV scenes and then render them, instead of running a
simulation while the animation progresses. If it is an internal patch,
it doesn't make sense to have it save to a POV file, because that means
you will always have to run it from the very beginning.
> Maybe the particle system renders faster than cloth, otherwise I
> would argue that particle systems should probably be implemented as
> an outside utility too...
And I don't see what rendering time has to do with any of this...it will
render at the same speed whether you use a patch or an external utility.
Actually, it may be possible to optimize a patch for even more speed...
> I'll return the question about height-fields to you: what is the
> difference between hfs and cloth that would justify the cloth to be
> generated in pov while the hf is generated by an outside program?
Um, well, I usually generate my height fields with POV-Ray...
The difference between height_fields and cloth? Cloth interacts with the
objects of the scene, that information is required in order to generate
the cloth, so it makes sense for it to be specified as part of the
scene. Height fields are a fixed element that don't usually depend on
anything in the scene.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Jérôme M. Berger" <ber### [at] inamecom> wrote in message
news:3AA### [at] inamecom...
> Chris Huff wrote:
>
> > In article <3A9### [at] inamecom>, "Jérôme M. Berger"
> <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.
> Since, as you said yourself, it would require too much work, the only
> *practical* way of actually *doing* it is by taking the code from pov.
>
No it isn't, not entirely anyway. Reinventing the wheel may not be the
most efficient, but is often the most practical, solution to a problem.
--
Scott Hill.
Software Engineer.
E-Mail : sco### [at] innocentcom
Pandora's Box : http://www.pandora-software.com
*Everything in this message/post is purely IMHO and no-one-else's*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff wrote:
> [lots of thing about saving to a file]
I see what you mean now. The problem with this approach is that it bloat
s
pov with code that has nothing to do with its original purpose. POV is a
rendering engine, it's meant to output images not cloth data, not
particle system data, only images. Adding "features" like that inside
pov itself can only result in overall slowdown (at least in the parsing
stage) and harder to maintain code (and therefore, more risk of bugs and
a longer wait between version). That's why I think those should be
implemented as separate utilities (even if ideally they would reuse the
pov code for object intersection. This isn't possible at the time being,
both because of the license and because pov wasn't written for it, but I
hope version 4 will address these points).
>> This is too slow in my opinion, so you need to be able to perform the
>> cloth simulation once and save the result in a file (a mesh is the mos
t
>> logical form of output here, though not the only one).
>
> But you can't continue the cloth simulation from mesh data...the most
> logical output would be to save the whole cloth simulation. If it was a
n
> external utility and you were producing an animation, you would have to
> output a lot of POV scenes and then render them, instead of running a
> simulation while the animation progresses. If it is an internal patch,
> it doesn't make sense to have it save to a POV file, because that means
> you will always have to run it from the very beginning.
>
If you look at the samples for the cloth simulator, you'll notice that i
t
does run the simulation while the animation progresses.
>
>
>> Maybe the particle system renders faster than cloth, otherwise I
>> would argue that particle systems should probably be implemented as
>> an outside utility too...
>
> And I don't see what rendering time has to do with any of this...it wil
l
> render at the same speed whether you use a patch or an external utility
.
If you allow the patch to write simulation related data to a file, then
rendering time has very little to do with it. If you don't, a patch will
have to recompute each time...
> Actually, it may be possible to optimize a patch for even more speed...
>
Actually, it *is* possible to optimize a separate utility for more speed
,
since it may not need the same precision in the intersection
computations that pov does (the cloth simulator certainly doesn't)...
Jerome
--
********************************* Jérôme M. BERGER
* 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3AA### [at] inamecom>, =?ISO-8859-1?Q?J=E9r=F4me?= M.
Berger says...
> I see what you mean now. The problem with this approach is that it bloat=
> s=20
> pov with code that has nothing to do with its original purpose. POV is a =
>
> rendering engine, it's meant to output images not cloth data, not=20
> particle system data, only images. Adding "features" like that inside=20
> pov itself can only result in overall slowdown (at least in the parsing=20
> stage) and harder to maintain code (and therefore, more risk of bugs and =
> l=20
Just a quick interjection: why have you now the "=20" and "=t" bits in
your mail? html?
--
Regards, Sander
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>POV is a rendering engine, it's meant to output images not cloth
>data, not particle system data, only images.
What about radiosity and photon data? If it can output those, why not cloth?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Sander wrote:
> Just a quick interjection: why have you now the "=20" and "=t" bits
> in your mail? html?
Because it's encoded in quoted-printable format, which most newsreaders
understand. This one shouldn't have this problem (but might cause
trouble for others...)
Jerome
--
********************************* Jérôme M. BERGER
* 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tony[B] wrote:
>> POV is a rendering engine, it's meant to output images not cloth
>> data, not particle system data, only images.
>
>
> What about radiosity and photon data? If it can output those, why not cloth?
Because those are internal rendering values that can have no meaning
outside of povray. A cloth simulator (or a particle systems simulator)
can be useful for people using other software. This also means that if
they are implemented as standalone utilities, they'll still work with
pov 4.0 even though it'll be a complete rewrite and that the pov-team
won't have to expend any effort for this (meaning we'll see it sooner
and there'll be less bugs). OTOH I won't expect pov 4.0 to still be able
to read photon/radiosity data saved by former versions...
Jerome
--
********************************* Jérôme M. BERGER
* 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3AB### [at] inamecom>, =?ISO-8859-1?Q?J=E9r=F4me?= M.
Berger says...
> Sander wrote:
>
> > Just a quick interjection: why have you now the "=20" and "=t" bits
> > in your mail? html?
> Because it's encoded in quoted-printable format, which most newsreaders
> understand. This one shouldn't have this problem (but might cause
> trouble for others...)
>
> Jerome
>
Ahh, I'll have to see whether they have adapted my newsreader to this
format, yet. Thanks.
--
Regards, Sander
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
