Cost of moving/rotating a prim affected by phys?

Just curious: I'd imagine phantom prims should be easier on sim ressources, though I haven't tested that. Especially when moving them...

Based on that premise, I'd conclude that rotating a texture on a prim would be less laggy than actually rotating the whole prim?

An example there would be clock hands. The hands could be thin prims that rotate. Or they could be flat, and have an alpha texture on it that rotates (alpha bug nonwithstanding). Would rotating the texture be causing less lag? Or no difference either way, presuming an otherwise identical script?

For non-physical prims, I doubt it matters much on phantom vs not phantom. For physical ones, I'm not sure it matters but if it does, phantom ones are probably cheaper.


It depends.

If you're taking about doing a small rotation once a second, I still don't think it matters much - either way, the sim has to do an object update and I'd guess that the info it sends to say "rotate this prim" is probably similar to what it sends to say "rotate this texture."

If you're talking about doing a constant rotation, llTargetOmega or llAnimateTexture, those are both client-side effects so they cost about the same. The target omega is probably the more expensive one though, as it has some funky tie-ins with physics.

/me looks at her post and wonders why she bothered. Yes but not except sometimes. Er..

Good points, I hadn't thought about the possibility of the sim just sending the info to the viewer. I kinda only thought Havok cost...

As far as llTargetOmega/llAnimateTexture goes, I've never been able to get that to work for very very slow rotating objects (with the clock example, minute hand, let alone hour hand). Seems that the precision there just rounds 1/3600 (one rotation per hour, as an example) down to zero.

There are a few ways to do it. But I would rotate a texture if you can.
One way is to call llRotateTexture every minute but that's not a method I would recommend unless you need some kind of highly accurate and dynamic display. Like a pressure gauge that could change at any time.

As for a clock that has a constant rotation, you will only need to check it's accuracy every so often.
So in this case I would use the llSetTextureAnim settings to rotate the image in a smooth format.
Then have the script check a clock's texture rotation every 5 minutes or so. Or just reset the rotation when it completes a full rotation. Again it's just used to keep accurate time in this case so it's better than directly moving the texture every minute, or worse, every second.

Also a texture can rotate on it's own without a script once it's set by llSetTextureAnim. If you don't require an accurate rotation then you can just set the rotation with a script and delete it. That prim will remember the effect and now you have one less script/timer going on the sim.

I believe this is also true for llTargetOmega. So if you must do a prim hand for a clock then use llTargetOmega and check it's alignment every so often. Again we just need to make sure it's keeping accurate time every so often. Similar to the texture format.

But a texture is the way to go in my opinion.

Makes sense. I just wish llTargetOmega (or llTextureAnim for that matter) would even support REALLY slow movement. They both do not, as near as I can tell. Again using the clock example (very useful, that), you seemingly cannot set a rotation equaling 1 rotation per hour.