<div dir="ltr">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.</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 7, 2014 at 10:38 AM, Mister Blue <span dir="ltr"><<a href="mailto:misterblue@misterblue.com" target="_blank">misterblue@misterblue.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Good stuff.<div><br></div><div>@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.</div>
<div><br></div><div>@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. </div>
<div><br></div><div>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.</div>
<div><br></div><div><span style="font-family:arial,sans-serif;font-size:13.333333969116211px">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, ...).</span><br>
</div><div><span style="font-family:arial,sans-serif;font-size:13.333333969116211px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13.333333969116211px">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?</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13.333333969116211px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13.333333969116211px">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.</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13.333333969116211px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13.333333969116211px">A first step would be a simple viewer that shows promise and connects to existing grids. A baby step.</span></div>
<div><br></div><div class="gmail_extra">-- mb<br><br><div class="gmail_quote">On Thu, Aug 7, 2014 at 6:49 AM, Frank Nichols <span dir="ltr"><<a href="mailto:j.frank.nichols@gmail.com" target="_blank">j.frank.nichols@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>"<span style="font-family:arial,sans-serif;font-size:13px">make it in a way it can better support functionality for handicapt people."</span><div>
<span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div></div><div><span style="font-family:arial,sans-serif;font-size:13px">Absolutely - this will go a long way towards gaining acceptance! </span></div></div><div><div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Thu, Aug 7, 2014 at 7:16 AM, R.Gunther <span dir="ltr"><<a href="mailto:rigun@rigutech.nl" target="_blank">rigun@rigutech.nl</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Afree with this, i think its just a bit to early for a viewer.<br>
Its better if possible to adjust opensim to make it High Fidelity compatible.<br>
And als use there viewer, or write one thats based on high fidelity code.<br>
If you now write a viewer for opensim you possible have to many bandages needed later to adjust it for High Fidelity.<br>
High Fidelity can give a few parts that openmsim is now missing.<div><br>
<br>
On 2014-08-07 09:05, Ilan Tochner wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
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.<br>
<br>
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.<br>
<br>
Cheers,<br>
<br>
Ilan Tochner<br>
Co-Founder and CEO<br>
Kitely Ltd.<br>
<br>
</blockquote>
<br></div><div><div>
______________________________<u></u>_________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@opensimulator.org" target="_blank">Opensim-dev@opensimulator.org</a><br>
<a href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev" target="_blank">http://opensimulator.org/cgi-<u></u>bin/mailman/listinfo/opensim-<u></u>dev</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@opensimulator.org" target="_blank">Opensim-dev@opensimulator.org</a><br>
<a href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev" target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
<br></blockquote></div><br></div></div>
<br>_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a><br>
<a href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev" target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
<br></blockquote></div><br></div>