[opensource-dev] Unity 3D as possible base for future (maybe even official) SL Viewers
Glen Canaday
gcanaday at gmail.com
Mon Oct 4 09:37:35 PDT 2010
I agree with Neil -> very nice post.
But I do think that this really hasn't been tested well enough to
declare that all scene-graphers and 3rd-party renderers won't perform
well on SL data, though. For me, that's up in the air and is something
that should be tested before it's tossed out. That would go for Unity,
Irrlicht, Ogre, OSG, and others. Some will likely suck, some possibly
won't, but we'll never know until they're tried.
I wont say "zOmg don't use Unity because it doesn't support Linux!" but
I will say that anything that might work, and would be workable as an
alpha-test-tangent-etc for a possible *official* 3.0, can't be something
that doesn't support all 3 major platforms natively. That was my
original beef with the idea of trying Unity out - can't suggest it as a
candidate for official use. Anything that doesn't support them all
should be relegated to TPV.
--GC
On Mon, 2010-10-04 at 08:32 -0400, 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
More information about the opensource-dev
mailing list