[Opensim-dev] Technical questions from a viewer developer - varregions

[cinder@cinderblocks.biz]

Hi,

> On Saturday, May 13, 2023 at 11:54 PM, John Nagle <nagle at animats.com (mailto:nagle at animats.com)> wrote:
> I'm working on a new viewer. It's connecting to Second Life, and to
> non-varregion Open Simulator regions. Varregions don't work yet.
> I need more info on them.

I wrote the original implementation of varregions in Firestorm for AuroraSim which was used as a reference to implement OpenSim/Singularity support for varregions. There are some fine differences between Aurora’s implementation and OpenSim’s, but it appears that Aurora has since been abandoned. I wrote a new implementation when I added OpenSim support to Alchemy Viewer that removed support things that OpenSim had not implemented (IIRC, oblong shaped regions.)

>
> ## Simulator to client protocol for connecting to regions
>
> The Open Simulator wiki says, at
>
> http://opensimulator.org/wiki/Varregion
>
> "The implementation uses the Aurora large region protocol extensions so
> the existing Firestorm and Singularity Aurora support will now work for
> OpenSimulator."
>
> This references
>
> http://opensimulator.org/wiki/Varregion/Protocol
>
> which says:
>
> Simulator to Client Protocol
>
> EnableSimulator event message: add integers 'RegionSizeX' and
> 'RegionSizeY'
> CrossRegion event message: add integers 'RegionSizeX' and
> 'RegionSizeY' to 'RegionData' section.
> TeleportFinish event message: add integers 'RegionSizeX' and
> 'RegionSizeY' to 'Info' section.
> EstablishAgentCommunication event message: add integers
> 'region-size-x' and 'region-size-y'.
>
> This is, apparently, obsolete, according to Ubit. Although there is
> still code for those LLUDP messages in Firestorm. Does anything still
> use those now-blacklisted UDP messages? Ubit has said that region size
> info is now passed via an HTTP capability. But which capability, and in
> what format?

EstablishAgentCommunication is absolutely still required. It’s extremely likely the data is being passed over EQ but I can’t be arsed to check right now. I would certainly not rely on the caps system wholey and leave the LLUDP fallback in place.

>
> The obsolete Varregion article also says that regions are limited to
> multiples of 256x256 and that sizes cannot be mixed for regions that
> touch. Are those obsolete restrictions, or should mixed-size regions
> be handled?

Indeed, both my implementations support rectangular sized regions. I had a 2048x256 racetrack on Aurora and was very pleased with how it ran. I believe OpenSimulator stuck with square multiples of 256 as a matter of simplicity (possibly power-of-two? Never tested 768x768 or something there likely no.) Aurora was limited to rectangular power-of-two sized regions, but things go pear shaped below 256.
> If so, how does a sim find all its neighbors?

The Simulator has no “neighbor” concept. The Agent connects to a primary region and “child” regions which are its neighbors.

> Are non-square regions now supported?

Client, yes, OpenSimulator, no.

> (An argument for mixed-size regions in a grid is that you can have large
> regions of mostly empty space as large regions, with smaller regions
> for heavily populated areas. I'm willing to support that if the protocol
> is documented.)
>
>
> ## Terrain patches
>
> The wiki says " Implementation Discussion (Obsolete)", and
> that, as of the obsolete version, terrain was sent the Linden Lab way,
> as patches with discrite cosine transform compression. The discussion
> on the wiki suggests this be replaced with generalized meshes. Was that
> ever supported? I would guess not, but would like to be sure before
> I implement.

Doubtful.

> For larger regions, do the terrain squares get bigger than LL's 4x4
> meter size? Or are there just more 4x4 terrain squares?

More terrain squares.

Hope this helps!