Aligning an entity to my verlet construct.
Blitz3D Forums/Blitz3D Programming/Aligning an entity to my verlet construct.
| ||
| I for the life of me can't figure out how to align an entity to a verlet construct. I am currently doing it by finding the vector between two verelt particles along the constructs Z axis, then finding one for along the verlet constructs X axis. But using aling to vector for one, then the other, doesnt seem to work. Any ideas? |
| ||
| NM, I got it. |
| ||
| ShatteredReality, Would you mind sharing your find. I'm working on a verlet integrator myself and will soon have to deal with this. thanx |
| ||
I had the same problem a while ago , and i solved it by using a center verlet and 2 other auxiliary verlets ,and then alligntovector For cc.construct = Each construct ;<- PROBLEM? If cc\stopped = 0 Then PositionEntity cc\m_cg,EntityX(cc\v[0]\m,True),EntityY(cc\v[0]\m,True),EntityZ(cc\v[0]\m,True) x#=EntityX(cc\x1[1]\m)-EntityX(cc\v[0]\m) y#=EntityY(cc\x1[1]\m)-EntityY(cc\v[0]\m) z#=EntityZ(cc\x1[1]\m)-EntityZ(cc\v[0]\m) AlignToVector cc\m_cg, x#, y#, z#, 2 x#=EntityX(cc\x2[1]\m)-EntityX(cc\v[0]\m) y#=EntityY(cc\x2[1]\m)-EntityY(cc\v[0]\m) z#=EntityZ(cc\x2[1]\m)-EntityZ(cc\v[0]\m) AlignToVector cc\m_cg, x#, y#, z#, 3 End If Next cc\v[0] - center verlet cc\x1 and cc\x2 - aux verlets cc\m_cg - object |
| ||
| ghostdag, thanx for the code. I have to figure out what the construct is, but, I'm sure that i can. For construct.construct = Each construct ;<- PROBLEM? If not construct\stopped PositionEntity construct\entity%,EntityX(construct\v[0]\pivot%,True),EntityY(construct\v[0]\pivot%,True),EntityZ(construct\v[0]\pivot%,True) x#=EntityX(construct\x1[1]\pivot%)-EntityX(construct\v[0]\pivot%) y#=EntityY(construct\x1[1]\pivot%)-EntityY(construct\v[0]\pivot%) z#=EntityZ(construct\x1[1]\pivot%)-EntityZ(construct\v[0]\pivot%) AlignToVector construct\entity%, x#, y#, z#, 2 x#=EntityX(construct\x2[1]\pivot%)-EntityX(construct\v[0]\pivot%) y#=EntityY(construct\x2[1]\pivot%)-EntityY(construct\v[0]\pivot%) z#=EntityZ(construct\x2[1]\pivot%)-EntityZ(construct\v[0]\pivot%) AlignToVector construct\entity%, x#, y#, z#, 3 End If Next |
| ||
| Ghostdag does it the same way as myself. |
| ||
| the problem i am having using verlet physics is that i can't get it to be rigid enough especialy when the construct is thin,like a board, is there any method of improoving rigidity ? |
| ||
| To improve rigidity you'd either need to slow things down or increase the number of iterations, both of which can get pretty expensive. It's hard to keep something flat from going all over the place. |
| ||
| To Gurus who have implemented Thomas Jakobsen's Verlet Integrator Character Physics: I'm currently searching for the (C2) Sqrt Approximation with respect to particle masses. My code simply does not work: delta=x2-x1 delta=delta*restlength^2/((dotproduct(delta,delta)*(invmass1+invmass2))+restlength^2)-(invmass1+invmass2) <-- trouble starts here x1=x1-delta*invmass1 x2=x2+delta*invmass2Your assistance is valued. thanx |
| ||
| Forget the sqrt approximation... it doesn't make anything faster. On my Athlon 1800xp... sqr was as fast as fetching data from an array. So it isn't worth the hassle. Btw. I didn't get it to work either. It's wrong in the paper. |
| ||
| Bouncer, Interestingly, I could not get the standard formula to work. I had success with the standard sqr approx formula. I desire to tinker with masses and would like to use the sqr approx formula. I would prefer to keep the number operations to a minimum and the sqr approx offers this. Thanks for you insight. |
| ||
| You don't need to use any odd formulas just to incorporate mass into your equations. Here's how the SetDistance function works in my own Verlet integration routine: 1. Find the vector between point 1 and point 2. 2. Find the length of that vector using your math of choice. I just used Sqr((x*x)+(y*y)+(z*z)), which is plenty fast. 3. If that delta length is <= 0, set it to some very small number. 4. diff# = (deltalength - distance you want the two points to be apart)/deltalength. 5. totalmass# = (mass of particle 1) + (mass of particle 2). 6. Multiply the vector you found in Step 1 by (diff * (mass of particle 2/totalmass)) and subtract the result from the position of particle 1. 7. Multiply the vector you found in Step 1 by (diff * (mass of particle 1/totalmass)) and add the result to the position of particle 2. Trust me, it works great. With this system, particles of high mass move proportionately more slowly, which gives you the whole off-center rotational thing you're looking for. I also use this same function in my collision routines, which makes things bounce off each other wonderfully. Can't use Blitz collisions with this system, though. |
| ||
| Miracle, Thank you for your insight. I have been able to reduce the number of operations to 1/3 using the Sqr approx. However, I will give your suggestion a try. Can't use Blitz collisions with this system, though. Please elaborate. |
| ||
| Please elaborate. Blitz collisions work great for things like keeping a car from falling through the ground or other movable-to-immovable object collisions. But if, say, you have two cars and want them to collide and bounce realistically off each other, Blitz collisions don't do as well. The way Blitz collisions work, one object runs into another and stops cold (or slides around it). This dynamically changes the position of the moving object, but doesn't change the object it just ran into. Since the change in relative positions of objects are a big part of how Verlet physics work, you end up with one object bouncing off the other as if the other object had infinite mass. On the other hand, if you handle collisions mathematically (i.e. "Oops, particle A is too close to particle B, I need to push them apart"), you can change the positions of both particles simultaneously, which makes them bounce off each other in a more realistic fashion. On the down side, this method is a lot more work since it requires you to keep track of which particle is getting too close to which other particle. If you only have two or three moving items, it's not so bad. If you're throwing around ten thousand bouncing constructs, however, it gets a little complicated. |
| ||
| miracle, check out the moving-moving collision lib by binary_moon(I think...). It is being optimized right now by sswift. I'll be using it for my physics system once it's finalized. |
| ||
| It was done by SimonH if I remember correctly.... |
| ||
| doh. Well, binary_moon was talking to sswift alot about it in the last topic. Probably simonh. Actually, yeah. now I remember... |
   |