[Opensim-dev] Unreal viewer: summoning the coders

[Michel Beauregard]

extract from DIVA email paragraph 4:

.....and the horribly un-optimized content that people create.

Mainly asset quality  problem that translated in lag and loading failure in our scenes.

A while back I was talking to the creator of the viewer building tool in SL who also happen to be the keeper of SVARGA a SL showcase region done with prim only .  At the time the viewer was defacto the  input filter tool for SL content. 

Now a days with content creation external to viewer where would a content upload  filter tool best fit if not in the viewer. The cost of upload is a good indication of what burden is incurred in hosting said content and in SL that cost to some  extent  somehow regulate the content creation quality. SL also imposes upper limits on mesh object creation see next paragraph for details.  Could we use that data or other in our new viewer  to do some kind of control of asset upload quality in our opensim grids. 

See for detail http://blog.nalates.net/2015/10/01/second-lifes-limits/#more-15460 where they indicate that not only there is a upper limit on material of 8 and total of triangle count per object of 174,752 for you mesh in SL , which was already documented . But they mention there is also a limit per material of 175,752/8 = 21,969 triangles .  Testing at the time with 0821 none of these limits were applicable to opensim.

GiMiSa 

    Le vendredi 14 décembre 2018 19 h 08 min 38 s HNE, Diva Canto <diva at metaverseink.com> a écrit :  
 
 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.