This is just a first test. In more 'serious' scenes I won't fix cloth at
just a few single nodes. But still I want to get rid of that 'about to
break' problem. The first solution I can think of is decreasing the step
size and increasing the stiffness of the springs.
The animation I submitted before used timesteps of 0.04 and 20 steps per
frame. The animation with this message uses timesteps of 0.08 and 10 steps
per frame.
Both sheets are 50x50 nodes (or atoms).

As you can see the sheet of the new animation (cloth07test4, the one
attached to this message) needs more time to settle down and the sheet is
more flexible. That's caused by the larger time step. Maybe using 5th or 6th
order Runge-Kutta would even improve the thing more? So my next question
would be: I would like to know HOW them people (mister Runge and mister
Kutta?) got to that Runge-Kutta algorithm.

A part of the R-K algorithm: Vnew = Vold + (K1+ 2*K2 + 2*K3 + K4) / 6
Why oh why wouldn't it be Vnew = Vold +(K1 + 3*K2 + 2*K3 + K4) / 8 or
something else? Maybe someone told/taught it me some time ago when I wasn't
paying attention. If I know how them people got that formula, I would be
able to get higher order algorithms by myself.

Apache
http://geitenkaas.dns2go.com/experiments/

Post a reply to this message

Attachments:
Download 'cloth07test4_320x240.mpg' (547 KB)

Aha! I know now why the latest rubber sheet needs more time to stop moving.
The program dampes only once per time step. So with 10 time steps per
animation frame there's less damping than with 20 time steps per animation
frame.
I should fix this bug...

Post a reply to this message

Apache wrote:

> The first solution I can think of is decreasing the step
> size and increasing the stiffness of the springs.

That came to my mind too. I'm sure you also know how much that will slow the
simulation down by too :-)

>
> As you can see the sheet of the new animation (cloth07test4, the one
> attached to this message) needs more time to settle down and the sheet is
> more flexible. That's caused by the larger time step.

Does this cloth have the same number (and strength) springs too? I would not have
expected this large a change in flexibility by changing the time step (and
consequently the number of steps) alone.

> Maybe using 5th or 6th
> order Runge-Kutta would even improve the thing more? So my next question
> would be: I would like to know HOW them people (mister Runge and mister
> Kutta?) got to that Runge-Kutta algorithm.

I confess to know little of these methods. These links explain 2nd and 4th order
RK. They may be of some use.

http://nacphy.physics.orst.edu/ComPhys/DIFFEQ/mydif2/node5.html
http://nacphy.physics.orst.edu/ComPhys/DIFFEQ/mydif2/node6.html

Math has never been a strong point for me.

--
prism{0,.1,30#local I=1;#while(I<30)#local B=asc(substr(// Mark James Lewin
"#K?U_u`V[RG>3<9DGPL.0EObkcPF'",I,1))-33;<div(B,10)-4mod(B,10)+5*div(I,21)-
6>#local I=I+1;#end,-4pigment{rgb 9}rotate-x*90translate 15*z}//POV-Ray 3.5

Post a reply to this message

Apache wrote:

> Aha! I know now why the latest rubber sheet needs more time to stop moving.
> The program dampes only once per time step. So with 10 time steps per
> animation frame there's less damping than with 20 time steps per animation
> frame.
> I should fix this bug...

How much damping do you use? I woudn't have expected it to have such an effect on
the flexibility.

MJL
--
prism{0,.1,30#local I=1;#while(I<30)#local B=asc(substr(// Mark James Lewin
"#K?U_u`V[RG>3<9DGPL.0EObkcPF'",I,1))-33;<div(B,10)-4mod(B,10)+5*div(I,21)-
6>#local I=I+1;#end,-4pigment{rgb 9}rotate-x*90translate 15*z}//POV-Ray 3.5

Post a reply to this message

The damping factor I used: 0.997 per time step.

Post a reply to this message

What kind of damping are you using?

velocity = velocity * damping_factor?

I've read that that kind of damping is not very good.

Baraff et al, in "Large-steps in cloth animation" recommend a more
complicated dampening system which depend in some condition functions (which
are related to the energy of the cloth), but I found it a bit complicated
and tried to look for something similar but simpler. I implemented the
following dampening process (and I think I got good results):

Add another modification to the force vector which is proportional to the
velocity (but in opposite direction):

f = -k * v (for some dampening constant k)

This serves as some kind of friction. However Baraff et al, strongly
emphasize that any dampening process must be relative to "in-cloth"
movements and not because of other external forces (did I explain
myself????)

So, I implemented

f = -k*w

where w is the projection of the velocity vector in the plane tangent to the
cloth's surface. Later I tried with a intermediate mix, and it also worked
well.

If you implement this, I hope you can tell me if it works or not.

Anyway, congratulations on your advances.

Fernando.

Post a reply to this message

> velocity = velocity * damping_factor?
Yes.

I did these test just to make sure that R-K actually worked in my
implementation. Any damping, cloth-solid / cloth-cloth / cloth-fur
collission detection will be implemented by me in the next few
years...ehhh... weeks.  ;-)

Post a reply to this message

<fcu### [at] yahoocom> wrote:

>However Baraff et al, strongly
>emphasize that any dampening process must be relative to "in-cloth"
>movements and not because of other external forces (did I explain
>myself????)

LOL, I remember making this mistake in my early dynamic body
simulations. I would have the velocity damped alright, but that
velocity was the result of integrating an acceleration which was
proportional to the net force acting on a node,  both internal and
external forces... As a result, as I was using viscuous damping
(velocity-based), it looked as if the body was submerged in a liquid,
slowing down for no apparent reason etc. Took me some time to redesign
it, I ended up splitting up velocity in two components (internal and
external) and storing both of them to the next iteration, only adding
them at the end to find displacement.


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

Post a reply to this message

This routine is called RK45 or Runge-Kutta-Fehlberg. It involves a
fifth order RK method where the difference between the fourth- and
fifth order evaluations is an estimate of the truncation error for the
classical rk4 procedure. The error estimate is used to change the
increment size. I've programmed it in Matlab that involves some
obscure matrix expressions, so I've converted it to pseudo pov.
This routine seems to perform just as well as Matlab's own ode45,
which I've used in many fluid and thermodynamics problems whitout
problems. Problems can arise with stiff, coupled systems but I don't
think cloths can be characterized as such.

It takes the function f(t,x) for the differential equation and finds
the value of x at t=t+h Input: t (current time), h (step size), x
(current variable value). At the end, t and x are updated to the next
time step.

#macro rk45(t,x,h)
c20=.25
c21=.25
c30=.375
c31=.09375
c32=.28125
c40=12/13
c41=1932/2197
c42=-7200/2197
c43=7296/2197
c51=439/216
c52=-8
c53=439/216
c54=-845/4104
c60=.5
c61=-8/27
c62=2
c63=-3544/2565
c64=1859/4104
c65=-.275
a1=25/216
a3=1408/2565
a4=2197/4104
a5=-.2
b1=16/135
b3=6656/12825
b4=28561/56430
b5=-.18
b6=2/55

k1=h*f(t,x)
k2=h*f(t+c20*h,x+c21*K1)
k3=h*f(t+c30*h,x+c31*k1+c32*k2)
k4=h*f(t+c40*h,x+c41*k1+c42*k2+c43*k3)
k5=h*f(t+h,x+c51*k1+c52*k2+c53*k3+c54*k4)
k6=h*f(t+c60*h,x+c61*k1+c62*k2+c63*k3+c64*k4+c65*k5)

x4=x+a1*k1+a3*k3+a4*k4+a5*k5
x=x+b1*k1+b3*k3+b4*k4+b5*k5+b6*k6
t=t+h
error=abs(x-x4)
#end rk45

The next routine uses rk45 and it's error output to increase or
decrease the time increment if the error goes beyond error_max or
below error_min. If its between the increment is kept unchanged.

sign(h) returns the sign of h. The following macro would do the trick:
#macro sign(a) a^2/(abs(a)*a) #end
I'm not sure how to code the exit_while_loop, but I'm sure it's
possible.

h is the initial time step size, tb is stop time, hmax and hmin are
upper and lower bounds on the  step size and errormin and errormax are
the error bounds. iflag has value 0 or 1: iflag=0 means successful
integration from ta-tb, iflag=1 means maximum number of iterations
reached.

#macro rk45Adaptive(t,x,h)
tb=2
itmax=1e4
errormax=1e-3
errormin=1e-4
hmin=1e-3
hmax=5
delta=1e-5
iflag=1
k=0
while k <= itmax
 k=k+1
 if (abs(h)<hmin) h=sign(h)*hmin end
 if (abs(h)>hmax) h=sign(h)*hmax end
 d=abs(tb-t)
 if (d<=abs(h))
  iflag=0  
  if (d<=delta*max(abs(tb),abs(t)) exit_while_loop
  h=sign(h)*d
 end
 xsave=x
 tsave=t
 rk45(t,x,h)
 if (iflag=0) then exit_while_loop
 if (error<error_min) h=2*h end
 if (error>error_max)
  h=h/2
  x=xsave
  t=tsave
  k=k-1
 end
end
#end rk45Adaptive
-- 
ICQ 74734588

Post a reply to this message

My goal is to get rid of as much elastic behaviour as possible. Very
difficult thing to do if I want to maintain big step sizes. The cloth
'explodes' or I'm getting some very weird overflow problems all the time
trying to get rid of all that elasticity.     Terrible  :-(
I'm surprised that I managed to get RK4 working after all. And sometimes I'm
wondering if/when I'll get the system working the way I want it to: (very)
fast, stable and (more or less) realistic.

I think that using variable step sizes would be a good thing.

Post a reply to this message