Mister Blue, I would very much prefer a "new" renderer for avatars - if using the existing one means we are stuck with the SL avatar mesh/model. Something much more modular and modern that would work with more "standard". In fact, the renderer, I think, should be modular and pluggable and designed so when you visit a foreign grid/region/sim you automatically get a copy of the renderer required to display that grid if you don't already have it.
On Thu, Aug 7, 2014 at 10:38 AM, Mister Blue <[email protected]> wrote: > Good stuff. > > @Gunther: I have toyed with building an OpenSim module that adds an > OpenSim region to the HiFi hierarchical object tree. Then I spent a week > trying to build the HiFi viewer to conclude that they are creating a new > integrated viewer in the same sort of form as the SL viewer. While I like a > lot of their grid and object system, I'm not happy with the viewer. > > @Tochner: RealXtend contains a lot of good work and it is now wrapped into > the Fi-Ware European project which will provide it funding and momentum. > Like OpenSim, there are companies using RealXtend and, for smaller worlds, > it works pretty well. > > You are right that starting from scratch would be a long road. But, since > we are in the open-source world and many necessary parts are available to > build on. > > I've been thinking along the lines of building a browser based renderer > using asm.js for performance and borrowing rendering logic from HiFi (they > seem to have people who know about rendering arch) and three.js (which has > an efficient, generalized renderer) and Radegast. RealXtend has developed a > flexible WebSockets transport system (protocol versioning and > multi-channels, ...). Add to that a 'space management' system like > Sirikata's or the hierarchical tree of HiFi but with a generalization for > girds and different authentication systems. I like Macaroons for bearer > certificates or passing around permissions. Avatar renderers would come > from HiFi and Radegast although I wonder if avatar rendering could be cut > out of the LL viewer as a separate LGPL'ed library. The interface to the > backend would be cloud-ish -- all REST interfaces that can use all the > scaling tech of modern web applications (notifications, CDNs, managed APIs, > versioning, ...). > > An eventual research project would be the storage and manipulation of > objects in spaces. I wonder if only 'digested' objects can be sent to > viewers? 'Digested' in the sense that they have been combined, formatted, > enhanced for viewing (added light maps or occlusion maps) or merged to > build views of that city in the distance. If intermediate processors > (between the client and the object stores) can make 'views' for the client, > what would they do? What is the 'map/reduce' operation for 3d world > objects? Now could procedural rendering fit into this? > > Anyway, that's a long way of saying that starting from scratch would be > hard. Not only in the amount of work but also in building both new > developer and user communities. As @Justin pointed out, I am being very > optimistic on the amount of work involved. > > A first step would be a simple viewer that shows promise and connects to > existing grids. A baby step. > > -- mb > > On Thu, Aug 7, 2014 at 6:49 AM, Frank Nichols <[email protected]> > wrote: > >> "make it in a way it can better support functionality for handicapt >> people." >> >> Absolutely - this will go a long way towards gaining acceptance! >> >> >> On Thu, Aug 7, 2014 at 7:16 AM, R.Gunther <[email protected]> wrote: >> >>> Afree with this, i think its just a bit to early for a viewer. >>> Its better if possible to adjust opensim to make it High Fidelity >>> compatible. >>> And als use there viewer, or write one thats based on high fidelity code. >>> If you now write a viewer for opensim you possible have to many bandages >>> needed later to adjust it for High Fidelity. >>> High Fidelity can give a few parts that openmsim is now missing. >>> >>> >>> On 2014-08-07 09:05, Ilan Tochner wrote: >>> >>>> I highly recommend that we avoid trying to start a viewer project from >>>> scratch. Doing so without a dedicated group working full time for an >>>> extended period of time will result in the viewer project's failure and the >>>> growing irrelevance of the OpenSim project that will pend the availability >>>> of this modern viewer. >>>> >>>> I suggest we either adopt and extend the realXtend project for our >>>> needs (with or without its server architecture) or invest our collective >>>> R&D resources towards pushing High Fidelity in the direction we want it to >>>> evolve to. These liberally-licensed open source projects have already had >>>> many developer-years worth of effort invested in them and are actively >>>> developed by more people than are currently contributing to the OpenSim >>>> codebase. It would be very unwise IMO to spend years reimplementing the >>>> type of viewer they already have working. >>>> >>>> Cheers, >>>> >>>> Ilan Tochner >>>> Co-Founder and CEO >>>> Kitely Ltd. >>>> >>>> >>> _______________________________________________ >>> Opensim-dev mailing list >>> [email protected] >>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >>> >> >> >> _______________________________________________ >> Opensim-dev mailing list >> [email protected] >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev >> >> > > _______________________________________________ > Opensim-dev mailing list > [email protected] > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev > >
_______________________________________________ Opensim-dev mailing list [email protected] http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
