[sldev] [VWR] Scale not sticking

Dale Mahalko dmahalko at gmail.com
Mon Mar 3 03:54:07 PST 2008


I would like to point to some Google Videos I created many months ago,
involving these kinds of prim editing problems when moving or rotating
a huge number of unlinked primitives. I made the movies back in Oct
2006, but these editing annoyances have probably been around for years
longer than that.


Basically, when you edit something in SL, the client immediately shows
you the results of the action, before the server has finished
receiving all the data that encodes for the new orientation. The
client makes all edits appear to be instant, but in truth they are
not.

Periodically the server sends out a status message of where it thinks
those objects should be, and this update will move the objects on the
client's screen to where the server thinks they are.

Second Life Editing - Slow position updating.
http://video.google.com/videoplay?docid=-2684000491129635519&hl=en

When editing a huge number of individual objects simultaneously (in
the videos I am editing a stack of 1458 unlinked cubes) it takes a
very long time for the client to send all the new object orientations
to the server. This results in a weird bubbling and shifting around of
the objects while the data continues to be sent. The client gives you
no indication that any data is being sent, nor does it indicate how
long it will take to finish, or when it is actually finished. .



A rather annoying result of this lack of client feedback to the user
is that you can edit a huge collection of objects, wait not long
enough for the updates to finish, and do another edit, which then
aborts the previous object updates before it could finish and
immediately starts sending this new positioning data:

Second Life Editing - Corrupted prim rotation
http://video.google.com/videoplay?docid=-8608210525014859556&hl=en

If you wait this out you will see that your primitives half rearranged
through the first edit before your second edit aborted it and took
over, resulting in a huge mess of prims all over the place. Because
some prims were updated twice and some once, usually this mess cannot
be undone in any rational manner and all objects must be deleted so
you can start over.



The proper way to edit a huge collection of unlinked prims is to do
the edit, and then leave your client alone for an undefined long
period of time waiting for the updates to finish on their own.

Second Life Editing - Rotating hundreds of prims
http://video.google.com/videoplay?docid=-2327329216734064920&hl=en

If you wait long enough the updating should be finished before your
next edit, but the client gives no indication of when that will be.



In short, I think the way the editor handles these background object
edit updates sucks and the client needs to be revised to give the user
much more direct feedback of what is going on and when it will finish.

There should be some indication that the instant primitive
repositioning shown in the client is a preview only, and the
primitives are not really in that position and will not be until the
updating finishes. This could be done by showing the primitives in the
old position AND the new position, with the objects in the new
position being a wireframe version of the old, while a status box
appears onscreen saying "Moving primitives to new location.  3%
completed.."  As the objects are moved and updated by the server, they
fill in the wireframed preview.

Attempting to do an edit of objects that haven't finished updating
should pop up a warning that the previous updates are not finished and
doing an edit now could corrupt the previous edit, along with buttons
like "Do this Edit" and "Abort this edit", with abort as the default
to permit backing out of this ill-advised edit.

- Scalar Tardis / Dale Mahalko



On Sat, Mar 1, 2008 at 5:19 PM, Anna Gulaev <annagulaev at gmail.com> wrote:
> I'm trying to re-scale (and also potentially re-position and rotate) a set
> of objects using MultipleObjectUpdate following the example of
> LLSelectMgr::sendListToRegions(). I'm finding it rather unreliable.


More information about the SLDev mailing list