Teravus++ On Mon, Oct 4, 2010 at 2:32 PM, Teravus Ovares <tera...@gmail.com> wrote:
> 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 -- Jeroen Frans Virtual World Technology Specialist @ http://VesuviusGroup.com Second Life: Frans Charming blog about SL @ http://secondslog.blogspot.com
_______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
