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.

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.

To get proper sun and moon lighting, I spent a day adding Caelum. This is an Ogre plugin for sun and moon and precipitation and everything atmospheric. I didn’t quite get it working and as I was looking for solutions I found that the person who created Hydrax (water and oceans) is now building a sky system. I think I might wait to see how that comes out. This means that, for the moment, Caelum build information is in the source tree but the ifdef in LookingGlassOgre is commented out to disable any use of that library.