Hi,

I just finished a test with my cloth-cloth collission thing. I included a
divx avi with this message. But if you're not able to view the thing. Check
http://geitenkaas.dns2go.com/experiments/
The cloth06tests are with cloth-cloth collission detection.

(I was actually jumping up and down when I got the first image that showed
me that it actually worked!)



-- too many idle loops? visit http://www.imp.org/ and take care of it! --

Post a reply to this message

Attachments:
Download 'cloth06test2_640x480.divx.avi.dat' (652 KB)

On Tue, 5 Feb 2002 20:44:47 +0100, Apache wrote:
> I just finished a test with my cloth-cloth collission thing. I included a
> divx avi with this message. But if you're not able to view the thing. Check
> http://geitenkaas.dns2go.com/experiments/
> The cloth06tests are with cloth-cloth collission detection.

I think maybe your universe needs some friction.  But this is very cool.

-- 
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbf 1}hollow interior{media{emission 3-T}}}#end 
Z(-x-x.2x)camera{location z*-10rotate x*90normal{bumps.02scale.05}}

Post a reply to this message

I've been following your cloth progress, and I just wanted to say:
"Excellent Work!"  What kind of math is behind this?  I assume that it is
well above my head.  The movement is great, but in this last one, the cloth
looks more like silk, because of it's lack of friction; is there someway to
cause it to lose energy?  But whatever comments I have, I really want to say
keep going with this, it is amazing work.

H. David Young

Post a reply to this message

Nice! There is something odd about the way the fold moves toward the right hand
corner, but I liked the way it pushed the cloth above it  out of the way. What is
the speed decrease when using your internal collision detection?


--
text{ttf"timrom.ttf"concat(#local O=1;#while(O<7)chr(val(substr(concat(#local Q=
1;#while(Q<7)str(asc(substr("???<?>",Q,1))-56,0,0),#local Q=Q+1;#end""),O,2))),#
local O=O+2;#end"").1,0pigment{rgb 9}translate-<1,.3,-2>} // MJL

Post a reply to this message

Apache wrote:

> Hi,
>
> I just finished a test with my cloth-cloth collission thing. I included a
> divx avi with this message. But if you're not able to view the thing. Check
> http://geitenkaas.dns2go.com/experiments/
> The cloth06tests are with cloth-cloth collission detection.

I like it very much. Like the others I think that you need some friction
to get rid of some energy in order to stop the motion a bit earlier.
I also think that the value for your force that resists the bending between
your elements is too high. Otherwise, brilliant work.

I am also curious what programs you use to compute the motion.


>
> (I was actually jumping up and down when I got the first image that showed
> me that it actually worked!)
>
> -- too many idle loops? visit http://www.imp.org/ and take care of it! --
>

Great idea, I'll give them a call.

>
>                                     Name: cloth06test2_640x480.divx.avi
>    cloth06test2_640x480.divx.avi    Type: WMPLAYER File (video/avi)
>                                 Encoding: x-uuencode

Post a reply to this message

>Nice!
Thank you!


> There is something odd about the way the fold moves toward the right hand
corner, but I liked the way it pushed the cloth above it  out of the way.

My cloth algorithm works with (very stiff) springs between 'atoms'. That odd
movement at the corner is caused by the fact that at the center side of the
fold there are more pressed (pushing) springs than at the corner side. This
causes some sort of 'imbalance' so the fold is pressed to the corner. I have
some ideas about using a very different cloth model.


> What is the speed decrease when using your internal collision detection?

Not sure what you mean by this. Possibly you're talking about some energy
loss when atoms collide or bounce. Well.. They actually NEVER collide, since
them atoms don't have no volume or width. They're infinitely small like
points: just coördinates.
When 2 atoms come too near eachother I simply put a spring between them that
pushes them apart. That's quite simple in fact. Managing the friction is
something else because the friction depends on the kind of material, the
structure of it. Possibly it depends on the angle of attack too.

(I built some bounding box trick in order to detect near atoms very fast.
I'll start rendering some more animations showing just those boxes and put
them on http://geitenkaas.dns2go.com/experiments/. I'll let you know when
they're up.)

Post a reply to this message

I'll rerender the thing again then! But this time I'll try making it more
supple. And I'll increase the amount of particles or 'atoms'.

Post a reply to this message

Bounding box animations:
http://geitenkaas.dns2go.com/experiments/cloth06test2bounds_640x480.divx.avi
and
http://geitenkaas.dns2go.com/experiments/cloth06test2bounds_640x480.mpg .

Post a reply to this message

Apache wrote:

> My cloth algorithm works with (very stiff) springs between 'atoms'.

Yes, thats it. Reminds me of a stiff rubber sheet.

> > What is the speed decrease when using your internal collision detection?
>
> Not sure what you mean by this.

Sorry, I should have been clearer. I meant to ask about the extra time it takes
to calculate this collision detection.

> When 2 atoms come too near eachother I simply put a spring between them that
> pushes them apart.

Ah... the same method that Clothray (in POVMan) uses. I have some feel over how
much longer this collision detection takes to determine :-) The results, though,
look worth the wait.

> (I built some bounding box trick in order to detect near atoms very fast.
> I'll start rendering some more animations showing just those boxes and put
> them on http://geitenkaas.dns2go.com/experiments/. I'll let you know when
> they're up.)

Is it just me, or do other people enjoy these sort of "show the inner workings"
too? I do it alot with my particle system.

--
text{ttf"timrom.ttf"concat(#local O=1;#while(O<7)chr(val(substr(concat(#local Q=
1;#while(Q<7)str(asc(substr("???<?>",Q,1))-56,0,0),#local Q=Q+1;#end""),O,2))),#
local O=O+2;#end"").1,0pigment{rgb 9}translate-<1,.3,-2>} // MJL

Post a reply to this message

You're getting very good results!!!

I see that this time you used smooth triangles, am I right? It looks much
better.

I hope I can find some time soon to continue my research! I got a bit
dissappointed with my last experiments, but I think I'm ready to restart.

Congratulations again!

Fernando.

Post a reply to this message

No smooth triangles (yet)!

This 'rubber' sheet consists of 100x100 atoms (174830 springs, 99x99x2
triangles).

My machine is working on a new animation of 150x150 atoms (221710 springs,
149x149x2 triangles). There are three spheres this time. (Too lazy/dumb to
implement torus and box.) The sheet is much more flexible this time, so
probably the angles between triangles will be sharper. Maybe I'll have to
render the thing using smooth triangles.

BTW should I normalize the normal vectors of the triangle mesh?
(#declare NormVec = NormVec / vlength(NormVec); )

Post a reply to this message

The collission detection doesn't need much extra time, because those
bounding things work really fast.

In fact I created those boundbox animations for testing purposes.
As you could see those boxes have different colors.
The color of a box shows if there are collissions between atoms inside the
box or between atoms of that box and atoms of a neighbor box.
(There are 26 neighbor boxes. Just check the first 13 of those neighbors,
otherwise you'll check the same collissions twice and would be a waste of
cycles.)
The colors of the boxes:
 - blue: no collissions
 - red: collissions between directly connected atoms --> ignore
 - yellow: collissions --> add springs to push atoms apart.

Post a reply to this message

"Apache" <apa### [at] yahoocom> wrote in message
news:3c60c70c$1@news.povray.org...

> No smooth triangles (yet)!
>
> This 'rubber' sheet consists of 100x100 atoms (174830 springs, 99x99x2
> triangles).

Well, it looks really smooth!

> My machine is working on a new animation of 150x150 atoms (221710 springs,
> 149x149x2 triangles). There are three spheres this time. (Too lazy/dumb to
> implement torus and box.) The sheet is much more flexible this time, so
> probably the angles between triangles will be sharper. Maybe I'll have to
> render the thing using smooth triangles.
>
> BTW should I normalize the normal vectors of the triangle mesh?
> (#declare NormVec = NormVec / vlength(NormVec); )

I suppose that POV normalizes them, because I don't and they look ok.

Fernando.

Post a reply to this message

Apache wrote:

> No smooth triangles (yet)!
>

There is another possibility. You could use your atoms as the
four inner points of a bezier patch and interpolate the border
control points.  This way you will get a surface that is by
definition continuous and smooth. It may increase the computation
time as internally they are converted to smooth triangles (I think),
but you may also be able to reduce the number of atoms.

Post a reply to this message

Some more info about my current sheet program:
It needs the following variables for input:
 1. Atom coordinates
 2. Stiffness value (higher stiffness --> more springs between atoms)
 3. Stepsize (smaller steps --> better results but slower movements in
animation)
 4. Steps per frame (more steps --> faster movements in animation)
 5. Amount of frames (ehhmmm... more frames --> longer animation)
 5. Solid objects data (sphere coords and size)
 6. Collission distance (minimum distance between not-connected atoms)

the current version of my program sorts out which atoms should be connected
by springs. So there's no need to do find that out by yourself.


If I decide to create a more user-friendly cloth-application, I'll have the
following 'to do' list (in no particular order):
 1. Fur   or Furr, I don't know :-)      (Not sure about this one, but it
would be very nice thing)
 2. Thickness of material  (A sheet won't be infinitely thin anymore)
 3. Smooth triangles / bezier patches (I was thinking about that one some
days ago)
 4. User defined springs (You decide which atoms will be connected by
springs, how stiff those springs are and how long they'll be)
 5. External forces: wind
 6. External forces: moving solid objects
 7. Output in 3.1 povscript that parses easily (with #declare I = I + 1; and
all)
 8. More solid objects like cones, boxes and toruses and triangle meshes,
including transformations.
 9. Resume option (If I would stop the program now, I'll have to start from
T=0 all over)

If number 4 very funny things are possible: sleeves or different cloths that
are interacting wich eachother.

Adding support for triangle meshes is just a small step. All solid objects
can be approximated by a triangle mesh, so I can skip the support of all
other solid objects.But I'm not sure if that would be a wise thing to do,
because testing for a sphere is much faster than testing for a bunch of
triangles. It will all depend on the speed and efficiency of my collission
detection bounding boxes algorithm and implementation.

Post a reply to this message

On Wed, 6 Feb 2002 07:31:52 +0100, "Apache"
<apa### [at] yahoocom> wrote:

> - yellow: collissions --> add springs to push atoms apart.

This approach gives rise to some problems:

1. It is a feedback approach, i.e. it corrects the error after it has
occurred. In this case, self-intersection may need several integration
cycles to be corrected, depending on inertia. Using a feed-forward
approach to predict self-collision early is definitely better, and
harder by a factor of [choose a random large number :)]

2. You need very stiff springs to improve the reaction time of the
collision avoidance algorithm, and this gives rise to very stiff
differential equations which need either a very small step to be
solved explicitly or an implicit integration routine of higher
complexity.

3. You do not account for friction between different parts of the
cloth, even if you do for the cloth-environment interface. I would
suggest using a feed-forward approach (collision prediction) to
identify imminent collisions. Then you'll have to decompose each
atom's velocity into normal and tangent to the plane tangent to the
cloth in the intersection point (this might prove difficult). Then
friction should be rather easy to apply, and as for self collision,
you'll probably want to apply penalties directly to the offending
atoms' velocities (i.e. cancel their normal component) rather then
introducing new springs into the problem.

Hope this helps. If you keep going at the pace you're currently doing,
you might as well get David Baraff's job at Pixar before the year is
over :) Good luck!


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

Some years ago my mathematical knowledge went down the drain. So I'll need
an absurd amount of time to get hold of the backward Euler algorithm. And
I've got many things, but time....
And my brain seems to be tired too... :-(
And.... I really want to start a good city planning and generation thing for
a big animation project I'm working on. And I want to do this all in C so I
can get some BIG speed improvements.

Anyhow, before implementing backward euler I should rewrite some of the code
and make the executable publicly available and easy to use for other
pov'ers.

Post a reply to this message