_1024_Rope

franz's picture

It seems I just got tired of noodling. Rope plugin to simulate ... errrr ... a rope. Doesn't work in an iterator tho'... but why ?

DL from 1024d.wordpress.com

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

cybero's picture
Re: _1024_Rope

Quote:
doesn't work in an iterator tho'... but why ?

not so sure about that :-)

still working on getting that to stay on screen more than off .

franz's picture
Re: _1024_Rope

pushing the numbers too far will make the rope pretty unstable. Also, as I said before, it won't work properly inside an iterator, unfortunately.

vade's picture
Re: _1024_Rope

Are you using static vars in the plugin source? Or is everything in class ivars?

I suspect if you use static vars declared outside of the scope of the QCPlugin @implementation and use them to drive calculations, multiple instances of the plugin will overwrite your variables and, in a sense corrupt the calculations each pass.

Total speculation :)

vade's picture
Re: _1024_Rope

Apparently I am using an iterator to post.

jersmi's picture
Re: _1024_Rope

More promising tidbits. Interest abounds. Silly question: isn't most rope always the same length? :)

edit: that is, this is interesting, wondering what are the strengths / weaknesses of verlet integration, what features are practical, etc.

franz's picture
Re: _1024_Rope

mmm, ivars sound pretty opaque to me at the moment. I've googled them, but didn't feel suddenly enlighted.

My code is c++, I'm just declaring a RopeController instance in the plugin header, @interface. Then the RopeController is driving the springs instances, nothing fancy or crazy.

Strangely, multiple instances of the rope patch do work within the QC environment, however placing the patch in an iterator looks like if all the variables were overwritten, somehow.

Reading again the Hillegass cookbook, but I haven't found any useful info, QC-wise.

franz's picture
Re: _1024_Rope

It is based on springs, so each spring has a rest length and a max elongation. Verlet is pretty practical. Modifying the numbers has a big impact on the simulation stability. Memo said to me once " It's all about tweaking the numbers" . I guess he is right....

dust's picture
Re: _1024_Rope

ohh missed this conversation. your using the verlet's sweet. yeah thats the stable one. i haven't noticed to much of a difference in animations using verlet's or euler richardson's but if accuracy counts verlets is the one to use.

going to get into springs this week for class. i'm excited. what kind of ∆t or delta time are you using. i don't know if you want to do this or not but i found its pretty cool to expose the ∆t and feed audio spectrum in. when the ∆t is larger it takes your computer less time to calculate so you get a faster animation.

so it looks cool with time freeze type of effects when you feed music into the ∆t. this opposite of how ∆t is supposed to work and is only based on the computers resources. meaning if your modifying ∆t to be a smaller step to get around a tight corner the object will move faster naturally.

franz's picture
Re: _1024_Rope

yep i'm using the verlet, same as _1024_cloth plugin (which was very alpha, so it's not a good idea to have both plugins at the same time on your qcplugins folder... anyway...).

For now I'm just trying to have a stable simulation, so I'm using a timer that shouldn't be dependant of your framerate, ensuring that the simulation time step is always regular and consistent.(in theory)

It's a good idea to be able to scratch time, will look into it. Will look into euler richardson as well. Do you have any interesting link (aka "understandable") ?

dust's picture
Re: _1024_Rope

basically your calculating your velocities from a half step instead of the velvet's where you need an old and new positions. the problem is that you need to estimate your new velocity from your old velocity that is why you use a euler.

so you run the Euler Richardson below to estimate your new pos to derive your velocity with the smallest error. so once you run the euler lets say a loop of 100 you take that position value (x below) lets call it X2 then you can do your verlet's integration using that value. (x2-x1)/2*∆t where x1 is your initial pos.

your using the mouse so its just as easy to calculate your start and end pos by the mouse touch down and touch end points. if you don't have a mouse you would want to run the simulation with euler to get the best verlet's result.

1D euler richardson

dt = delta-time or ∆t
x = position;
a = accel
g = gravity
v = init velocity
vt = terminal velocity. think of it as your viscous drag parameter. rather than getting into how to estimate this just use vt as an input parameter. 
vmid = velocity at mid point;
amid = accel at mid point;
 
 
for a linear case....
 
a = g(1-(v/vt));
vmid = v + a * (dt/2);
amid =g(1-(vmid/vt))
v = v + amid * dt;
x = x + vmid * dt;
 
for a quadratic case your v and vt are to the second power. 
 
a = g(1-(v*v/vt*vt));
vmid = v + a * (dt/2);
amid =g(1-(vmid*vmid/vt*vt))
v = v + amid * dt;
x = x + vmid * dt;

franz's picture
Re: _1024_Rope

massive ! thxxx

jersmi's picture
Re: _1024_Rope

Don't even keep them together in the plugins folder?!

franz's picture
Re: _1024_Rope

Ropes in action. Sorry for the bad quality, bad lighting and bad filming.

http://creative.arte.tv/fr/space/L_Ososphere/messages/

franz's picture
Re: _1024_Rope

avoid leaving unused/alpha/beta/gamma plugins in your folder.