Archived Posts from this Category
Archived Posts from this Category
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).
The new O3D is early in its development but it is coming. 3D on the web is just around the corner.
The updates for LookingGlass have been happening over at the official web site.
Camera and avatar movement is MUCH smoother because of finding bugs and adding position and rotation animation code. That also means that movement of animated objects is now smooth. LG works great in OSGrid/Lbsa Plaza but larger sims like OSGrid/Wright Plaza stretch the bounds of memory. SkyX now works with OpenGL although the shaders aren’t all together for the sun and moon lighting. Avatars are still stuck in T-pose and attachments are at the feet. Sitting avatars now are near the sit location and not at the sim’s 0,0. Also upgraded to the latest libomv. A new Windows 32-bit installation package is in the download section.
I broke a lot of stuff getting to a better place. The loading and reloading experience was poor (slow and jerky) so I moved a bunch of the update code from C# to C++. That has necessitated (after a while finding that this was the problem) building and including [http://boost.org Boost] for data structure access locking. I also wanted to have the Radegast window navigatable via the keyboard. This meant reorganizing the input code to extract common routines. Adding avatars meant rethinking and redoing the organization of Entities to allow for extensions for attachements, etc. Avatars are not first class items but merely a specialization of an entity which the viewer has to figure out how to display. The short of all this is I ripped a lot of things apart and they are not all together yet. Hopefully only another week. Fingers crossed.
To make for open discussions and transparency in my design directions, I will be added design comments to my blog here as well as in the LookingGlass forum on the Forge. Join in the discussions on the forge.
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
to add the interface to the IEntity. Later, the Viewer will do a
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.
I am about to make a video of logging into Wright Plaza and flying around but I wanted to get shadows working first. I introduced an oddity whereby the brightness of a prim is tied to it’s x or y rotation. I just can’t find the problem but, since it makes most buildings have large black sections, I have to find the bug before I show LG off. Other than that, LG allows logging into and navigating most sims.
I’ve wanted to advance a version but the main thing keeping LookingGlass from being usable was the unbelievable memory footprint. Ogre vertices took up all the memory until it crashed. So, I’ve spent the last two weeks adding a dynamic loading and unloading system. Now I can log into Wright Plaza and walk an fly around. Woot!! I’ll add a video and some updates this weekend.
I’ve completed sculpties and added many texture processing improvements. Normal LLLP textures are JPEG2000 but I had to figure out how to store sculptie textures as PNGs so I could read them into the .NET/Mono graphics functions. Once I was more familiar with textures, I put in checks for transparency and put in the code to pass that info down into the renderer. There are some problems around PrimMesher but I don’t know if it’s a bug or me using it wrong. You’ll see the problems with box prims having the wrong textures on the bottom (most notable if someone rotated the box to use the hollow for a hole) and that textures are placed on scuplties upside down.
But it’s getting more stable and can pretty much do a sim. Walking around is not very easy but that will take prioritization of the work queues.
I reduced the detail of Meshermizer from High to Low. The effect is not visible (at least so far) but the number of vertices generated per mesh is much less. After setting ‘MultipleSims’ to one, I was able to login and render the whole of OSGrid/Wright Plaza. Woot!!
Performance is no where near good enough yet. The callback for materials is taking forever since there are > 30k materials in Wright Plaza. Ogre also freezes up now and then. I added/completed statistics gathering and RESTing to try and find it. At the moment, it looks like Ogre hangs up doing the JPEG2000 decompression for the mipmaps. Might have to convert the textures on reception.
I spent a few days trying to get Ogre scaling of prim working. Decided to bag it for the moment. I thought that letting Ogre scale the prims would make most of the prims just unit boxes and these I could share vertices of thus reducing the memory problem. Well, it seems that entity scaling affects the coordinates of the entity also so linked sets (prims relative to their parent) would be messed up. Even after fixing that I discovered that the scaling messed up the texture mapping (which I am using Ogre for also) so I would have to scale the texture depending on the scaling of the face the texture was on. Ick.
Anyway, backed out the scaling code, found some bugs (one in the work queue that would ironically make more work) and the arrow keys now move t he agent avatar although the camera doesn’t move yet.
This weekend’s time spent programming (as opposed to pulling weeds and cleaning the garage) was changing the scaling of prims to use the Ogre scaling factors rather than having Meshmerizer scale the vertices information. This will allow me to share vertices information within cube prims.
Ogre doesn’t allow one to share vertices between prims (well, not really true and I will look into creating my own vertices class but that’s a ways down the road) but it does have a feature to share the same vertices between all of the sub-meshes within a mesh. That means I can share the vertices between all the sides of the ubiquitous cube. This should divide the memory requirements by nearly 6. Fingers crossed.
I’ve been tweaking the LookingGlass web site at http://lookingglassviewer.org/. Just another thing to add to the project — learning MediaWiki. But the seem is new so it doesn’t look like the default MediaWiki page. More formatting is needed but that will come with time.
I will be updating my progress programming here and on that site. Manual cut-and-paste at the moment. That is another thing for automation.
I am working on an OpenSim/SecondLife compatable viewer. I almost have it to a state that I am going to let the BSD Licensed code loose. I want to get it to the point of being buildable and runnable and not totally sucky before I put the code out. That’s not to say it will be anywhere usable or feature complete at that point.
The biggest problem at the moment is performance. I have clearly made some of the noob mistakes when creating a visual application. It disparately needs a manager and scheduler for all of the work queues. The current implementation gets totally overwhelmed when entering a large sim (especially an OpenSim sim since the whole sim contents is thrown at the viewer).
Here are some progress pictures. These are of the Portland Connection sim in SecondLife(r).
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.
My latest keep-me-busy project has been building a new viewer for OpenSim. The LookingGlass viewer is a virtual world viewer with an internal structure that makes extensions and mixing and matching easy.
This all started as a project to learn C#. Work was dropping me into a project using that language so I had to learn and what better way to learn than to build something so grand and unattainable that I would have to learn something. Thus LookingGlass was born.
The sources are not quite ready for releasing. The BSD licensed sources will be out in a few weeks. I just can’t bring myself to put it out without the basic features going. I was put back about a month by switching from Mogre to Ogre which required me to learn the managed to unmanaged interface between C# to C++.
I will post a feature list and progress reports and some of my frustrations as time goes on. Eventually there will be a release date and wiki’s and source control and bug reports but that will come in it’s own time. For the moment, I will get back to the background loading of textures.