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

Neil Canham neil at knowsense.co.uk
Mon Oct 4 05:51:09 PDT 2010


Just want to says thanks Teravus for a very insightful and informative
post.

Neil Canham

On Mon, Oct 4, 2010 at 1:32 PM, Teravus Ovares <teravus at gmail.com> 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/20101004/daa63068/attachment-0001.htm 


More information about the opensource-dev mailing list