Projected-light slowly "drifts" from TargetOmega use??

[Miles Doge]

As weird as the title is, this is the best way i can label my little predicament here....I was hoping someone here may have a solution or idea of what's going on here, but to give some detailed context:

The item: A friend of mine recently created an "illusionary" attachment for themselves, which contains a link-set of multiple projected light primitives, and a cylindrical prim. Each point-light prim is set to plainly spin using llTargetOmega(), while their lights are pointed directly at the cylinder primitive. The cylinder primitive has a specular gloss of 255, and an environment of 125 applied to it. Now for those who aren't aware of what exactly this does...When projected-light are pointed towards a primitive with gloss & environment like this, it can actually create some rather cool "reflective/mirror-like" effects, that can make for creating some neato false scenery or seemingly 3D portals; and that is precisely what we're dealing with here!

The issue: After completing this little light trinket of theirs, said friend eventually reached out to me with an issue, noting that their point lights had some form of "drift" that would occur after a considerable amount of time has passed (usually about 2 minutes or more, but the "drift" becomes even more noticeable if you wait even longer). Now, initially, my first assumption towards this "drift" issue, was that they might've just been calling llTargetOmega() before having the projector-light prims properly rotated & aligned a full 90 degrees, so that their (obvious client-side) rotation would rotate consistently throughout.

Test: To test that this issue wasn't just a matter of improper prim alignment (and to freshly test this overall), I completely recreated their trinket completely from scratch, including rewriting the EXTREMELY SIMPLE llTargetOmega() scripts that were involved with the trinket. I found that when these point light prims *weren't linked* at all, the aforementioned "point-light drift" was not an issue at all, nor did it ever occur as far as i could tell. However if they *WERE* linked, the "drift" would inevitably start to occur overtime. I tried a few different attempts at writing the llTargetOmega call differently with the linked point lights, and found still, that the issue persists.

I even tested to see if this problem happens with some of my own projected-light illusion contraptions that utilize a similar layout, and again, i found that all of them in some way or another, had this inevitable "drift" issue; despite the prim itself showing no signs of being "misaligned" whatsoever...I'm at a loss for what's the cause of this, but i can only assume its some strange unavoidable sight effect with spinning linked projected lights with llTargetOmega. 

Visual: To better show the problem I'm referring to, i've attached a gif to this post. If you pay CLOSE attention to the bottom of the outer ring, you will see that the projected-light slowly (but surely) drifts closer and closer towards the (unlinked) wooden "plane" seen just below the point-light effect. Right clicking the object seems to reset this issue as if nothing occurred, which (again) leads me to believe this is some kind of side-effect caused from calling llTargetOmega on a linked prim utilizing projected-lights. I'm certain there's some other method of constant rotation i could go about to avoid this problem altogether, but i first wanted to see if anyone else had ever encountered this issue before.

Edited January 11 by Miles Doge

[Love Zhaoying]

18 minutes ago, Miles Doge said:

The issue: After completing this little light trinket of theirs, said friend eventually reached out to me with an issue, noting that their point lights had some form of "drift" that would occur after a considerable amount of time has passed (usually about 2 minutes or more, but the "drift" becomes even more noticeable if you wait even longer). Now, initially, my first assumption towards this "drift" issue, was that they might've just been calling llTargetOmega() before having the projector-light prims properly rotated & aligned a full 90 degrees, so that their (obvious client-side) rotation would rotate consistently throughout.

Is this being tested / problems reported at a high elevation? If so, have you tried it both at ground level and at high elevation?

[Miles Doge]

15 minutes ago, Love Zhaoying said:

Is this being tested / problems reported at a high elevation? If so, have you tried it both at ground level and at high elevation?

Thus far, i've only tested this at ground level, but not any higher elevations. I must apologize when i say, I'm not sure what difference elevation would make for the drift to occur or not but its worth a shot in testing!

[Love Zhaoying]

2 minutes ago, Miles Doge said:

I must apologize when i say, I'm not sure what difference elevation would make for the drift to occur or not but its worth a shot in testing!

No problem. The reason I asked was, at higher elevation there are MORE issues for some features (because calculations, rounding errors, etc. are impacted).

Since you're at ground level, then don't worry too much about what I asked. 🙂

 

[Wulfie Reanimator]

Does this drift happen only in the "reflection" or does it also show up in the projected light? (I imagine it must happen on both, but weirder bugs exist.)

This definitely should go on the Jir- uhh... Github Issues? Canny? Somewhere.

Edited January 11 by Wulfie Reanimator

[Qie Niangao]

I wonder what's drifting though. The projected lights are presumably just tracking the colinear (local) Z axes of the linked emitters. The llTargetOmega is all viewer-side until you grab the object which will force the viewer's model of the object to re-sync with the server's, so… maybe there's some kind of minuscule rounding error in that local coordinate calculation within the viewer. 

If I had a test unit set up, the first thing I'd try is throw in an occasional hovertext update on the premise it might force an object update that could re-sync that local geometry in the viewer. But when it didn't make a difference, I'm not sure I'd have disproven anything.

[Love Zhaoying]

1 minute ago, Qie Niangao said:

I wonder what's drifting though. The projected lights are presumably just tracking the colinear (local) Z axes of the linked emitters. The llTargetOmega is all viewer-side until you grab the object which will force the viewer's model of the object to re-sync with the server's, so… maybe there's some kind of minuscule rounding error in that local coordinate calculation within the viewer. 

If I had a test unit set up, the first thing I'd try is throw in an occasional hovertext update on the premise it might force an object update that could re-sync that local geometry in the viewer. But when it didn't make a difference, I'm not sure I'd have disproven anything.

Makes sense. llTargetOmega() can be somewhat haphazard..(don't touch it, it'll stop!)

[Miles Doge]

10 hours ago, Wulfie Reanimator said:

Does this drift happen only in the "reflection" or does it also show up in the projected light? (I imagine it must happen on both, but weirder bugs exist.)

This definitely should go on the Jir- uhh... Github Issues? Canny? Somewhere.

Apologies for the delayed response. Quickly testing this on a simple rezzed wooden prim reveals that the projected light itself does indeed still "drift" It doesn't seem to be something specific to the reflection at all. (shown with the first two images)

I probably forgot to say this in the original post also, but: If i were to unlink one of the spinning projected-light prims from the linkset of this trinket, the point-light that's emitting from that unlinked prim no longer shares this drift issue, but the rest of the spinning point lights do.

This can be seen with the last two images; While the red colored point light remains stationary. The outer surrounding point lights are slowly drifting downwards (the central "triangle" point-light should also be seen as unaffected as it does not spin at all).

Edited January 12 by Miles Doge
Whoops. i pasted the images weirdly into this post

[Qie Niangao]

21 hours ago, Miles Doge said:

Right clicking the object seems to reset this issue as if nothing occurred, which (again) leads me to believe this is some kind of side-effect caused from calling llTargetOmega on a linked prim utilizing projected-lights.

This is a fun one. I'm not 100% sure how to force a complete object update to the viewer, but that doesn't seem to be the problem anyway. The phenomenon here seems to be very specific to projected light, which I didn't expect. Here's a little test script:

string PROJ_TEXTURE = "fabbb720-cb4c-f8a4-ba9b-b5c83451d73d";   // cross-hair stolen from another forums thread

default
{
    state_entry()
    {
        llSetLinkPrimitiveParamsFast(LINK_ALL_CHILDREN,
            [ PRIM_OMEGA, <0, 0, 1>, PI_BY_TWO, 1.0
            , PRIM_POINT_LIGHT, TRUE, <1, 1, 0>, 1.0, 1.0, 0.0
            , PRIM_PROJECTOR, PROJ_TEXTURE, 0.05, 0.5, 0.0
            ]);
        llLinkParticleSystem(LINK_ALL_CHILDREN,
            [ PSYS_PART_FLAGS, 0 | PSYS_PART_EMISSIVE_MASK
            , PSYS_SRC_PATTERN, PSYS_SRC_PATTERN_DROP
            , PSYS_PART_START_COLOR, <1, 0, 0>
            , PSYS_PART_START_SCALE, <0.035, 0.035, 0>
            , PSYS_SRC_ACCEL, <0,0,-1> * llGetRot()
            , PSYS_PART_MAX_AGE, 1.0
            ]);
        llSetTimerEvent(1.0);
    }
    timer()
    {
        llSetLinkPrimitiveParamsFast(LINK_ALL_CHILDREN,
            [ PRIM_POS_LOCAL, <0.1,0.1,0>
            ]);
        llSleep(0.2);
        llSetLinkPrimitiveParamsFast(LINK_ALL_CHILDREN,
            [ PRIM_POS_LOCAL, ZERO_VECTOR
            ]);
    }
}

The timer event was to test object updates; I tried llSetText, llSetScale, and finally in this version, re-aligning the child prims. I also tried toggling PRIM_POINT_LIGHT, but none of this mattered, which is weird because we know it's a viewer effect, so one would think it would correct if the viewer's representation of the projecting links was re-sync'd with the server's.

We know the projection, after drifting, restores to its original position if the object is grabbed in the editor, or (as I expected and found) if the observer leaves the region and returns, further illustrating that whatever is drifting it's in the viewer's representation of something.

But particles are viewer-side effects, too, and yet they do not drift with the projection, so whatever's drifting viewer-side, it's not something shared with particles.

So I definitely agree with @Wulfie Reanimator, this deserves a bug report, however we're supposed to do that right now.

[ETA: I wonder why it drifts downward, specifically. That seems as if it could be a clue.]

Edited January 12 by Qie Niangao

[Love Zhaoying]

26 minutes ago, Qie Niangao said:

21 hours ago, Miles Doge said:

Right clicking the object seems to reset this issue as if nothing occurred, which (again) leads me to believe this is some kind of side-effect caused from calling llTargetOmega on a linked prim utilizing projected-lights.

This is a fun one. I'm not 100% sure how to force a complete object update to the viewer, but that doesn't seem to be the problem anyway. The phenomenon here seems to be very specific to projected light, which I didn't expect.

The fact that "right-clicking" the object "resets" the drift, sounds exactly like what normally happens if you right-click any object that is being acted on by llTargetOmega().

By extension, I conclude that this is highly likely to be a bug with llTargetOmega()..! Of course, just "stopping" llTargetOmega() should reset the object to the pre-drift position to help "prove" this..

One thing to try would be after a time, "reverse" the llTargetOmega() to the "other direction", etc. - which may be a more pleasing affect then just "stopping" llTargetOmega(). Of course, stopping llTargetOmega() always results in a "jump" back to the object's "actual" position. 😞

 

[Miles Doge]

5 hours ago, Qie Niangao said:

The phenomenon here seems to be very specific to projected light, which I didn't expect. [cut]

I definitely agree with @Wulfie Reanimator, this deserves a bug report, however we're supposed to do that right now.

5 hours ago, Love Zhaoying said:

The fact that "right-clicking" the object "resets" the drift, sounds exactly like what normally happens if you right-click any object that is being acted on by llTargetOmega().

By extension, I conclude that this is highly likely to be a bug with llTargetOmega()..! Of course, just "stopping" llTargetOmega() should reset the object to the pre-drift position to help "prove" this..

On 1/11/2024 at 10:09 AM, Miles Doge said:

but i can only assume its some strange unavoidable sight effect with spinning linked projected lights with llTargetOmega

The way i worded my sentence in the OP, was definitely meant to convey needing a combination of the two things here to cause the condition. While the drift is specific to the projected light itself, it can only happen with the help of llTargetOmega rotating the prim emitting that light.

All in all though, i do agree it should be bug reported! I don't particularly recall where/how to go about doing that again (its been a while), but if it adds any helps at all for demonstrating the process, i did try to throw together a quick video demonstrating the "drifting" itself the other night.😅

[Qie Niangao]

17 hours ago, Miles Doge said:

All in all though, i do agree it should be bug reported! I don't particularly recall where/how to go about doing that again (its been a while), 

Okay, I made one in the new Canny thingy: https://feedback.secondlife.com/bug-reports/p/projected-lights-from-linked-lltargetomega-prims-slowly-drift-downwards

I also tested some other orientations of the projection setup, and found that as far as I can tell the drift is negative Z in region coordinates, and won't happen if the light is projecting straight up or straight down. Any other orientation, it's like the direction of light projection, -Z in the emitter's coordinate system, is very slowly drawn in the direction of -Z in region coordinates. Not that this is likely to have anything to do with the bug, merely describing how it behaves.

Edited January 13 by Qie Niangao

[Frionil Fang]

31 minutes ago, Qie Niangao said:

the drift is negative Z in region coordinates, and won't happen if the light is projecting straight up or straight down

That explains why I saw nothing when I left a test object running for half an hour. Mental note to check the viewer code how the local prim omega effect is computed out of curiosity. If I had to guess, the child prim rotation is constantly referencing the root prim in some way that slowly accumulates and turns the axis towards -z (the position probably doesn't change)..

[Qie Niangao]

1 hour ago, Frionil Fang said:

That explains why I saw nothing when I left a test object running for half an hour. Mental note to check the viewer code how the local prim omega effect is computed out of curiosity. If I had to guess, the child prim rotation is constantly referencing the root prim in some way that slowly accumulates and turns the axis towards -z (the position probably doesn't change)..

Specifically the axis used by projected light, though, not the direction particles are emitted—oh! of course! particles emit in region coordinates, regardless of the orientation of the emitter. So yeah, if the viewer thinks the child prim has tilted downward, it would only affect the projected light.

Now... if one waits long enough, that projected light drifts pretty far, far enough one could detect whether the emitting prim is also drawn at a corresponding angle. That might help isolate the bug.

Edited January 13 by Qie Niangao

[Wulfie Reanimator]

4 minutes ago, Qie Niangao said:

Specifically the axis used by projected light, though, not the direction particles are emitted—oh! of course! particles emit in region coordinates, regardless of the orientation of the emitter. So yeah, if the viewer thinks the child prim has tilted downward, it would only affect the projected light.

The emitter's rotation affects the direction of particles, easiest way to see that is with Angle Cone -type emitters.

[Frionil Fang]

Well, I can't claim I'm clever enough to give the exact how and why, especially why only a child prim as I don't see any obvious special handling for child prim omega, but it seems like a case of traditional floating point inaccuracy.

The viewer keeps track of an "accumulated angular velocity" quaternion: each update, it gets the time passed since last update, generates a rotational change quaternion from this time and composes this rotation with the accumulated velocity. Repeated composition of quaternions is almost certain to start to drift, there is only so much precision.

If my logic is right, this also means the drift becomes worse the better your framerate: more frames = more updates = more repeated quaternion compositions. Supporting this is that I couldn't quite get the drift to happen by letting a spinny light stay in the background, but once I turned off the background framerate throttling, it became apparent after a couple minutes.

Edit: the relevant code is in indra/newview/llviewerobject.cpp, void LLViewerObject::applyAngularVelocity(F32 dt)

Edited January 13 by Frionil Fang

[Qie Niangao]

32 minutes ago, Wulfie Reanimator said:

The emitter's rotation affects the direction of particles, easiest way to see that is with Angle Cone -type emitters.

Oh, that's another line of inquiry; my silly script uses PSYS_SRC_ACCEL on PSYS_SRC_PATTERN_DROP particles, so that's in region coordinates. So yeah, it might be informative to test with PSYS_SRC_PATTERN_ANGLE_CONE instead.

Meanwhile, though, I figured out a reliable way to detect if the emitter itself is drawn at a drifting tilt. It's not.

ETA: and same with particles emitted with PSYS_SRC_PATTERN_ANGLE: they remain directed on the non-drifting axis of the emitter. So the viewer's representation of the emitter itself doesn't seem to be drifting; rather what's drifting must be some separate record of the axis of light projection… whatever that may be.

Edited January 13 by Qie Niangao

[Wulfie Reanimator]

28 minutes ago, Frionil Fang said:

Well, I can't claim I'm clever enough to give the exact how and why, especially why only a child prim as I don't see any obvious special handling for child prim omega, but it seems like a case of traditional floating point inaccuracy.

The viewer keeps track of an "accumulated angular velocity" quaternion: each update, it gets the time passed since last update, generates a rotational change quaternion from this time and composes this rotation with the accumulated velocity. Repeated composition of quaternions is almost certain to start to drift, there is only so much precision.

If my logic is right, this also means the drift becomes worse the better your framerate: more frames = more updates = more repeated quaternion compositions. Supporting this is that I couldn't quite get the drift to happen by letting a spinny light stay in the background, but once I turned off the background framerate throttling, it became apparent after a couple minutes.

Edit: the relevant code is in indra/newview/llviewerobject.cpp, void LLViewerObject::applyAngularVelocity(F32 dt)

Link for easier access: https://github.com/secondlife/viewer/blob/77395eddc911e0801e50fd693f7bbaee8046aa95/indra/newview/llviewerobject.cpp#L6907

And yeah, the problem is obvious. It's not smart to make hundreds and thousands of cumulative changes with floats. I'm fairly sure this function could be rewritten to just not track cumulative changes but always calculate the new rotation based on the original rotation + total time passed. Obviously, precision issues will never go away, but this should avoid visible drift over time.

Edited January 13 by Wulfie Reanimator