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 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 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.