> It's made with cygwin so you will need the cygwin DLL just like for
> PovCyg.

Could you include the DLL on your site? I was unable to download it with the
cygwin package (and that's why I didn't try your cygPOV).

Post a reply to this message

Here it comes:

http://www.schunter.etc.tu-bs.de/~chris/cloth/index.html

The Cygwin DLL is needed to run the program.  I'm using version 1.1.7
which is the latest (Dec. 28 2000) and i don't know if earlier versions
work as well.  

You can find it on the Cygwin homepage:
http://sources.redhat.com/cygwin/

Either use the setup program offered:
http://sources.redhat.com/cygwin/setup.exe

or directly download the package from one of the various mirror sites
like:
ftp://ftp.franken.de/pub/win32/develop/gnuwin32/cygwin/mirrors/cygnus/latest/cygwin/cygwin-1.1.7-1.tar.gz

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

That is really great!

I succeeded in removing the vnoise and hnoise by using step 0.1.



Marc-Hendrik

Post a reply to this message

Thank you Chris. I have downloaded it, and will soon commence testing. :)

Post a reply to this message

Marc-Hendrik Bremer wrote:

 > That is really great!
 >
 > I succeeded in removing the vnoise and hnoise by using step 0.1.
 >
	Yes, lowering the step will improve the stability of the algorithm but it 
will require more steps to compute and therefore will be longer. I hope 
to improve this by moving to the semi-rigid model...


 >
	You're welcome

		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

Mark Wagner wrote:

 > The algorithm used is numerically unstable.  Under certain
 > circumstances, points will start heading off towards infinity.
 > isinfinite() attempts to detect this and currently stops
 > calculations with an error.
 >
	Exactly (no point in spending several hours computing something, just to 
discover that the result is full of NaNs and Infs, especially since as 
soon as they start appearing, the computations slow down). However, I'm 
not sure why the algorithm is unstable like that and why it depends on 
the cloth parameters (intuitively, I would have thought that it should 
depend only on step: being stable if step<1 and unstable if step>=1)

 > If you haven't already implemented it, I'd like interaction with
 > spheres (or even better, blobs ;-).
 >
	Spheres shouldn't be too long in coming. Blobs will probably have to wait 
more...

		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

Christoph Hormann wrote:

 > When compiling it with cygwin, it only complained about the 'if 
(!isfinite(tmp))'
 >  in vector.cc.  I just commented it out to get it running and it
 > worked nice although with the sample parameters in the docu, it generated
 >  'NaN' values in the output.
 >
 > I doubt these two things are related because the 'if
 > (!isfinite(tmp))' construction would not even finish the
 > calculation.
 >
 > I don't know any C++ so i would appreciate some info about both the
 > 'NaN' output and the isfinite() function
 >
	Look at Mark Wagner's message and my answer.

 > Have you thought about adding it directly to Povray? that would make
 >  it possible to use all Povray object for collision.
 >
	Yes it would, but since cloth computing is pretty slow, it should still 
be independent of scene rendering. Ideally, it would be an independant 
binary linked to the povray object code, but the license of pov doesn't 
allow this and anyway I'm afraid it would be too much of a mess until 
pov is programmed in C++ so I won't do it.

	OTOH, someone has just showed one such patch on the french newsgroup. 
It's not publicly available yet but it shows some promise (except that 
from the description the author gave it seems hellishly difficult to use)

 > Another nice thing would be smooth meshes.
 >
	If you mean in the output, it's already there (actually, there's no way 
to output a non-smooth mesh). If you mean in the input, meshes are 
certainly a possibility (they'll wait until after self-collision though, 
since they'll share a lot of code with it) but I don't see how *smooth* 
meshes would behave?

		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

Christoph Hormann wrote:

> Here it comes:
> 
> http://www.schunter.etc.tu-bs.de/~chris/cloth/index.html
> 
	Thank you Christoph, I've added a link to your page on the simulator's main page.

		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

> 
>         Yes it would, but since cloth computing is pretty slow, it should still
> be independent of scene rendering. Ideally, it would be an independant
> binary linked to the povray object code, but the license of pov doesn't
> allow this and anyway I'm afraid it would be too much of a mess until
> pov is programmed in C++ so I won't do it.
> 

I understand that, although another nice thing about integration into Pov
would be animations.

>  > Another nice thing would be smooth meshes.
>  >
>         If you mean in the output, it's already there (actually, there's no way
> to output a non-smooth mesh). If you mean in the input, meshes are
> certainly a possibility (they'll wait until after self-collision though,
> since they'll share a lot of code with it) but I don't see how *smooth*
> meshes would behave?
> 

Seems i have got this wrong, sorry.

One very nice thing for an object in the cloth simulator would be a
heightfield.  One could generate a depth map of any pov scene from above
and use it in the simulator.  Of course that would have some limitations,
but it would be quite sufficient for many complex scenes.  For example
imagine some sheet covering a table with a lot of different objects on
top.  

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

Christoph Hormann wrote:

 >
 > Seems i have got this wrong, sorry.
 >
 > One very nice thing for an object in the cloth simulator would be a 
heightfield.
 >   One could generate a depth map of any pov scene from above and
 > use it in the simulator.  Of course that would have some
 > limitations, but it would be quite sufficient for many complex
 > scenes.  For example imagine some sheet covering a table with a lot
 >  of different objects on top.
 >
	That's true, I'll try to add it after the mesh (since internally, an 
height-field is best represented as a mesh anyway)

		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