Re: [opensource-dev] Unity 3D as possible base for future (maybe even official) SL Viewers
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 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 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, wrote: >> >>> Obviously these are subjective statements but I think your statements >>> are based on an incomplete understanding of the tool and probably lim
Re: [opensource-dev] Unity 3D as possible base for future (maybe even official) SL Viewers
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 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, 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 assign
Re: [opensource-dev] Question about LOD debug setting
On Sun, 3 Oct 2010 21:01:00 -0700 (PDT), Ann Otoole wrote: > Whats the jira for this defect you say exists that I have never once observed > despite always using a setting of 4? I don't contribute to the JIRA any more: what's the point when LL marks the issues as "will not finish" or just plain ignores them for years, and when even your patches are not taken into account because they want a contribution agreement that endangers your privacy and anhilates your anonimity ?... As for a repro, I just sent you a test object in-world: it's derivated from a collar, and I reduced it to its simplest expression (5 prims in total) to demonstrate the issue: a torus (the 'collar'), and four little LEDs on its side, each made out of a sphere (around 0.015m big), hollowed at 70% and dimpled at 95%. Remove all attachments on your Av (so that there is no possible issue with the number of prims attached to your Av), and "Wear" the demonstrator (it attaches to your Av's spine and appears around its neck). - Start Snowglobe v1.4, 1.5 or v2.2, or even tyhe latest beta viewer v2.2 - Set your RenderVolumeLODFactor to 1.0, and zoom in and out on the leds: no problem. - Set your RenderVolumeLODFactor to 4.0 and zoom out and back in. 4 times out of 5 the LEDs do not come back when zooming it. In fact, the slower you zoom in, the less they are likely to reappear. If you zoom in real fast, they may come back. - Log off and start viewer v1.23.5. - Repeat the procedure: no issue at all, even with larger LOD factors. In fact any LOD factor above 2.0 shows the issue from times to time, and anything above 3.0 shows it almost everytime. > There is a different debug setting calledRenderMaxNodeSize that produces > the behavior you noted btw. It's default is 8192. Go lower and what you > describe happens. This has no influence whatsoever on the above issue. It's also set to 8192 for me anyway, and even doubling this number doesn't prevent the issue from happening Henri. ___ 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
Re: [opensource-dev] Uses of the Lookat target Crosshairs
On Mon, Oct 4, 2010 at 2:55 AM, Latif Khalifa wrote: > You are reading too much into these "targets". Those are just viewer > effects that help your viewer position head and the direction of eyes > of the avatar to the desired location. They have no other use. > Yes as Latif says there only purpose is for the head turn/look at animation so that your avatar will turn its head towards the chat source for a nice i'm listening to you effect. The LL viewer uses a small back off so that in busy areas you are not flipping your head everywhere and i would guess the LL viewer correctly clears the look at effect after a short time. Some viewers (i believed introduced by Emerald) seem to make a big deal out of the look at crosshairs, then if another viewer comes along that does not correctly clear the lookat effect you get rude IMs asking why your crosshairs are on me. I've had this before with one of my viewers, it was not clearing the look at, so in a busy area i quickly ended up with crosshairs on everyone who had spoken then started getting rude IMs from emerald users who had the look at cross hairs turned on and could see where they were pointed. Robin ___ 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
[opensource-dev] New Snowstorm Builds?
There hasn't been a new build of Snowstorm (Second Life 2.2.1 (210917) Sep 30 2010 05:11:51 (Second Life Development)) for several days. Any ETA on when new builds will be available? -- - Zak Escher email: zak.esc...@gmail.com Join me in Second Life http://secondlife.com/ss/?u=f76730f9dee0d54e3cc51e29da87373a ___ 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
[opensource-dev] Uses of the Lookat target Crosshairs
Folks, Thanks for the informed responses. I admit that most of my concern was NOT a function of seeing the cross-hairs, but rather the response I got when I inquired about it. The fact that the avatar was 10 days old, was folded up in a corner not moving, and that he basically told me to "kiss his ass" when I asked him what viewer he was using.I might also be willing to admit it was a "mistake" like Robin suffered, except the crosshairs disappeared shortly after I suggested I would be Abuse Reporting a member of his staff group in a conversation with the club owner. It seems clear that this user is NOT using a "standard" viewer, has control over the targets, and an attitude like "If you come here, we can do whatever we like" (until it looks like you might really know something about whats going on). After three years of SL, and a LOT of online time, these kinds of things raise all kinds of red flags. Robin Was "Your viewer" in use before or after the recent TPV changes? Did you intentionally alter the look at target color so that the text did not conform to the standard color codes used everywhere else? Did you sit folded up in a corner 24/7 outside a busy club? For me, the bottom line seems to be that the knowledgeable viewer folks don't see any reason to be concerned over what is most likely just a bug in someone's implementation of LookAt crosshairs. I find it just too weird that I've only seen this happen for 2 avatars, and approaching both of them in a civil manner has resulted in a response typical of a child caught with cookie crumbs on their lips. I also realize none of those issues are relevant to this mailing list... SO Thank you all again for your feedback ( and the work you all do (wink) )... D On Mon, Oct 4, 2010 at 2:14 AM, Robin Cornelius wrote: > On Mon, Oct 4, 2010 at 2:55 AM, Latif Khalifa > wrote: > > You are reading too much into these "targets". Those are just viewer > > effects that help your viewer position head and the direction of eyes > > of the avatar to the desired location. They have no other use. > > > > Yes as Latif says there only purpose is for the head turn/look at > animation so that your avatar will turn its head towards the chat > source for a nice i'm listening to you effect. The LL viewer uses a > small back off so that in busy areas you are not flipping your head > everywhere and i would guess the LL viewer correctly clears the look > at effect after a short time. > > Some viewers (i believed introduced by Emerald) seem to make a big > deal out of the look at crosshairs, then if another viewer comes along > that does not correctly clear the lookat effect you get rude IMs > asking why your crosshairs are on me. I've had this before with one of > my viewers, it was not clearing the look at, so in a busy area i > quickly ended up with crosshairs on everyone who had spoken then > started getting rude IMs from emerald users who had the look at cross > hairs turned on and could see where they were pointed. > > Robin > ___ 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
Re: [opensource-dev] Unity 3D as possible base for future (maybe even official) SL Viewers
Teravus++ On Mon, Oct 4, 2010 at 2:32 PM, 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 -- Jeroen Frans Virtual World Technology Specialist @ http://VesuviusGroup.com Second Life: Frans Charming blog about SL @ http://secondslog.blogspot.com ___ 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
Re: [opensource-dev] Unity 3D as possible base for future (maybe even official) SL Viewers
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 > 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
Re: [opensource-dev] Uses of the Lookat target Crosshairs
I am going to have to agree that too much is read into "look at targets" but I will also have to disagree that this tool serves only rudimentary uses. Tools of this nature have been in use for ages before TPVs came on the scene. I remember using them when I was an administrator in the Dreamland sandbox ages ago. It was a very useful tool for keeping an eye on people that were known to make weapons that would take out two or three sims back in the day. It is also a really useful tool for building and it was especially so back before the viewer allowed access to the advanced features that are now commonplace. Unless you used an addon back then, you could not disable camera restraints or limit select distance which made building large structures a real pain. Max Case used to make a scripted tool called "Builders Eye" which was a useful tool to get past this barrier. I remember it well as he was kind enough to customize it a bit for me once I contacted him about adding a feature. This sort of tool is still commonly used in clubs to follow avatars through crowds.. useful if there are giveaways and the club owner or DJ needs to pass a a prize in a lag infested area without pulling up search, typing in an avies name, pulling up a profile and then dropping the object on them. You can see an example of such a tool here https://marketplace.secondlife.com/p/Club-Tool-Dance-HUD-Emote-HUD-DJ-HUD-Host-HUD/1377702 And again, it is also very useful for building or pointing out specific objects to another avatar. A very popular tool used by educators is Cam Sync which allows both avatars to wear a HUD so that a students viewpoint becomes the same as the instructors. It can be useful for a variety of things other than building such as pointing out a specific object in a store as well. You can find that item here https://www.xstreetsl.com/modules.php?name=Marketplace&file=item&ItemID=1020372 If the trend continues that such tools serve no function other than pure evil then the viewer will cease to have any useful functionality at all. After all what harm is there in someone looking at your avatar? Will we soon raise notions of evildoings because you can make your avatar entirely invisible thanks to code that arose from Viewer 2 or could that actually be useful? Would all avatars going alpha during interviews or other events cut down on lag or would we just assume that evil intentions are behind it all and eject avatars that are making use of the viewers functionality? All tools that are useful can also do harm. You can use a telephone to call a doctor or the fire department but you can also use it to harass and threaten someone. There sure are a lot of telephones out there in spite of all the evil potential that they harbor. Dirk Talamasca ___ 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
Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request
On Sun, Oct 3, 2010 at 2:47 AM, Kelly Linden wrote: > Unfortunately no. LSL scripts take up 16k of memory no matter how much they > actually use. Is there any technical reason why this can't be made adjustable, though? I know that changing the amount of script memory available for LSL scripts would require a recompile, since it's fixed at compilation time, but I suspect it could be done. ___ 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
Re: [opensource-dev] Unity 3D as possible base / 2.x Codebase plugin capable?
Am happy to see some input on the idea of Unity. It makes me smile. My intent, of course, was to jolt a bit out of idea of a monolithic 2.x codebase. A lot of folks want the viewer to do quite a bit (mesh editor, anyone?). Fulfilling the wishlist without going to a plugin strategy will result in a bloated client that will run on fewer and fewer machines. So if Unity is relegated to a cool TPV project somewhere, that's fine ;) Proposing something radical like that will hopefully get people to think more about what it would take to do a very plugin oriented client (can the 2.x codebase do it? or does it call for a reset of sorts?) Where do people want to see an SL client, 2 years from now? I dont think much of possible approaches that dont handle the physics / animation / terrain / sound angles. It's just asking to reinvent too many wheels. Oh, and as for the objection to Unity outputting to game consoles: snap out of it. The mere existence of code on a console doesn't make it a game. The overall idea is to make SL / OS ubiquitous (Linux client doesnt go away, other approaches open up the Web, phones, and consoles.. all good moves). cheers, Daniel ___ 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
Re: [opensource-dev] Unity 3D as possible base / 2.x Codebase plugin capable?
I really hope LL is not going to add a Mesh Editor in the client. That's just going to be so bloated. I agree though, that plugins will be important, and some months(year?) ago it was mentioned that there is a team at LL working on doing just that. Can anyone (at LL) confirm that there is still a team working on making plugins a possibility? -Frans On Mon, Oct 4, 2010 at 10:15 PM, Daniel Smith wrote: > > Am happy to see some input on the idea of Unity. It makes me smile. > > My intent, of course, was to jolt a bit out of idea of a monolithic 2.x > codebase. A lot of folks want the viewer to do quite a bit (mesh editor, > anyone?). Fulfilling the wishlist without going to a plugin strategy will > result in a bloated client that will run on fewer and fewer machines. > > So if Unity is relegated to a cool TPV project somewhere, that's fine ;) > > Proposing something radical like that will hopefully get people to think > more about what it would take to do a very plugin oriented client (can the > 2.x codebase do it? or does it call for a reset of sorts?) Where do people > want to see an SL client, 2 years from now? > > I dont think much of possible approaches that dont handle the physics / > animation / terrain / sound angles. It's just asking to reinvent too many > wheels. Oh, and as for the objection to Unity outputting to game consoles: > snap out of it. The mere existence of code on a console doesn't make it a > game. The overall idea is to make SL / OS ubiquitous (Linux client doesnt > go away, other approaches open up the Web, phones, and consoles.. all good > moves). > > cheers, > > Daniel > > > ___ > 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 > -- Jeroen Frans Virtual World Technology Specialist @ http://VesuviusGroup.com Second Life: Frans Charming blog about SL @ http://secondslog.blogspot.com ___ 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
Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request
On Mon, Oct 4, 2010 at 1:05 PM, Aidan Thornton wrote: > On Sun, Oct 3, 2010 at 2:47 AM, Kelly Linden wrote: > > Unfortunately no. LSL scripts take up 16k of memory no matter how much > they > > actually use. > > Is there any technical reason why this can't be made adjustable, > though? I know that changing the amount of script memory available for > LSL scripts would require a recompile, since it's fixed at compilation > time, but I suspect it could be done. > LSL is crufty and hacky. It would be a serious engineering and QA effort to implement such a feature. The language is pretty specific and hard coded to 16k. Even if we had a patch ready it would be a lot of QA to be sure it worked as expected. Right now if we are doing anything of this level of work we should be working on implementing a better language and not duct taping LSL. - Kelly ___ 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
[opensource-dev] Fwd: Unity 3D as possible base / 2.x Codebase plugin capable?
-- Forwarded message -- From: Robert Martin Date: Mon, Oct 4, 2010 at 4:52 PM Subject: Re: [opensource-dev] Unity 3D as possible base / 2.x Codebase plugin capable? To: Frans On Mon, Oct 4, 2010 at 4:38 PM, Frans wrote: > I really hope LL is not going to add a Mesh Editor in the client. That's > just going to be so bloated. > personally i see very little that could be done CORRECTLY in world now i could see maybe some sort of way to send just delta info to the server and or some sort of autoupload/publish on SL plugin being of use but if you stage your 3d utility correctly you should not need to do a reupload or edit after the fact. BTW for those of you that want to to use "Legacy Mesh" clothing with a .DAE avatar you can export the current avatar mesh with a certain flaming TPV that took over certain green stone code. -- Robert L Martin -- Robert L Martin ___ 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
Re: [opensource-dev] New Snowstorm Builds?
On 2010-10-04 10:55, Zak Escher wrote: > There hasn't been a new build of Snowstorm (Second Life 2.2.1 (210917) > Sep 30 2010 05:11:51 (Second Life Development)) for several days. Any > ETA on when new builds will be available? There just have not been any new commits since then. People have been focused on beta bugs, mostly. Nice to see that we're developing an expectation of frequent fresh meat, though :-) ___ 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
Re: [opensource-dev] Unity 3D as possible base / 2.x Codebase plugin capable?
On Mon, 2010-10-04 at 13:15 -0700, Daniel Smith wrote: > > Am happy to see some input on the idea of Unity. It makes me smile. > > My intent, of course, was to jolt a bit out of idea of a monolithic > 2.x codebase. A lot of folks want the viewer to do quite a bit (mesh > editor, anyone?). Fulfilling the wishlist without going to a plugin > strategy will result in a bloated client that will run on fewer and > fewer machines. > > So if Unity is relegated to a cool TPV project somewhere, that's > fine ;) > Proposing something radical like that will hopefully get people to > think more about what it would take to do a very plugin oriented > client (can the 2.x codebase do it? or does it call for a reset of > sorts?) Where do people want to see an SL client, 2 years from now? > Hey, when it gets all-around support, it can come right back out of TPV and be an option.. > That's where I was going with my own project. Sounds like there are quite a few people thinking in the same direction - I like that. My first run through, should I ever be able to get it off the ground, was to just split up the current code base so that it would be simpler to implement things just like this. If Unity worked better on a given machine, then by all means use it, and the same with Ogre or Irrlicht or the Linden engine or OSG or etc. > I dont think much of possible approaches that dont handle the > physics / animation / terrain / sound angles. It's just asking to > reinvent too many wheels. Oh, and as for the objection to Unity > outputting to game consoles: snap out of it. The mere existence of > code on a console doesn't make it a game. The overall idea is to make > SL / OS ubiquitous (Linux client doesnt go away, other approaches open > up the Web, phones, and consoles.. all good moves). > Oh, don't misunderstand, I've got nothing against putting it on a console. The more platforms, the merrier. I don't know how useful the XBox controller would be in a heavy chat environment, but to each his own, I suppose! --GC ___ 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
Re: [opensource-dev] Unity 3D as possible base / 2.x Codebase plugin capable?
Im in all support for Unity 3d Daniel!!! Very cool! Keep the embers burning! On Mon, Oct 4, 2010 at 1:15 PM, Daniel Smith wrote: > > Am happy to see some input on the idea of Unity. It makes me smile. > > My intent, of course, was to jolt a bit out of idea of a monolithic 2.x > codebase. A lot of folks want the viewer to do quite a bit (mesh editor, > anyone?). Fulfilling the wishlist without going to a plugin strategy will > result in a bloated client that will run on fewer and fewer machines. > > So if Unity is relegated to a cool TPV project somewhere, that's fine ;) > > Proposing something radical like that will hopefully get people to think > more about what it would take to do a very plugin oriented client (can the > 2.x codebase do it? or does it call for a reset of sorts?) Where do people > want to see an SL client, 2 years from now? > > I dont think much of possible approaches that dont handle the physics / > animation / terrain / sound angles. It's just asking to reinvent too many > wheels. Oh, and as for the objection to Unity outputting to game consoles: > snap out of it. The mere existence of code on a console doesn't make it a > game. The overall idea is to make SL / OS ubiquitous (Linux client doesnt > go away, other approaches open up the Web, phones, and consoles.. all good > moves). > > cheers, > > Daniel > > > ___ > 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
Re: [opensource-dev] Unity 3D as possible base / 2.x Codebase plugin capable?
On Mon, Oct 4, 2010 at 1:38 PM, Frans wrote: > I really hope LL is not going to add a Mesh Editor in the client. That's > just going to be so bloated. I think it's a terrible idea for LL to try to recreate tools that teams of professionals have already been working on for years. Photoshop, Gimp, Blender, Max, Maya -- there are specialty tools out there, many of them free, that already do a much, much better job than LL ever could, simply because that is their only job and they have years of a head start. What I would like to see is a better connection with existing tools. Being able to have SL work with other programs easier, better conversion and import support, to cut steps out of the design workflow. For example, texture work often involves modifying a texture, test it out, modifying it again, and repeat forever. Having SL "watch" a texture, model, or other file for a change and automatically update it in SL so you can see exactly what it will look like would cut out a lot of steps. Even if it was only a local view. Heck, even if I had to pay for every single time I hit the save button in Photoshop or Blender. Though I'd prefer it be integrated in a way that all people could see what I was working on, then I hit "finalize" and it does the final upload. Having said that, very simple editors that are not designed to have fancy features but be as basic as possible would allow people to create things without going to an outside source. But it must be clear and planned that they will never evolve beyond a basic level. A simple whiteboard-style application for textures, being able to push vertices around on a model or sculpty. Nothing fancy, but enough to create something simple or touch something up without starting up an external program. That's my opinion. I know it's not universal, but it's my view based on my limited experience as a content creator. Stickman ___ 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
Re: [opensource-dev] Unity 3D as possible base / 2.x Codebase plugin capable?
LL Snowstorm/Opensource-Dev, To stimulate SL growth and accessibility to the mainstream, one or the collective SL Viewer developers and/or decision makers ought to think & design universally. If mesh becomes a standard in SL, a basic mesh editor ought to be included by default. The ability to plugin with existing professional tools such as Photoshop, Gimp, Blender, Max, etc. is essential for high-end content production and advanced SL users. However, to deny a new users who are discovering either 3D Second Life or the 3D Web for the first time a complete basic set of content creation tools for the 3D world they are introduced to (of which would include a mesh editor), may seriously discourage them; along with potential opportunity for regular influx of new & emerging content creators within our community from Low, Medium, and High End. SL Viewer Mesh Editor doesn't need to be Maya, it just needs to be 'there' and 'basic' to encourage new content creators to create and feel that they begin to learn and participate without significant barriers. We must try and avoid any situation where a New User in SL feels disadvantaged or unable to create before they start. Regards, DMC Zsigmond-Jurassic Science Fiction. -Original Message- From: opensource-dev-boun...@lists.secondlife.com [mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Stickman Sent: Tuesday, October 05, 2010 2:48 PM To: Frans Cc: opensource-dev@lists.secondlife.com Subject: Re: [opensource-dev] Unity 3D as possible base / 2.x Codebase plugin capable? On Mon, Oct 4, 2010 at 1:38 PM, Frans wrote: > I really hope LL is not going to add a Mesh Editor in the client. That's > just going to be so bloated. I think it's a terrible idea for LL to try to recreate tools that teams of professionals have already been working on for years. Photoshop, Gimp, Blender, Max, Maya -- there are specialty tools out there, many of them free, that already do a much, much better job than LL ever could, simply because that is their only job and they have years of a head start. What I would like to see is a better connection with existing tools. Being able to have SL work with other programs easier, better conversion and import support, to cut steps out of the design workflow. For example, texture work often involves modifying a texture, test it out, modifying it again, and repeat forever. Having SL "watch" a texture, model, or other file for a change and automatically update it in SL so you can see exactly what it will look like would cut out a lot of steps. Even if it was only a local view. Heck, even if I had to pay for every single time I hit the save button in Photoshop or Blender. Though I'd prefer it be integrated in a way that all people could see what I was working on, then I hit "finalize" and it does the final upload. Having said that, very simple editors that are not designed to have fancy features but be as basic as possible would allow people to create things without going to an outside source. But it must be clear and planned that they will never evolve beyond a basic level. A simple whiteboard-style application for textures, being able to push vertices around on a model or sculpty. Nothing fancy, but enough to create something simple or touch something up without starting up an external program. That's my opinion. I know it's not universal, but it's my view based on my limited experience as a content creator. Stickman ___ 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
