It's #3.
Here's my point of view(er). We need a viewer that:
1) Uses secure networking and is able to go through firewalls, so a
completely different network stack.
2) Accepts programmable UIs from the server and therefore is capable of
conveying completely different applications.
3) Uses modern graphics, so a completely different rendering engine.
Would be nice that it would be capable of being compiled for different
platforms such as mobile and game stations.
4) Last but not least, is capable of rendering OpenSim/SL content. We
all like the build tools of SL, they are the easiest 3D authoring tools
out there, and therefore we want to continue to support prims and the
horribly un-optimized content that people create. The current viewers
can support building very well, we should continue to use them for that.
Rendering on the Web browser is not a priority. These days it's pretty
easy and common to install and run native applications by clicking
links. Ppl are starting to get used to it with apps like Zoom,
BlueJeans, etc.
We've been having internal discussions about how to go at it, what
rendering engine(s) to use, etc. Personally, I hate the thought of
committing to one single technology, so a lot of the hesitation [on my
part] has been to figure out how to develop a viewer that doesn't commit
strongly to Unreal, Unity, ... but that could perhaps be made to work
with several rendering engines. Like what we did for Physics on the
server side. It's not easy, and may not even be possible. So starting
with one but keeping it at arms-length distance may be the way to go.
On 12/14/2018 3:07 PM, Tommy Anderberg wrote:
On Mon, 10 Dec 2018 13:48:29 -0800, Diva wrote:
Some of us core devs have been talking for a while about developing a
viewer more or less from scratch. This code _may_ be a good start. If
there's anyone out here with the technical chops, the time, and the will
to contribute, let us know!
Is there a list of goals for a new viewer?
I ask because I've seen the need for one suggested many times, usually
with two arguments:
1) Current viewers make OpenSim look bad; "my kids laugh at me because
the graphics look like they're from a 15-year old game". (I think this
was said at OSCC, too.)
2) OpenSim needs a web-based viewer; people these days just don't want
to download and install software the old-fashioned way, they just want
to open a browser window and go.
There is also a less commonly seen argument:
3) OpenSim needs a viewer which can be tailored to provide experiences
beyond an SL clone. Viewer developers focusing on SL are unlikely to
spend time on such features, so it's up to OpenSim developers to do it.
Hence https://github.com/diva/OnLook
Argument #1
...looks iffy to me. A new viewer will not automatically make OpenSim
look better. If it is to be compatible with existing worlds (and if not,
who will use it?), it will be displaying the same old assets, and shader
lipstick can only do so much for porcine content. (I believe somebody at
OSCC mentioned dynamic shadows. I scratched my head. We've had those in
OS/SL viewers for almost a decade?)
Existing viewers actually do some things really well; I have yet to see
any client for the growing crop of new VR worlds do what Windlight can
do (Hypatia's comes closest). That would all have to be recreated before
a new viewer can be called an improvement.
Is the idea to introduce new asset types tailored to UE's capabilities?
Then we're moving from argument #1 to argument #3. Existing worlds won't
benefit much in the short term, but they will still have to be supported
if there is to be any uptake at all of the new viewer. Meanwhile, users
of existing viewers will complain that some assets look broken or even
make them crash.
Argument #2
...usually gets shot down with something like "browsers can't do the
job" (that too was heard at OSCC). If we are talking about HTML5 and
Three.js, it might well be true. But have a look at Epic's Zen Garden
demo from March 2017. Is it really obvious that WebAssembly and WebGL 2
can't do the job either?
So, if you really believe that lack of a web-based viewer is keeping
OpenSim back, UE's support for WebAssembly might be a good reason to
consider going down this route. But then one should weigh the effort of
building a whole new viewer against the effort required to get the core
parts of an existing one to compile with Emscripten.
As an aside, I am less convinced now than a few years ago that a web
viewer would really make that much of a difference. It's not like
Fortnite has suffered greatly from the need to download and run a 10 GB
installer before you can start having fun (for some people's definition
of "fun").
Argument #3
... is the one I find most credible. But whether UE provides the best
route to an OpenSim-specific viewer depends on what exactly one is
trying to achieve.
Is better graphics an important criterion, to the point that it warrants
the introduction of UE-specific asset types unsupported by existing
viewers?
Is VR support important? UE and Unity both make this very easy to add.
Is easy customization of the UI what really matters? An easily
customizable HTML5 UI around a WebAssembly-driven WebGL canvas could be
a worthy heir to OnLook, but this might be easier to achieve starting
from an existing viewer.
Maybe these questions have all been thrashed out already. If so, a link
to a document summarizing the answers would be welcome.
_______________________________________________
Opensim-dev mailing list
Opensim-dev@opensimulator.org
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
Opensim-dev@opensimulator.org
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
