Insightful post by Teravus Ovares on Unity 3D vs. SL Viewer and other renderers

Yesterday, on an ongoing discussion at the opensource-dev mailing list, Teravus Ovares posted a great piece of information on rendering challenges and differences between Second Life viewer's renderers, Unity 3D, Ogre, and Irrlicht. It's quite worth a read:

Teravus Ovares
Mon Oct 4 05:32:04 PDT 2010

When working on IdealistViewer, I noticed that, generally, third party 'general purpose' renderers like Irrlicht and Ogre are not well suited for rendering objects at the quantity that SecondLife prims require. Rendering prims /can/ be done with them, however, not at the level that can be done with the SecondLife viewer.

With Irrlicht, for example, the memory load of a typical 5000 prim scene runs up against the 2GB memory limit.

With SecondLife prims, it's more about segmenting the render data so that only the unique things are kept and everything else is a reference to something that was calculated before. Out of the box, Irrlicht requires per-instance knowledge about texture, mesh buffer, face and lighting settings configurations. This and reference/const/value type semantics used in the engine causes far more data duplications then are necessary.

Prims are strange for rendering. The prim's mesh result is complex in terms of vertex count however, in a given 5000 prim scene there's on average 130 'unique' prim mesh. Those 130 unique mesh are duplicated with various textures, colors, orientations and associated data to make for the entire prim count in the region. In theory, you can manage memory reasonably well by using a 'mesh factory' pattern where by the mesh factory keeps track of instance counts and generates a new mesh when required. In practice, however, the associated data makes this very difficult. In Irrlicht, the API is such that the texture configuration data is 'stuck in with' the mesh data object. So, to get the variability that the secondlife prim scene requires, you're also duplicating the mesh and making small changes to the object's visual configuration data.

Irrlicht, like Ogre, is better optimized for a smaller number of more complex mesh objects then a very large number of highly 'instancable' objects with very small differences. I'd comment on the opposite of the last statement... but I don't really know about how the SecondLife viewer works under the hood to do so (OpenSimulator Developer).

I don't think that this issue is going to 'go away'. In fact, introducing mesh in the viewer is going to make that memory, speed, and instancing balance even more difficult to maintain. The gap between the viewer and 3rd party 'general purpose' rendering tools will narrow in both directions.. the viewer will get better at managing arbitrary mesh and 3rd party 'general purpose' rendering tools will be able to render secondlife scenes better because there will be less 'prim' to render as a result of there being arbitrary mesh.

In either case, the future is full of interesting technical challenges. I think in unity, like with Irrlicht, smaller, more specialized scenes will work OK with regards to prim rendering. And, I don't think 3rd party renderers are going to be able to come close to the capability of the SecondLife viewer when dealing with prim. They're just not designed for the same type of data. The object models and API just are not really appropriate for prim. I'm not saying that it isn't worth pursuing a render plugin architecture. I am saying, however, that given that 3rd party 'general purpose' renderers are never going to be able to meet the SecondLife viewer's capability in rendering prim, it probably shouldn't be very high on the priority of things to do.

Regards

Teravus