EEP problems with Firestorm and SL viewer

[VirtualKitten]

HI I have a problem with the new win light or EEP . It manifests in POINT of LIGHT and not in mesh . It seems to disconnect my light beams from tie lights even though the mesh is moving correctly. I have had a senior technician from Firestorm look at this but he could not work out why it was doing this :https://gyazo.com/801452994091d2a502d5f4db6a0658ac as shown in edit mode and this disjointed in normal view https://gyazo.com/bd2ce31efa50fe4966b1f6a773a032be Is there anyone can suggest to hep as this came n with new EEP in firestorm.

 

Thank you for looking Dx

[Fritigern Gothly]

How is this related to EEP?

[Lindal Kidd]

Silly question...do you have separate prims that are the actual lights...the ones with the "light" property enabled?  If so...are they linked to the spotlight mesh and are they moving/rotating with it?

[VirtualKitten]

My mesh is linked and the linked mesh moves fine without jumping over the screen its the light model that seems to be now causing this aberration jumping all over the place not following the point of light in the mesh.

 

it may be shown better here gifs show the mesh is rotating correctly . The new light model jumps the point of light off the mesh and looks silly

https://gyazo.com/3781c3ad1c5f0d18f3b3adb636889c8f

https://gyazo.com/e73ed9488d6450081e994f19bc43bab2

https://gyazo.com/0ab1aa741539d2a5cfab6238d5d445c2

Edited January 10, 2021 by VirtualKitten

[Qie Niangao]

I'm still not seeing what I'm supposed to see in these gifs, but I'll guess that the problem is with projected light not following motion of the projector. Assuming the motion is simple llTargetOmega, that's all purely viewer-side, so the first question I'd ask is if the same problem arises with other, non-Firestorm viewers. (If you're correct that it's EEP-related, though, almost all viewers have EEP now -- Firestorm was nearly the last to release with EEP, although I think the "official" Catznip release is still pre-EEP, despite their EEP having been in test for months.) Actually, my second question would be whether it's correct that the motion is llTargetOmega, or if instead there's actual server-side motion happening, and my third would be whether it's indeed projected light, not simple point-light emission. And maybe also whether there's been any change in graphics settings, particularly Advanced Lighting Model, Shadows, and (on Firestorm only?) the "Point Lighting: Full" setting.

[ETA: I tried this with Firestorm and both EEP and non-EEP Catznip and everything appeared to be working fine, where "this" is projected lights from nested llTargetOmega()s (root and children spinning in opposite directions) viewed with ALM, full shadows and full point lighting in graphics prefs. So I probably guessed wrong about what I was supposed to be seeing in the gifs.]

Edited January 10, 2021 by Qie Niangao

[animats]

I'm not quite seeing it either.

Projectors normally track the motion of the object to what they are attached quite well. Most vehicle headlights are projectors, and they reliably point where the vehicle is pointed.

LLTargetOmega is for spinning things where you're not that concerned about exact position. Use it for propellers, wheels, and decorative spinning objects. It's usually all viewer side and doesn't load down the sim.

If you need more controlled rotation, I'd suggest using keyframe animation. That's a combination of server side and viewer side, and will get you smooth motion.

A script frantically updating angles many times per second is the least efficient approach, but will work.

By the way, an SL light has four parts:

1. The projection or emission of light from the object. This lights other objects, but not the light source.
2. The color of the face emitting the light. This is often just full bright.
3. Glow. A little glow around a light looks good, but don't overdo. About 0.02 is good for most lights.
4. The visible light cone. That's a separate object, usually translucent and full bright. Textures can give it a nice falloff effect.

Each of those has to be set up separately. But if all are attached to the same object, they should stay in sync.

[VirtualKitten]

yes the projected light model is doing this have been asking lost of people but am still without answer.

[VirtualKitten]

I also should say that I had someone from Firestorm group with me and he could see it on both browsers with the same light error in edit mode the mesh moves perfectly smoothly the light modal jumps about all over the place . The gifs show this clearly This one https://gyazo.com/e73ed9488d6450081e994f19bc43bab2 shows edit mode  others are the out of phase lighting modal It refers to EEP As it came in with this Firestorm release of new lighting modal and EEP I had ROBO over and he could see it happening . as you can see here https://gyazo.com/27c0cfe397edcb37c6354070379223c9 the lighting goes off at 90 degrees and flickers strangely . This does not happening if model is stationary. We also tried in different region a friend in the group secondlife:///app/agent/a305f3dd-17ed-480b-a6b3-70be80cfbc4e/about had a problem with ALM as well Hope this is clearer

 

Edited January 21, 2021 by VirtualKitten

[VirtualKitten]

On 1/9/2021 at 8:40 PM, Lindal Kidd said:

Silly question...do you have separate prims that are the actual lights...the ones with the "light" property enabled?  If so...are they linked to the spotlight mesh and are they moving/rotating with it?

Yes they are Mesh three items per light as it all moves about itself in all directions when its programmed.

[Qie Niangao]

I can finally see something strange in the last one of those ( https://gyazo.com/27c0cfe397edcb37c6354070379223c9 ) but to me it looks as if the object itself disintegrates, as the "lamp" in the middle seems to move normally as the glowing "beam" goes off in some other direction for part of the path. In that video the projected lights do also seem to move strangely, which I think(?) is what we're supposed to see, but with the beam coming detached from the lamp, I now wonder how many links there are in this object, and in particular, what specific links emit light. It seems likely the projected light is going exactly where the projector is pointing, but the light projector is not moving in exact sync with all the rest of the parts.

But I'm also not sure what to make of the jumpiness of the video itself, whether the actual motion seen in the viewer is also that jumpy.

When you say "I had someone from Firestorm group with me and he could see it on both browsers " are "both browsers" the EEP and non-EEP versions of the Firestorm viewer? If so, then we should conclude that it's not related to EEP? (I'm confused.)

I could script up a thing that recreates the object I used to test, which projects light just fine in EEP, but I'm not sure that's of much use. Take my word for it: simple projected lights handle llTargetOmega() motion just fine in EEP, same as always. So the problem is to discover what is so weird about this object, that it misbehaves under some conditions that may or may not depend on the EEP-readiness of the viewer. And so I wonder, is this a commercial product that can be examined at an in-world store, perhaps?