Programming

Doing VarRegion for OpenSimulator

I’ve taken on the task of porting Aurora‘s variable region feature into OpenSimulator.

This port will use Aurora’s protocol extensions so the existing Firestorm and Singularity Aurora support will now work for OpenSimulator. The larger regions size will be restricted to multiples of 256 meters and adjacent regions (the ability to have other regions spacially next to larger regions) will not be implemented and will not work. Additionally, the larger regions must be square. This latter restriction is because the viewers currently (20131101) only use the X size dimension for both X and Y size. These restrictions are enforced by code in RegionInfo.cs which truncates and rounds values and output warning log messages.

The size is be specified in the Region.ini file:

[MyRegionName]
RegionUUID = 95ec77ec-58c5-4ce2-9ff3-b6d1900d78a2
Location = 1000,1000
SizeX = 1024
SizeY = 1024
InternalAddress = 0.0.0.0
InternalPort = 9200
AllowAlternatePorts = False
ExternalHostName = SYSTEMIP

If size is not specified, it will, of course, default to the legacy size of 256.

Since this will be a major change to OpenSimulator that touches a lot of different parts, subsequent posts, will discuss the changes I’m making.

3D Worlds on the web

I’ve been working on LookingGlass which is a stand-alone, you-have-to-download-it viewer for the OpenSimulator virtual worlds. I really wish one didn’t have to download the viewer. Viewing should just happen as part of the web.

I’ve looked at this several times and it looks like the infrastructure is maturing. WebGL is appearing or will soon appear in most browsers. This provides the basis for getting accelerated, 3D graphics on the screen. Additionally, it is standard in the browsers (IE is a problem, Microsoft being who they are, but Google has a plugin to fix that).

Recently, Google has decided to move their O3D project to being a scene graph wrapper for WebGL. This makes JavaScript connect to the 3D world reasonably while keeping all the 3D technology in the standard browser.

The new O3D is early in its development but it is coming. 3D on the web is just around the corner.

Integrating Avatars and Attachments and generalizing entities

I had been fretting about whether avatars and their attachements are first class objects or subclasses of entities. I am now thinking the latter. That is, World just deals with Regions that contain Entities and the Entities have sub-classes that are created by Comm and sensed by the Viewer.

The pattern I’m working with at the moment is (using an Avatar as an example) for there to be a World.IEntityAvatar which defines the operations beyond the base entity. For LLLP, there is a World.LL.LLEntityAvatar that implements the IEntityAvatar and IEntity for an LLLP avatar. Additionally, LLEntityAvatar does a

RegisterInterface<IEntityAvatar>(this);

to add the interface to the IEntity. Later, the Viewer will do a

TryGet<IEntityAvatar>(out anAV)

to see if the underlying entity is an avatar or not. If it is, it will call the avatar specific methods to view the avatar.

Over time, methods will be added to IEntityAvatar and LLEntityAvatar to try and hide the implementation details of an avatar and create an abstract interface for a boned mesh with animations. I figure that the specific positioning logic that is now in RendererOgreLL will move into LLEntityPhysical with a generalized interface for RendererOgreLL to call into the entity to compute the location and parent.

The goal would be to extend Viewer to handler IEntityPhysical (a regular object in the view), IEntityFoliage, IEntityAvatar and IEntityAttachment and all the protocol and item type specific logic will move into protocol specific implementation of classes with those interfaces.

More Ogre Dynamic Loading

I updated my page on dynamically loading meshes, materials and textures in Ogre with information for textures. Turns out that the requests for the textures works out but that, again, the containing mesh has to be reloaded to get the texture to pop up in the scene. The code for finding which meshes need reloading is included.

Dynamic Loading of Ogre Resources

In trying to get LookingGlass working with Ogre, I had to figure out how to dynamically load resources (meshes, materials and textures). Ogre’s default methodology is to have everything preloaded. Loading meshes and materials on demand is not obvious. Especially materials.

I’ve figured some of it out and wrote up Dynamic Loading of Ogre Resources. Hopefully this will save some other people many frustrating hours.