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