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

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

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

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

> 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

<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

> 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