[opensource-dev] Unity 3D as possible base for future (maybe even official) SL Viewers

[Kent Quirk (Q Linden)]

Agreed (a day late). Teravus' post is great -- very insightful, and it mimics our own thinking.

The complexity of what we render, and the fact that it's not professionally created content, means that we get all sorts of edge cases that aren't a problem in traditional graphics engines. Many systems, including Unity, put constraints on the content they'll render to achieve speed or certain effects.

We don't have the same sorts of limitations, and so our engine needs to be special. I know we've had people who've evaluated Unity as well as other engines, including Ogre, and it's by no means a simple problem to figure out how to get our content into those systems without choking them. It may be possible, and one of the things I'd like to do is abstract our renderer better so that we  have the ability to try a few experiments without re-implementing all of the viewer. 

Anyway, I guess that graphics systems are kind of like Tolstoy's unhappy families: each one sucks in its own way. It so happens that ours is designed for our content (surprise!), and our content is weird, so other engines may not be as obviously well suited to displaying it as you might think.

      Q

On Oct 4, 2010, at 8:32 AM, Teravus Ovares wrote:

> When working on IdealistViewer, I noticed that, generally, third party 'general purpose' renderers like Irrlicht and Ogre are not well suited for rendering objects at the quantity that SecondLife prims require.   Rendering prims /can/ be done with them, however, not at the level that can be done with the SecondLife viewer. 
> 
> With Irrlicht, for example, the memory load of a typical 5000 prim scene runs up against the 2GB memory limit.   
> 
> With SecondLife prims, it's more about segmenting the render data so that only the unique things are kept and everything else is a reference to something that was calculated before.   Out of the box, Irrlicht requires per-instance knowledge about texture, mesh buffer, face and lighting settings configurations.   This and reference/const/value type semantics used in the engine causes far more data duplications then are necessary.
> 
> Prims are strange for rendering.  The prim's mesh result is complex in terms of vertex count however, in a given 5000 prim scene there's on average 130 'unique' prim mesh.   Those 130 unique mesh are duplicated with various textures, colors, orientations and associated data to make for the entire prim count in the region.   In theory, you can manage memory reasonably well by using a 'mesh factory' pattern where by the mesh factory keeps track of instance counts and generates a new mesh when required.   In practice, however, the associated data makes this very difficult.   In Irrlicht, the API is such that the texture configuration data is 'stuck in with' the mesh data object.    So, to get the variability that the secondlife prim scene requires, you're also duplicating the mesh and making small changes to the object's visual configuration data.   
> 
> Irrlicht, like Ogre, is better optimized for a smaller number of more complex mesh objects then a very large number of highly 'instancable' objects with very small differences.   I'd comment on the opposite of the last statement...   but I don't really know about how the SecondLife viewer works under the hood to do so (OpenSimulator Developer).
> 
> I don't think that this issue is going to 'go away'.   In fact, introducing mesh in the viewer is going to make that memory, speed, and instancing balance even more difficult to maintain.    The gap between the viewer and 3rd party 'general purpose' rendering tools will narrow in both directions.. the viewer will get better at managing arbitrary mesh and 3rd party 'general purpose' rendering tools will be able to render secondlife scenes better because there will be less 'prim' to render as a result of there being arbitrary mesh.
> 
> In either case, the future is full of interesting technical challenges.    I think in unity, like with Irrlicht, smaller, more specialized scenes will work OK with regards to prim rendering.  And, I don't think 3rd party renderers are going to be able to come close to the capability of the SecondLife viewer when dealing with prim.  They're just not designed for the same type of data.  The object models and API just are not really appropriate for prim.   I'm not saying that it isn't worth pursuing a render plugin architecture.  I am saying, however, that given that 3rd party 'general purpose' renderers are never going to be able to meet the SecondLife viewer's capability in rendering prim, it probably shouldn't be very high on the priority of things to do.
> 
> Regards
> 
> Teravus
> 
> 
> On Mon, Oct 4, 2010 at 12:36 AM, Brandon Husbands <xotmid at gmail.com> wrote:
> Ive used it, and fount it blehh.  I think we are failing to communicate about our conception of what is possible and what is used.
> 
> Are you saying that the normal user would have full access to what you use to develop the "client"?
> As its a middle ware really i fail to see how your going to implement that.
> I could be wrong. There are so many propitiatory things that you'd have to code in and handle rendering for with sl. Also remember you can not change the server backend. I just do not see it possible or powerful enough to handle what sl uses and does. I guess its the same concept between higher level langs and lower level ones. I could be wrong about this and just be old school in my thoughts.
> 
> If your so sure that it can do what needs to be done why have you not already done a prototype.
> From what your saying should be easy to get connected and render the scene. 
> 
> I would love to be wrong in that regard but then again i just don't see how your going to handle such things in a closed source engine.
> 
> 
> 
> 
> On Sun, Oct 3, 2010 at 9:36 PM, <mysticaldemina at xrgrid.com> wrote:
> Obviously these are subjective statements but I think your statements are based on an incomplete understanding of the tool and probably limited experience using it.  
> 
>  
> Not sure how you can say it is clunky.  I have a scene hierarchy where I can list and see every object in my seen. It’s like seeing every prim in my region.  I can select any object and view it in the inspector.
> 
>  
> Scripts are assigned to objects and not copied and duplicated into each prim.  I can edit a script once and every object that uses it gets that update.
> 
>  
> In the inspector I can see every public value of the script and change its value without having to actually edit the script.
> 
>  
> I can use assets directly from my disk without having to upload them when creating.  That is much faster than waiting for SL to do things.
> 
>  
> Scripts can access to every bone in the skeleton system and I can override animations to adjust the bones to a given scene’s needs, for instance if two avatars are a different height and I can adjust the bones to make their hands connect so they can really walk hand in hand.
> 
>  
> I can create keyed animations in Unity or use animations from other programs.  Animates can throw events which can trigger code to do things.  From scripts you can create and edit the animations and their key data.  You can layer animations, set their weights.  You can sync the length of layers.  Cross fade animations.
> 
>  
> You have materials like you do in Maya.
> 
>  
> I can create custom shaders.
> 
>  
> You can have spot lights, point lights and directional lights.
> 
>  
> You can create your own skyboxes.
> 
>  
> You can use water any where, not limited to just one plane with the water shader.
> 
>  
> I can use meshes.  Any object in the scene can have a skeleton.
> 
>  
> I can edit meshes and vertices in real-time allowing me to create parameterized content in real-time.
> 
>  
> I can load assets from a URL or through websockets.
> 
>  
> I can load textures from a URL or through websockets.
> 
>  
> There is a profiler that lets me see in great detail what the engine is doing.
> 
>  
> I can use Visual Studio to develop my scripts with all the features of Visual Studio.
> 
>  
> I can run a debugger and debug the scripts and libraries I am using in the scene.
> 
>  
> I can do baked lighting including ambient occlusion inside the tool
> 
>  
> I can do occlusion culling so I can have very large scenes.
> 
>  
> I can control what assets are loading and stream the rest in the background.
> 
>  
> I can use libraries of code.
> 
>  
> From one code base I can be published to many platforms including web and mobile phone.  Linux is the big one they are missing a native support for.
> 
>  
> Should I go on?
> 
>  
>  
> This is a group that is focused on Second Life client so not trying to convince anyone to switch.  But I do think it is fair that people give accurate information based on real experience and not guessing.  I think if you understood the tool more you will see your statements are based on inaccurate understanding of the tool.
> 
>  
> I personally do believe that the game development platforms will outpace anyone doing proprietary client development and as such the days are quickly approaching where you won’t be able to justify the cost of developing your own client rendering engines when you can get the features off the shelf for $1200 that would cost you way more to do yourself.  I also believe you won’t stay up and will find yourself quickly falling behind.
> 
>  
> M.
> 
>  
>  
>  
>  
> From: Brandon Husbands [mailto:xotmid at gmail.com] 
> Sent: Sunday, October 03, 2010 9:57 PM
> To: mysticaldemina at xrgrid.com
> Cc: Robert Exile In Paradise Murphey; opensource-dev at lists.secondlife.com
> 
> 
> Subject: Re: [opensource-dev] Unity 3D as possible base for future (maybe even official) SL Viewers
> 
>  
> Actually its not inaccurate. The tools themselves are clunky.. And i am not taking this as a lsl vs their language. I am talking about the engine itself.  From a lower level perspective.  Unity is really more of a middleware when it comes to graphics engines. sure you can use any network you want but in a whole as what it offers as a base is not what would be able to be used for something on the scale of sl. 
> 
> Also as a user you would not have those midddle ware tools that you see unless you want the whole thing to be clunky.
> 
> Its rigging and control system is designed for rapid prototyping and higher level designig.
> 
> I would put unity as an equivilant to making a mod for a fps with "good" tools unlike most mod systems. 
> 
> But as a complete engine from a graphics and other standpoints The hero engine blows that away. Actually there are quite a few game engines that surpass unity. And if we take thoes its like compairing writing with QT vs flash. (not quick time... but QT).
> 
> Flash is great as a packaged thing but its limited. Now unity can me modified and such to some extent but no where whats needed for a SL type of thing. 
> 
> And for the record I am not a fan boi of any engine or system. But i have developed a mmo from the ground up in 2001 to playable alpha 2 on the cusp of beta before the project was shelved due to funding.
> Having written a majority of the Engine and most of the server code. I would thing these are subjects i am quite capable of assessing.
> 
> 
> 
> On Sun, Oct 3, 2010 at 7:41 PM, <mysticaldemina at xrgrid.com> wrote:
> 
> Alright, this is the most incorrect post I have ever seen so I would guess you have used Unity for maybe a total of an one hour.
> 
>  
> First of all you can use any network technology you like.  It does come with a very basic P2P network, but you can use many game server that you like included some that support fail over and fault tolerance configurations.  In fact there are those using SL’s server and rendering prims and sculpties in Unity.
> 
>  
> The scripting language can also use C# and supports a way more complete set of functions then is available in SL.  This list is so long I don’t know where to start on functionality it supports that LSL doesn’t support.
> 
>  
> Not sure your point about FPS, it has Ambers Occlusion culling, beast lighting and deferred lighting which lets it create FPS you can’t do in SL for the same amount of content.
> 
>  
> So if you are going to comment on Unity please do your homework and don’t mislead people.
> 
>  
> M.
> 
>  
>  
>  
> From: opensource-dev-bounces at lists.secondlife.com [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of Brandon Husbands
> Sent: Sunday, October 03, 2010 8:20 PM
> To: Robert Exile In Paradise Murphey
> Cc: opensource-dev at lists.secondlife.com
> Subject: Re: [opensource-dev] Unity 3D as possible base for future (maybe even official) SL Viewers
> 
>  
> Unity is the biggest POS i have ever used.... 
> Not well designed. IMHO. Its like trying to do SL in javascript.
> Not literally but you know what i mean. 
> 
> It was never designed for a heavy network transport now multi player / mmo style.
> 
> A FPS maybe but nothing on a grand scale.
> 
> On Sun, Oct 3, 2010 at 7:04 PM, Robert "Exile In Paradise" Murphey <exile at weylan-yutani.com> wrote:
> 
> On Sun, 2010-10-03 at 18:15 -0400, Glen Canaday wrote:
> > That's why I suggested Ogre instead. I personally think it would be a
> > better fit and more productive to look at. Others may have different
> > opinions.
> 
> Well, I run Linux and agree that being shut out after
> years of being supported would be suboptimal for me.
> 
> Running in a VM is an exercise that only a masochist can love
> compared to an application natively supported.
> 
> Plus, a VM position forces people to purchase additional OSes
> just to support one (or a handful) of apps, which add massive
> overheard in additional administration. At-home-VM is a
> temporary workaround, not a "platform strategy".
> Remember - SL is supposed to be Fast, Easy, Fun... not an
> enterprise-level support nightmare just to boot and run in
> the first place.
> 
> Unity3D seems like a lot of "lose" to me: for the same amount
> of effort to switch to that, re-base on something else that keeps
> the same supported set of platforms or extends it without dropping
> already supported platforms.
> 
> OGRE may be a great suggestion, especially in light of the RealXtend
> folks having already broken a LOT of the ground of an "SL client
> that uses OGRE rendering." Why re-reinvent their wheel?
> Maybe talk to them about Naali and see what goes from there?
> 
> --
> Robert "Exile In Paradise" Murphey
> Promise her anything, but give her Exxon unleaded.
> 
> 
> 
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges
> 
> 
> 
> 
> -- 
> -------------------------------------------------------------------------------------------------------------------------------
> This email is a private and confidential communication. Any use of email may be subject to the laws and regulations of the United States. You may not Repost, Distribute nor reproduce any content of this message.
> -------------------------------------------------------------------------------------------------------------------------------
> -------------------------------------------------------------------------------------------------------------------------------
> 
> 
> 
> 
> -- 
> -------------------------------------------------------------------------------------------------------------------------------
> This email is a private and confidential communication. Any use of email may be subject to the laws and regulations of the United States. You may not Repost, Distribute nor reproduce any content of this message.
> -------------------------------------------------------------------------------------------------------------------------------
> -------------------------------------------------------------------------------------------------------------------------------
> 
> 
> 
> 
> -- 
> -------------------------------------------------------------------------------------------------------------------------------
> This email is a private and confidential communication. Any use of email may be subject to the laws and regulations of the United States. You may not Repost, Distribute nor reproduce any content of this message.
> -------------------------------------------------------------------------------------------------------------------------------
> -------------------------------------------------------------------------------------------------------------------------------
> 
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges
> 
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101005/76c4ea5a/attachment-0001.htm