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

Teravus Ovares teravus at gmail.com
Mon Oct 4 05:32:04 PDT 2010


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101004/9aa331df/attachment-0001.htm 


More information about the opensource-dev mailing list