<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

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
-- 

* 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:


<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
-- 

* 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

<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

news:3AA### [at] inamecom...
> Chris Huff wrote:
>

> <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
-- 

* 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