search

IslandzVW / halcyon

InWorldz Halcyon 3d virtual reality world simulator
BSD 3-Clause "New" or "Revised" License
21 stars 26 forks source link

Prim Vanishing Act! Prim attribute problem. #460

Closed Vinhold closed 6 years ago

Vinhold commented 6 years ago

This problem was discovered quite by accident. This effect happens on all Halcyon grid installations including InWorldz. This is only an option in FireStorm at the moment and the cure can be applied using Alchemy or perhaps IW V3.

  1. Using FireStorm: Rez a cub. Edit it, open Options tab. Use the Revolutions setting to increase the entry. The cube will instantly vanish from sight. It is still there, but Firestorm will no longer render it.
  2. Relog using Alchemy. You will see the vanished prim. Change any other attribute Except Size. That action will alter the prim options (apparently zeroing the invalid settings). The options for Revolutions and Radius do not display in Alchemy unless a prim type that supports them is selected.
  3. Relog in FireStorm and the cube will be visible again.

In Second Life, using FireStorm, repeat the same process and the cube will just sit there for all the setting changes. No change in its appearance. A change of prim type will show the current effect on the prim. Cubes will not show them. Something is going on with either the data in Halcyon or when Firestorm gets something invalid it refuses to display it. Can be a source of ghost prims that wont go away or be detected by FireStorm viewers, but will be run into by physics interaction. Perhaps SL does not send the invalid attributes to the viewer, so the cube remains visible, where in Halcyon FireStorm chokes on it. Alchemy does not accept or try to display the invalid attributes even though they do exist on the prim. This is proven by changing the prim type to one that supports the attributes and you will see them applied.

zauberparacelsus commented 6 years ago

I've seen this problem before, but it was with prims that normally use revolutions, IE: torus, tube, and ring. This happens only on Firestorm 5.0.11, earlier versions such as 5.0.7 do not have the problem.

Vinhold commented 6 years ago

This is not a Halcyon related problem. I just received confirmation from Emperor Starfinder that this is a bug created in FireStorm release while attempting to correct another problem related to SL and the Havoc restrictive license Havoc has. It was a mesh related problem. So it somehow created a rendering problem with the cubes by trying to render invalid attributes for the prim type. This problem also happens in OpenSim. I am using FireStorm 5.0.11.53634 which appears to be only related to that release so far. Object parameter bug with Firestorm.pdf

zauberparacelsus commented 6 years ago

Again, this also happens with prims that are supposed to use revolutions (IE: torus, tube, ring).

Vinhold commented 6 years ago

I just confirmed that attempting to set a revolution on any prim type will cause it to vanish in FireStorm. Using Alchemy to change the prims to have hollow set restores them to FireStorm visibility again. Again if the revolutions is changed in FireStorm, the prim will vanish. Interesting that reducing the Revolutions if >1 will work fine. Only increasing it will make it vanish.

appurist commented 6 years ago

This appears to be a problem when the change to revolutions != 0 is made by FS 5.0.11. It updates the Revolutions but does not force the Skew to 0.67 as other viewers do. I think it rejects this update invalid in a way other viewers do not, by blacklisting the prim until it gets a new update without the inconsistency. Without skewing the prim, rotations > 1.0 cause an overlap in the volume, so that may be directly related here.

At any rate, this really looks like something that should be reported to the Firestorm team as it is specific not only to that viewer but to the most recent version of that viewer. Perhaps they removed the automatic auto-correction to always change the Skew field if you change the revolutions in a way that requires some skew.

appurist commented 6 years ago

Firestorm has "strict object checking" enabled now and the edit (by the Firestorm viewer) actually puts the prim in an invalid/inconsistent state and thus is removed from view.

This is a known (reported) bug in the Firestorm viewer, visible on OpenSim/Halcyon grids. See Firestorm bug report FIRE-22278.

This is likely only a problem on OpenSim/Halcyon grids because Second Life probably has extra repair code to auto-repair the inconsistent prim settings, but the problem is in the Firestorm update to the prim.

The Firestorm team has disabled the strict checking on OpenSim grids, but that's really a workaround to allow the prim (with the now-invalid settings) to continue to be seen. Ideally they will address the actual problem of not updating the Skew now that I've provided some additional info on the problem.

appurist commented 6 years ago

Note that the Firestorm team has since disabled this strict checking on OpenSim/Halcyon grids, so any newer Firestorm (currently unreleased and only in development) allows the prim to continue to be seen. Apparently anything from rev 55135 or later has the strict checking disabled again. However, this doesn't address the root cause of the problem so I've pointed this out and hopefully the next update will avoid the inconsistency completely.