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 <[email protected]> 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. _______________________________________________ Opensim-dev mailing list [email protected] http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
