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.
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.
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....
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.
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") ?
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;
not so sure about that :-)
still working on getting that to stay on screen more than off .
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.
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 :)
Apparently I am using an iterator to post.
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.
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.
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....
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.
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") ?
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
massive ! thxxx
Don't even keep them together in the plugins folder?!
Ropes in action. Sorry for the bad quality, bad lighting and bad filming.
http://creative.arte.tv/fr/space/L_Ososphere/messages/
avoid leaving unused/alpha/beta/gamma plugins in your folder.