On Jun 6, 2012, at 7:03 AM, Lord wrote: > to make the hybrid viewer ? Another thing I have been thinking about was > that it seemed that Ogre would be incompatible with OpenSim and wondering why > it wasn't a module instead of part of the core, so that it could be more > easily switched in or out as needed and to keep everything as small and fast > as possible ?
Ogre isn't really incompatible with OpenSim -- Naali (~old version of Tundra) itself demonstrates that, for example this screenshot from osgrid shows a primboard in Naali 0.1, https://www.dropbox.com/gallery/1002746/1/naali?h=d9f90e#gallery:12 It is just that it doesn't do batching automagically, so for efficient rendering of large prim builds (say a house with staircases etc resulting in 2000 prims) the prim support with Ogre would need to be implemented so that nearby prims using the same materials are combined to single objects etc. Lasse (the dev from Ludocraft who wrote Naali's (and hence Tundra's) rendering module made a plan for that back then, was iirc 1-3 man months work. The same technique would work also for user created content made with meshes, is not specific to prims only. I guess an alternative would be to implement prim rendering with some kind of special prim rendering code. And the rendering with Ogre is in a module, just that for simplicity the Ogre types are used also in scene core currently. That may change depending on how well Ogre suits all the needs in the future, for example how it runs on current mobile devices etc. Ogre itself is quite small and very modular (the main dll is some 300kb iirc? then scene managers, directx/opengl etc renderers and for example particles are optional plugins) so it is often not a problem. ~Toni > On Monday, April 30, 2012 9:58:50 AM UTC-4, ATupper wrote: > To me it would seem that the optimal solution would be a project > loosely coupled with both of the development teams for ReX and > Opensim. This breed of Tundra-based Opensim viewer does show a > substantial amount of promise, but it would really need a dedicated > team to dig in and suss out all of the inevitable roadblocks without > diverting resources away from either of the core teams. This might be > the place for a for-profit venture to step in to take up the flag of > doing the heavy grunt work to get a implementation cranked out and > released into the wild. Such a venture would have to develop the > viewer with its' release as open-source as a given and build a > business model around leveraging services around it. > > While we're tossing around blue-sky concepts for a hybrid, I'd like to > point out a big advantage of not hard-coding the viewer UI is the > ability to experiment with radically different layouts (Ilan touched > on this tangentially). One of my longest running soapbox rants is > that for new adopters of Opensim/SL, the viewer is too complicated and > loaded with functionality that they don't want or need. It's much > like giving an industrial-grade smelter to someone who just wants an > EZ-Bake oven. There are of course plenty of people who do want and > need the advanced functionality, but those people are very rarely the > ones who are trying out the platform for the first time. By not > hardcoding the UI, there's a lot more freedom to experiment with a > simplified experience that will help draw in new users. Theoretically, > if we can make it easier for new users to have positive experiences > with both Opensim and ReX, it will lead to a positive feedback loop. > > -- > http://groups.google.com/group/realxtend > http://www.realxtend.org -- http://groups.google.com/group/realxtend http://www.realxtend.org
