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 <tera...@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 <xot...@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, <mysticaldem...@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:xot...@gmail.com] >>> *Sent:* Sunday, October 03, 2010 9:57 PM >>> *To:* mysticaldem...@xrgrid.com >>> *Cc:* Robert Exile In Paradise Murphey; >>> opensource-dev@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, <mysticaldem...@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-boun...@lists.secondlife.com [mailto: >>> opensource-dev-boun...@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@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 < >>> ex...@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 >
_______________________________________________ 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
