[Opensim-dev] How objects cross regions, at the message level. Questions.

[Dahlia Trimble]

One thing I've done is cache geometry and textures. I'll hash geometry
parameters for each object and store the geometry in GPU memory based on
this hash code, which allows me to only have one copy of geometry in memory
for all prims or objects of the same shape. If geometry isn't referenced
for some time, say several minutes, I'll mark it as being able to be
deleted, but this seldom happens as such shared geometry isn't usually a
large share of GPU memory. For textures, I'll use the UUID instead of a
hash code and treat them similar to geometry. The benefit here is I only
have to make a given shape once and this can save quite a bit of time and
mempru. It also speeds up rendering significantly because I can sort by
geometry hash and/or texture UUID along with my other sort criteria prior
to rendering a frame, and this can reduce buffer binds which also speed up
rendering. While it doesn't cover all the problems you're facing in your
post, considering such methods might help with the flickering you describe
when you need to rebuild an object, because you wouldn't need to "rebuild"
it.

I realize you're using a pre-existing renering engine which might not be
able to function in this matter but it might be worth considering as
perhaps a similar technique might work for you.

Hope that helps,
-D

On Fri, Nov 17, 2023 at 12:25 AM John Nagle <nagle at animats.com> wrote:

> I'm the guy coding the Sharpview viewer in Rust. The released demo
> (at https://www.animats.com/sharpview, use username "devs", password
> "thread") only loads one region and you can't leave it or see others.
> I'm working on supporting full grids. Current status is that I can
> see neighboring regions come up, but can't cross into them.
> So, some questions:
>
> How linksets cross regions:
>
> 1. ObjectUpdate messages (compressed or not) contain the parent ID of
> the parent ObjectUpdate. Parent IDs are region-local.  Each ObjectUpdate
> also has a Object ID (a UUID) which is, I think, unique to that object
> over the whole grid. Is that correct? Are there ever duplicate Object IDs?
>
> 2. When a linkset moves from one region to another, it is re-created
> in the new region, with an object update for each prim.
> This implicitly kills it in the old region. Sometimes a KillObject event
> is sent, and sometimes there is no KillObject event.
>
> 3. The object updates which create an object in the the new region
> are not always in the same UDP message. So there are potentially
> partially-created objects in the new region.
>
> 4. The obvious implementation is to just create the object in the new
> region, and kill it in the old region. But if you do that, it flickers
> when crossing regions, because it's being completely rebuilt from
> scratch. This looks bad. So the SL C++ viewer and the ones based on
> it try to transfer the object tree (root and children) to the new
> region when the object is re-created in the new region.
>
> 5. That may not work reliably. Transferring the object tree moves
> it to a new region where the local IDs are all different. As the
> object gets re-created in the new region, I think those bad values
> get overwritten before they are ever used. Most of the time.
> Whether this works may depend on object update order.
> I'm not convinced that this is safe code. It may be the cause
> of avatar attachments falling off at region crossings.
> I am not sure about this. I don't see any code in the C++
> viewers to fix parent IDs. Am I reading that correctly?
>
> 6. I'm thinking that the right way to do this is to
> look up the Object ID for a parent ID and local ID as
> soon as an object update is received, and index
> everything viewer side by object ID. That way,
> moving an object or object subtree to a new region
> should be sound. Is that reasonable?
>
> (OS and SL only allow a 3-level hierarchy now.
> Worst case is vehicle/avatar/attachments. But
> I code Sharpview assuming that a full hierarchy
> is coming, because that is an accepted JIRA on the
> Second Life side. When full glTF content loading
> is added, that will probably go in, because glTF
> has a full hierarchy, unlike COLLADA. So I want to get
> the general case right.)
>
>
>                                 John Nagle
>                                 Joe Magarac (OSgrid)
>                                 Animats Resident (SL)
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at opensimulator.org
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>