<div dir="ltr"><div>I originally didn’t want to reply to this thread because this has been brought up before on numinous occasions and in each case it has gone off on some wild tangent of insane impossibility. <br><br>Its in my humble opinion that the first thing we need to do is have our own graphical viewer. To accomplish this with any sane timing we need to take the BSD licenced Radgast viewer with its new graphical mode and use this as a base in which to create an opensim only viewer.. This separates us from being dependent on LL and the limitations of the TPV's allowed shared experience rules. <br>
<br>There really isn’t anything wrong with using LL's current protocols as a base. They are tried and true and a known working protocol, but with that being said, they can be updated modified and renamed to our whim if we re not tied to the viewers use being compatible with SL. <br>
<br></div><div>Stop trying to reinvent the wheel and utilize or fix what you have at your disposal first.<br></div><div><br><br></div>Trinity Bays (aka Yoshiko Fazuku)<br><div><br><br></div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Tue, Aug 5, 2014 at 10:34 PM, 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">Diva: I've been thinking along the lines of your #4 suggestion. The base scene viewer should be architecturally like an X11 server -- just takes commands to draw things. For a 3D world, the necessary graphics functions would be more than frame buffers and overlapping windows but would enable layering of 3D content from many different sources. And then, since JavaScript workers can be loaded dynamically, rather than embedding an avatar renderer in the viewer, the avatar renderer would be fetched from that avatar asset server. That way, different implementations of avatars could stand side-by-side without having to worry about viewer versions.<div>
<br></div><div>All the other support services would be broken out -- chat, inventory, mapping. They wouldn't be part of the scene viewer but would be other JavaScript pages that could be in separate windows or displayed on a panel in the view (needed for the people wearing goggles).</div>
<div><br></div><div>Also, with this loose organization, everything doesn't have to run on the same computer.</div><div><br></div><div>As modular and extensible as possible.</div></div><div class="HOEnZb"><div class="h5">
<div class="gmail_extra"><br><br>
<div class="gmail_quote">On Tue, Aug 5, 2014 at 5:20 PM, Michael Emory Cerquoni <span dir="ltr"><<a href="mailto:nebadon2025@gmail.com" target="_blank">nebadon2025@gmail.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">I am not sure that WebGL is at a level where it could displace or replace the standard SL viewer even as a simple viewer only, some experimenting with WebGL that we have done shows that it is very very difficult to render a typical SL/OpenSimulator scene in the web browser, the performance is also not great even on the most top of the line hardware, personally I think using WebGL would be a big step down graphically and functionally, I like the idea of a easy to use no-nonsense don't have to install anything viewer, conceptually it sounds great, but not at the expense of a degraded experience which is what I suspect we would end up with if we went down the WebGL path today. I honestly do not have a good solution to this problem, especially if we are talking about Cross platform, its going to be some form of OpenGL and it will likely be difficult to get Call of Duty style graphics cross platform, though its not impossible, valve has shown it can be done, but its going to be a lot of work, Radegast is a good start to an alternative viewer however graphically it still can not compete with even the SL viewer in terms of render capability, however i suspect it does better than any other non LL viewer does at the moment, things like Windlight will be very difficult to replicate, even plain sky and clouds are very difficult to do well. I am not sure I have seen any opensource / cross platform engines or systems that compare to the latest DirectX style game graphics, most of the open source cross platform stuff you see, including WebGL seem to be stuck in the 2005'ish era graphics at best. I would love to see any examples anyone has that would prove me wrong there.<br>
</div><div class="gmail_extra"><div><div><br><br><div class="gmail_quote">On Tue, Aug 5, 2014 at 7:15 PM, Diva Canto <span dir="ltr"><<a href="mailto:diva@metaverseink.com" target="_blank">diva@metaverseink.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div><tt>Hi Mister Blue,</tt><tt><br>
</tt><tt><br>
</tt><tt>You ask a great question.</tt><tt><br>
</tt><tt>Here are some of the things I would like to see in a
future virtual world viewer:</tt><tt><br>
</tt><tt><br>
</tt><tt>#1 - Open source -- goes without saying</tt><tt><br>
</tt><tt><br>
#2 - Multi-platform -- it should run on the Web, standalone, and
tablets</tt><tt>. JavaScript maybe? Or something that compiles
to it.<br>
</tt><tt><br>
#3 - VR-enabled -- it should be ready to run on the Oculus and
other VR displays and inputs</tt><tt><br>
</tt><tt><br>
#4 - Modular with a small core -- the core viewer should be as
simple as possible, possibly just a non-interactive *viewer*
without avatars, and all features (such as avatars, chat, build,
etc) should be added as plugable, optional modules</tt><tt> with
corresponding server-side support. In fact, the viewer-side
modules should be downloaded from the server-side as people
visit the server </tt><tt><tt>(a la JavaScript on the Web) </tt>--
that's the maximum flexibility, as it allows for all kinds of
additional features and differentiation. Voice chat is an
important feature for many, but should also be optional. <br>
</tt><tt><br>
#5 - </tt><tt>Modern graphics -- I don't really know what this
entails, but it would be nice to have environments and avatars
like those in Call of Duty. This may be at odds with #2.<br>
<br>
I'm not sure if this requires a whole new server side or if we
can use OpenSim for a while. People have added WebSockets
support, and that's ripe for being improved.<br>
<br>
If you start this project, I hope I have time to help! I would
like that very much.<br>
<br>
<br>
</tt><div><div><tt><br>
</tt><tt>On 8/4/2014 6:08 PM, Mister Blue wrote:</tt><tt><br>
</tt></div></div></div>
<blockquote type="cite"><div><div>
<div dir="ltr"><tt>I've been seriously thinking about creating a
new viewer project. But with Maria's survey[1] and all the
different virtual world announcements happening and the lively
OpenSimulator vs Unity discussion on the opensim-user list,
I'd like to open up the discussion to the OpenSimulator
development community[2].</tt>
<div>
<tt><br>
</tt></div>
<div><tt>LL is making a new world and viewer (closed and
proprietary as far as I know). HighFidelity is making a new
world and viewer (open source with commercial 'grid
services'). Unity 5 will have a multi-platform web viewer
and a new multi-user backend (pricing not announced). There
are various wonderful open source virtual world projects
(realXtend, Virtual World Framework, ...) as well as many
emerging technologies (xml3d, html5, asm.js). There are
several forks of OpenSimulator (Aurora, ArribaSim, ...) that
have made many enhancements to the base system. Add to that
several successful virtual worlds build on OpenSimulator
(inWorldz, Anvination, Kitely, ...) as well as a few
packaged distributions of OpenSimulator (Diva, ...). Add to
that the many SL/OpenSim third party viewers based on the LL
viewer. And that's just in our sphere. There is much more
happening in the gaming and education and training
communities.</tt></div>
<div><tt><br>
</tt></div>
<div><tt>So, what could a new viewer add to the mix? Whatever a
new view does, it approaches the question of what
OpenSimulator should be three years from now.</tt></div>
<div><tt><br>
</tt></div>
<div><tt>For me, there are two basic choices[3]: evolutionary
change or revolutionary change.</tt></div>
<div><tt><br>
</tt></div>
<div><tt>Evolutionary change says to build on existing
OpenSimulator. Make due with the existing LLLP (Linden Lab
Legacy Protocol) and improve vehicles, make installation and
use easier and add an easier to use and improve viewer.</tt></div>
<div><tt><br>
</tt></div>
<div><tt>Revolutionary change would be striking off on a new
virtual world architecture. It could have LLLP support but
only for downward compatibility and to keep that community
and content. But other questions arise: How would one build
a viewer/virtual world where a HiFi avatar could stand next
to a SL avatar? How could content be delivered to a viewer
so it is displayable but is not in the original, copyable
form? How to leverage the distribution and power of 'the
cloud'[4]? How could one make hypergridable grids across the
many virtual worlds?</tt></div>
<div><tt><br>
</tt></div>
<div><tt>What do you think? Evolution or revolution?</tt></div>
<div><tt><br>
</tt></div>
<div><tt>-- mb</tt></div>
<div>
<div>
<div><tt><br>
</tt></div>
<div><tt>[1] </tt><tt><a href="http://www.hypergridbusiness.com/2014/08/survey-better-vehicles-search-most-wanted-in-opensim/" target="_blank">http://www.hypergridbusiness.com/2014/08/survey-better-vehicles-search-most-wanted-in-opensim/</a></tt></div>
</div>
<div><tt>[2] I see this expanding to other forums eventually.</tt></div>
</div>
<div><tt>[3] With a lot of gray area in between</tt></div>
<div><tt>[4] I'm always amazed by Google Maps -- it displays the
map with traffic overlays and I can zoom in and out with
almost immediate response. Why can't a virtual world viewer
do that?</tt></div>
</div>
<tt><br>
</tt>
<fieldset></fieldset>
<tt><br>
</tt>
</div></div><div><pre>_______________________________________________
Opensim-dev mailing list
<a href="mailto:Opensim-dev@opensimulator.org" target="_blank">Opensim-dev@opensimulator.org</a>
<a href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev" target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a>
</pre>
</div></blockquote>
<tt><br>
</tt>
</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><br clear="all"><br></div></div><span><font color="#888888">-- <br>Michael Emory Cerquoni
</font></span></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></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>