set rot + target omega

ohai, i have thing i can't sort out.

The object is the front wheel of a car (1 prim sculpted spokes). I'm using setlocalrot to turn the wheel to the left and right. I'm using targetomega to rotate the wheel at the driving speed.

This all works, except there is a short stoppage in the omega when the setlocalrot happens. This is pretty much as I expected it to work.

Now, the problem is that i've seen a car with sculpted front wheels that look pretty decent combining the rot and spin and now i'm pulling my hair out

vector current_rot = llRot2Euler(llGetLocalRot());
vector new_rot = llRot2Euler(<local_target_rot>;
llSetLocalRot(llEuler2Rot(<new_rot.x,new_rot.y,current_rot.z> );
llTargetOmega(<0.0, 0.0, 1.0> * llGetLocalRot(), rotation_speed, 0.1);

If anyone has any ideas on how to do this clean i'd love to hear them. thanks!

target omega has a zero delay...
set local rot has a 0.2 sec delay...
delays are applied AFTER the function takes effect...

so swap the order to get them closer together.

(and you'd be much better served to do you rotations in rotations instead of down-converting to Euler's and then up-converting back to rotations, which is going to slow you down, and add file size)

i should have been more specific i think. even if you put the omega before the rot it does the same thing, which is this :

it goes to a zero omega, lets call TDC (top dead center) and then begins the rotation.

so what i tried to do was detect the rotation on the wheel spin axis and apply that to the new rotation before starting the omega, but it doesn't capture true. it doesn't capture where it is currently from the target omega.... so TDC might be on the bottom as seen in the client from the omega, but the get local rot will report TDC at the top as if the wheel is not turning.

It flips the prim to zero instead of continuing from where it left off creating a stutter in the visual.

//EDIT

closer inspection of the car with the "working" sculpted rims shows that it does have the same problem of the omega starting from the same spot. it's just less noticeable with a little speed.

i consider it unpossible again.

I'm going to do it this way and call it lunch :

llTargetOmega(<0.38268, 0.92388, 0.00000>,turn_rate,1);
llSetLocalRot(<-0.13795, -0.69352, 0.69352, 0.13795>;

i'll update the omega's turn_rate once a second while speed is above 1mps and below 40 or so. it only stutters when a rot has to be applied.

Thanks

Anyone have a diffrent take on this? As of now I have come up with the same problem and well semi fix as Les, Just to make it "wobble" a little less. Would love to see some diffrent ideas if there are any thanks.

Raver Bellow

it might be that the person with the "working" version is recalling the target omega in a timered loop, so that the cal hits pretty close to the starting point (but i'd expect semi frequent micro jumps, either forward or back. and it'd be kinda laggy)

does target omega physically spin child prims on vehicles, or does it use the viewer to do it?, if it physically spins them you could set a rotation target, and trigger the update when it's within the range of that... that's the only other thought I could imagine working.

https://wiki.secondlife.com/wiki/LlRotTarget

Try rotating the texture on the outside of the wheels (or maybe the treads too) instead.

It will look better if you edit your texture by blurring it in strategic locations so it looks more authentic when it is moving. Putting it together, you use two or three textures: one for standing still, one when moving slowly, and one for fast. Once you get that working there are ways of preloading textures so that the transition between them is smoother.

HTH! -2fast