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

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

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

* 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