Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request

[Argent Stonecutter]

On 2010-10-02, at 20:47, Kelly Linden wrote:
> On Sat, Oct 2, 2010 at 4:40 PM, Argent Stonecutter  
> wrote:
>> Could this be applied to LSL scripts as well, since they could be made 
>> potentially MUCH smaller? A kilobyte might be enough for a poseball, for 
>> example, and even less for a titler or particle script.
> 
> Unfortunately no. LSL scripts take up 16k of memory no matter how much they 
> actually use.

I know they do. That's why I was asking if that could be changed. Have a script 
size box in the script editor, when you compile you can select 1k, 2k, 4k... up 
to 16k. That could potentially save a lot of memory... megabytes for locations 
with lots of scripted furniture.

___
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] CAN WE PLEASE STOP VIEWER DEVELOPMENT FOR 5 MINUTES

[malachi]

could we please take 5 minutes away from the client that we all obviously  
have our second thoughts about to begin with. and focus on grid  
infrastructure.

i honestly dont care if i am forced to use the dreaded 2.x client. if the  
grid actually responded to something you did. things like just loading my  
clothing. or if i save a script it should still exist after i close the  
edit box. but the fact that any script added to a prim inworld gets eaten  
and destroyed server side is a huge issue. could LL drop the client work  
for 5 minutes and see what is going on on the server? or is that too much  
to ask? because as it seems over the last few weeks its been new client  
code new client code new client code while the server just gradually falls  
off a cliff. what good is a client that runs like fiber when the server it  
connects to only speaks in dialup?


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
___
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] CAN WE PLEASE STOP VIEWER DEVELOPMENT FOR 5 MINUTES

[Carlo Wood]

Welcome to open source viewer, closed source server.

On Sun, Oct 03, 2010 at 10:27:52AM -0400, malachi wrote:
> could we please take 5 minutes away from the client that we all obviously  
> have our second thoughts about to begin with. and focus on grid  
> infrastructure.
> 
> i honestly dont care if i am forced to use the dreaded 2.x client. if the  
> grid actually responded to something you did. things like just loading my  
> clothing. or if i save a script it should still exist after i close the  
> edit box. but the fact that any script added to a prim inworld gets eaten  
> and destroyed server side is a huge issue. could LL drop the client work  
> for 5 minutes and see what is going on on the server? or is that too much  
> to ask? because as it seems over the last few weeks its been new client  
> code new client code new client code while the server just gradually falls  
> off a cliff. what good is a client that runs like fiber when the server it  
> connects to only speaks in dialup?
> 
> 
> -- 
> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
> ___
> 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

-- 
Carlo Wood 
___
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] CAN WE PLEASE STOP VIEWER DEVELOPMENT FOR 5 MINUTES

[Oz Linden (Scott Lawrence)]

  On 2010-10-03 10:27, malachi wrote:
> could we please take 5 minutes away from the client that we all obviously
> have our second thoughts about to begin with. and focus on grid
> infrastructure.
>
> i honestly dont care if i am forced to use the dreaded 2.x client. if the
> grid actually responded to something you did. things like just loading my
> clothing. or if i save a script it should still exist after i close the
> edit box. but the fact that any script added to a prim inworld gets eaten
> and destroyed server side is a huge issue. could LL drop the client work
> for 5 minutes and see what is going on on the server? or is that too much
> to ask? because as it seems over the last few weeks its been new client
> code new client code new client code while the server just gradually falls
> off a cliff. what good is a client that runs like fiber when the server it
> connects to only speaks in dialup?

The subject of this list is the open source, which does not include the 
server side.  Discussions of interactions with the server are of course 
in scope.

There is little conflict in the people involved with server side and 
viewer side development, so stopping viewer development would do little 
to change server problem resolution even if that is where the problem is.

It sounds as though you are experiencing some serious problems, but the 
descriptions above are not nearly complete enough for anyone to 
determine what the real problems are, much less determine who could best 
solve them.

___
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] CAN WE PLEASE STOP VIEWER DEVELOPMENT FOR 5 MINUTES

[Obsidian Kindragon]

  On 10/3/2010 8:38 AM, Oz Linden (Scott Lawrence) wrote:
>On 2010-10-03 10:27, malachi wrote:
>> could we please take 5 minutes away from the client that we all obviously
>> have our second thoughts about to begin with. and focus on grid
>> infrastructure.
>>
>> i honestly dont care if i am forced to use the dreaded 2.x client. if the
>> grid actually responded to something you did. things like just loading my
>> clothing. or if i save a script it should still exist after i close the
>> edit box. but the fact that any script added to a prim inworld gets eaten
>> and destroyed server side is a huge issue. could LL drop the client work
>> for 5 minutes and see what is going on on the server? or is that too much
>> to ask? because as it seems over the last few weeks its been new client
>> code new client code new client code while the server just gradually falls
>> off a cliff. what good is a client that runs like fiber when the server it
>> connects to only speaks in dialup?
> The subject of this list is the open source, which does not include the
> server side.  Discussions of interactions with the server are of course
> in scope.
>
> There is little conflict in the people involved with server side and
> viewer side development, so stopping viewer development would do little
> to change server problem resolution even if that is where the problem is.
>
> It sounds as though you are experiencing some serious problems, but the
> descriptions above are not nearly complete enough for anyone to
> determine what the real problems are, much less determine who could best
> solve them.
>
> ___
> 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
>
I agree with OZ here. The issue could be client side or server side, but 
as Oz stated we don't have enough information.

I think Malachi needs to describe the steps he's using to reproduce the 
issue (even if it's not consistently occurring) for each of the problems 
he's seeing so people can reproduce and add it to an existing JIRA or 
open a new one if one doesn't already exist for the specific problem.

- Obsidian Stormwind
___
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] Question about LOD debug setting

[Ponzu]

I picked up a notecard that says to increase RenderVolumeLODFactor to 4.  Is
this reasonable, do you think?  And if so, why not increase the default a
bit (currently seems to be 1.125

lee

==notecard says===
 well, its until they fix this lod problem, its just a workaround.

Debugging your LOD settings is something that can and will make all your
sculpts hold the intended detail better.
Follow these easy steps:

1. Show the "Advanced" menu with Ctrl-Alt-D, or Opt-Ctrl-D on a Mac.
2. Select "debug settings" near the bottom.
3. In the blank space, copy and paste the word:

RenderVolumeLODFactor

4. In the box below, set the number. The recommended setting is as high as 4
to have all your sculpts looking as the creator intended.

Unlike increasing your draw distance, this will NOT create lag for yourself
or those around you!  And it will improve the look of all sculpts.
___
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] Question about LOD debug setting

[leliel]

On Sun, Oct 3, 2010 at 10:37 AM, Ponzu  wrote:
> I picked up a notecard that says to increase RenderVolumeLODFactor to 4.  Is
> this reasonable, do you think?  And if so, why not increase the default a
> bit (currently seems to be 1.125

It is reasonable, the default setting is a bit low. It varies with
your graphics settings tho, 0 for low, 1.125 for mid & high, and 2 for
ultra IIRC. I find 3 a good compromise between quality and
performance.


> Unlike increasing your draw distance, this will NOT create lag for yourself

This however, is blatantly false. If rendering everything at full
detail all the time didn't cause a drop in frame rate than why would
we even bother with LOD?
___
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] Question about LOD debug setting

[Ponzu]

On Sun, Oct 3, 2010 at 2:54 PM, leliel  wrote:

>
> > Unlike increasing your draw distance, this will NOT create lag for
> yourself
>
> This however, is blatantly false. If rendering everything at full
> detail all the time didn't cause a drop in frame rate than why would
> we even bother with LOD?
>

Understood.  She was only talking about sculpties, however.
___
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] CAN WE PLEASE STOP VIEWER DEVELOPMENT FOR 5 MINUTES

[Daniel Smith]

I agree with Oz on this as well.  There are different folks working on the
client and server sides.  Throwing the client folks over to fix server side
problems runs the risk of actually slowing things down.

The huge, looming issue on the client side is simply this: evolution.

Where could the 2.x viewer be, 2 years from now?

Where could a 3.x viewer, with a plugin architecture, be in 2 years?

Where could a Unity-based viewer be in 2 years?

Without a good plugin architecture, this viewer is going to keep growing.
It will become even more of a monolithic piece of code that wont run well on
lower end machines.

With a good plugin architecture, there is the opportunity for a solid core +
customization.  Chrome and Firefox come to mind as examples on the web side.

Having said all that though, think about this:

It is a Sunday.  Go look at what Unity 3.x (you can download it for free) is
capable of.   Can any 2.x codebase get to that level of quality in the next
2 years?  I dont think so.

Consider what it would take to have a Unity foundation, layered with the
SL-specific experience on top.  Then think about it the other way (trying to
get the existing standard of 2.x to that level of quality, and on all of
those platforms).

My thought would be: get mesh out there on 2.x viewer, and then put on the
brakes and consider direction.

Daniel  -
daniel.org/blog
___
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

[Zi Ree]

Am Samstag 02 Oktober 2010 16:49:48 schrieb Lance Corrimal:

> phoenix already does that, in its radar you can define a warning that
> tells you when the script count in the sim changes by more than a
> threshold that you define... so there already _is_ a way to count all
> scripts in a sim.

Counting scripts on the sim is part of the sim stats (ctrl shift 1), we're 
talking about per object or per avatar.

Zi
___
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

[Lance Corrimal]

Am Sonntag 03 Oktober 2010 schrieb Zi Ree:
> Am Samstag 02 Oktober 2010 16:49:48 schrieb Lance Corrimal:
> > phoenix already does that, in its radar you can define a warning
> > that tells you when the script count in the sim changes by more
> > than a threshold that you define... so there already _is_ a way
> > to count all scripts in a sim.
> 
> Counting scripts on the sim is part of the sim stats (ctrl shift
> 1), we're talking about per object or per avatar.


Ah... didn't see that part.
___
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] another script fighting question

[miss c]

No one in concierge seems to know this, so I thought I would ask the viewer 
specialists here.  


When you first call for top scripts in region tools what is the order it is 
returning initially.  I know it's not random because some avatars come up in 
the 
same spots everytime.  I know its not time, because some avies and objects are 
higher than others.  Could it possibly be calls on the server??  or is it 
something as simple as UUID order.  I NEED A CLASS 7!


Combating the lag every hour on the hour.

TY

Miss



  ___
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] Question about LOD debug setting

[Ann Otoole]

It simply depends on your computer and video card. I can run that setting at 4 
with no noticeable difference. 


LL's quest to remain mired in circa 1999 graphics is admirable and noble and 
all 
but is costing SL/LL a vast amount of money. When mesh is rolled out and the 
inevitable "use all available resources" happens then I dare say SL will look a 
lot better but will probably lose the lower end anyway as they get tired and 
drop out because they can't have a decent experience and they choose alcohol, 
tobacco, reefer, and pizza over a decent gaming rig.

As is said at Microsoft: Upgrade or die" This too shall happen with SL if SL is 
to survive a long time. If LL doesn't do it then someone else will.

As for defaults yes the ultra default should be 4. LL recently changed the 
gpu_table.txt settings and any card that defults to ultra can more than handle 
RenderVolumeLODFactor at 4 with no noticeable impact. My GT240 on Kirstens with 
full shadows tweaked for realism gets a great frame rate with 
RenderVolumeLODFactor at 4. With shadows off and RenderVolumeLODFactor at 4 I 
get better than 29.97 FPS which is cinematic quality. 


However I get tired of ARC pundits spreading lies. Especially the ones saying 
mesh is low ARC since currently a theoretical mesh with 64 ktris/fr (64,000 
polys per frame) will register less than 20 ARC depending on the settings and 
scripts involved. It is, after all, one damned prim to ARC. Oh, and BTW, the 
"ARC" will have to be changed to show mesh render cost and leave out the script 
cost. Make a script cost measure and a real ktris/fr worst case cost estimate 
measure for the avatar. And then we need parcel/region render cost metrics 
available as well. And an estimated bytes downloaded measure for people on 
capped bandwidth plans. The entire concept of impact metrics needs to be 
revisited and done right IMHO.





From: leliel 
To: opensource-dev 
Sent: Sun, October 3, 2010 2:54:36 PM
Subject: Re: [opensource-dev] Question about LOD debug setting

On Sun, Oct 3, 2010 at 10:37 AM, Ponzu  wrote:
> I picked up a notecard that says to increase RenderVolumeLODFactor to 4.  Is
> this reasonable, do you think?  And if so, why not increase the default a
> bit (currently seems to be 1.125

It is reasonable, the default setting is a bit low. It varies with
your graphics settings tho, 0 for low, 1.125 for mid & high, and 2 for
ultra IIRC. I find 3 a good compromise between quality and
performance.


> Unlike increasing your draw distance, this will NOT create lag for yourself

This however, is blatantly false. If rendering everything at full
detail all the time didn't cause a drop in frame rate than why would
we even bother with LOD?
___
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] 2.0 Absolute Dealbreaker - script count feature request !!!!!!!

[miss c]

This is why we need it

 [12:52]  Counted scripts from 19 attachments on Sxt Cxxx: 1102


  ___
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] Unity 3D as possible base for future (maybe even official) SL Viewers (was: CAN WE PLEASE STOP VIEWER DEVELOPMENT FOR 5 MINUTES)

[Boroondas Gupte]

 On 10/03/2010 08:57 PM, Daniel Smith wrote:
> Consider what it would take to have a Unity foundation, layered with
> the SL-specific experience on top.
What it would take? At least Linux support for Unity.

While the percentage of Linux users among SL users might still be small
enough to be regarded negligible by some people, the percentage of Linux
users amongst the open source developer community around Linden Lab's
current official viewer is certainly significant.

Of course, one might assume a Unity based Viewer project would attract
enough new developers that one wouldn't have to rely on as many from the
current developer community as possible, but somehow I don't think
that'd be the case.

Then, I'd image Linden Lab would probably want to use Unity Pro for
development while most community developers would stick to the free (as
in beer) Unity license. Can developers with the free license even
collaborate in projects otherwise developed with the Pro one? Or would
this turn this new viewer into a pure in-house project, even if the new
viewer was open source, too? (Well, as open source as it can be with the
engine being proprietary.)

Boroondas
___
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 (was: CAN WE PLEASE STOP VIEWER DEVELOPMENT FOR 5 MINUTES)

[Daniel Smith]

On Sun, Oct 3, 2010 at 1:26 PM, Boroondas Gupte
wrote:

>  On 10/03/2010 08:57 PM, Daniel Smith wrote:
> > Consider what it would take to have a Unity foundation, layered with
> > the SL-specific experience on top.
> What it would take? At least Linux support for Unity.
>

Yep, that came up as a point on my blog, and I answered:

> Now, let’s look at the deployment platforms in Unity 
> 3.0,
> which just came out on Monday — all of these will be available soon:
>
> Mac, Windows, Web, iPhone, Android, Wii, PS3, and Xbox 360
>
> I think that’s amazing. Don’t you? Yes, it sucks a little that Linux isn’t
> in there. … But… if there is that potential to get a better experience for
> 95% of the current users, and to open up a bunch of new platforms to them
> and new users, then my gut says that is the right way to go.
>
Also.. I would think that the current Linux viewer could maintain
compatibility.
-- 
Daniel Smith - Sonoma County, California
http://daniel.org/resume
___
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 !!!!!!!

[Ponzu]

On Sun, Oct 3, 2010 at 3:59 PM, miss c  wrote:

> This is why we need it
>
>  [12:52]  Counted scripts from 19 attachments on Sxt Cxxx: 1102
>
>
>
I suggest a different approach.  Enable health/damage in your sim, and then
*kill* them.
___
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 (was: CAN WE PLEASE STOP VIEWER DEVELOPMENT FOR 5 MINUTES)

[Celierra Darling]

More than whether 2.x can technically get Unity features in two years, a
question would be how to teach or incentivize creators to use those features
without creating a laggy Tragedy of the Commons situation on the machines
the viewers are running on.  If you consider how much work and discussion is
needed to develop metrics and limits (for example, in that script metrics
thread), two years (or more!) might be taken up in just planning and testing
those rules.  The social considerations need to be thought about just as
carefully as (if not more than) technical ones.

(Also, adding additional platforms won't be free either - they each need
extra work for their different quirks, user interfaces, and strengths and
weaknesses.  Trying to use a Windows PC viewer on the Wii or Android would
be a train wreck.  It's not like C# scripting was suddenly free after
getting mono.)

Celi

On Sun, Oct 3, 2010 at 2:57 PM, Daniel Smith  wrote:

>
> Where could a Unity-based viewer be in 2 years?
> ...
> Consider what it would take to have a Unity foundation, layered with the
> SL-specific experience on top.  Then think about it the other way (trying to
> get the existing standard of 2.x to that level of quality, and on all of
> those platforms).
___
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

[Glen Canaday]

No Linux support is a total deal-breaker for me. I really don't care how
many platforms are supported, and that includes gaming consoles, if mine
isn't. Gaming consoles are irrelevant, as SL is not a game and would not
sell at Best Buy even if it were, making that support a completely moot
point.

I don't pay for the "privilege" of using an operating system on my
hardware. Just because someone else does does not mean I (and the rest
of the Linux users in SL, including a pretty good percentage of Lindens)
should be shut out. If a commercial piece of software does not support
the entire user base and is not GPL or LGPL, then it should be off the
table completely.

If you really want to do something like this, look to Ogre instead.

--GC

On Sun, 2010-10-03 at 13:44 -0700, Daniel Smith wrote:
> 
> 
> On Sun, Oct 3, 2010 at 1:26 PM, Boroondas Gupte
>  wrote:
>  On 10/03/2010 08:57 PM, Daniel Smith wrote:
> > Consider what it would take to have a Unity foundation,
> layered with
> > the SL-specific experience on top.
> What it would take? At least Linux support for Unity.
> 
> Yep, that came up as a point on my blog, and I answered: 
> 
> Now, let’s look at the deployment platforms in Unity 3.0,
> which just came out on Monday — all of these will be available
> soon:
> 
> Mac, Windows, Web, iPhone, Android, Wii, PS3, and Xbox 360
> 
> I think that’s amazing. Don’t you? Yes, it sucks a little that
> Linux isn’t in there. … But… if there is that potential to get
> a better experience for 95% of the current users, and to open
> up a bunch of new platforms to them and new users, then my gut
> says that is the right way to go.
> 
> Also.. I would think that the current Linux viewer could maintain
> compatibility. 
> 
> -- 
> Daniel Smith - Sonoma County, California
> http://daniel.org/resume
> 
> ___
> 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 for future (maybe even official) SL Viewers

[Daniel Smith]

On Sun, Oct 3, 2010 at 2:56 PM, Glen Canaday  wrote:

> No Linux support is a total deal-breaker for me.
>
> I never said anything about the Linux viewer going away.
I note that we have Pocket Metaverse now, and have had AjaxLife in the past.
If it helps at all, I started with BSD Unix in 1981, Linux in 1994 ;)

As is the case with web browsers, a VR client to the same server could take
many forms.

Ultimately, it's about what the community wants, and if a critical mass of
developers decides to give them that.  It doesn't have to be an official
Linden effort at all.

All I am saying is, in 2 years time, I cant see the current codebases even
getting to the point where Unity 3.0 is today, in terms of graphics,
physics, animation, terrain, and sound.
But, I could see a pretty decent SL app done in Unity within that amount of
time.

And, of course, I am just an interested observer.  I dont speak for LL,
Vivaty, AOL, Autodesk, or anywhere else I have worked :)

Daniel

-- 
Daniel Smith - Sonoma County, California
http://daniel.org/resume
___
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

[Glen Canaday]

On Sun, 2010-10-03 at 15:09 -0700, Daniel Smith wrote:
> 
> 
> On Sun, Oct 3, 2010 at 2:56 PM, Glen Canaday 
> wrote:
> No Linux support is a total deal-breaker for me.
> 
> I never said anything about the Linux viewer going away.
> I note that we have Pocket Metaverse now, and have had AjaxLife in the
> past.
> If it helps at all, I started with BSD Unix in 1981, Linux in 1994 ;)
> 
> As is the case with web browsers, a VR client to the same server could
> take many forms.
> 
> Ultimately, it's about what the community wants, and if a critical
> mass of developers decides to give them that.  It doesn't have to be
> an official Linden effort at all.
> 
> All I am saying is, in 2 years time, I cant see the current codebases
> even getting to the point where Unity 3.0 is today, in terms of
> graphics, physics, animation, terrain, and sound.
> But, I could see a pretty decent SL app done in Unity within that
> amount of time.
> 
> And, of course, I am just an interested observer.  I dont speak for
> LL, Vivaty, AOL, Autodesk, or anywhere else I have worked :)
> 
> Daniel 

It's hard to see exactly where the rendering engine will go, really, in
2 years. For a plugin-based client, as some (including myself) are
rather nudging towards, the renderer is just a part of the whole and
could in theory be hot-swapped if desired to A/B different engines. Even
if those renderers swapped between opengl and directx, it could still
fly. But to suggest that the main client perhaps go to something that
does not work across the board doesn't really include the whole of the
population - something which LL would be keen to retain.

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.

--GC

> -- 
> Daniel Smith - Sonoma County, California
> http://daniel.org/resume
> 


___
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

[Reed Steamroller]

Run Unity in a VM.  Works for me.

On Sun, Oct 3, 2010 at 6:15 PM, Glen Canaday  wrote:

> On Sun, 2010-10-03 at 15:09 -0700, Daniel Smith wrote:
> >
> >
> > On Sun, Oct 3, 2010 at 2:56 PM, Glen Canaday 
> > wrote:
> > No Linux support is a total deal-breaker for me.
> >
> > I never said anything about the Linux viewer going away.
> > I note that we have Pocket Metaverse now, and have had AjaxLife in the
> > past.
> > If it helps at all, I started with BSD Unix in 1981, Linux in 1994 ;)
> >
> > As is the case with web browsers, a VR client to the same server could
> > take many forms.
> >
> > Ultimately, it's about what the community wants, and if a critical
> > mass of developers decides to give them that.  It doesn't have to be
> > an official Linden effort at all.
> >
> > All I am saying is, in 2 years time, I cant see the current codebases
> > even getting to the point where Unity 3.0 is today, in terms of
> > graphics, physics, animation, terrain, and sound.
> > But, I could see a pretty decent SL app done in Unity within that
> > amount of time.
> >
> > And, of course, I am just an interested observer.  I dont speak for
> > LL, Vivaty, AOL, Autodesk, or anywhere else I have worked :)
> >
> > Daniel
>
> It's hard to see exactly where the rendering engine will go, really, in
> 2 years. For a plugin-based client, as some (including myself) are
> rather nudging towards, the renderer is just a part of the whole and
> could in theory be hot-swapped if desired to A/B different engines. Even
> if those renderers swapped between opengl and directx, it could still
> fly. But to suggest that the main client perhaps go to something that
> does not work across the board doesn't really include the whole of the
> population - something which LL would be keen to retain.
>
> 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.
>
> --GC
>
> > --
> > Daniel Smith - Sonoma County, California
> > http://daniel.org/resume
> >
>
>
> ___
> 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
>



-- 
William Reed Seal Foss (Reed Steamroller)
Chief Creative Officer
Sand Castle Studios LLC | Second Life

http://www.ChangingWorldsBuildingDreams.com
r...@changingworldsbuildingdreams.com
http://www.Twitter.com/ReedSteamroller
___
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

[Argent Stonecutter]

On 2010-10-03, at 17:39, Reed Steamroller wrote:
> Run Unity in a VM.  Works for me.

Run a 3d graphical application in a VM?

[insert picture of the Biting Pear of Salamanca here]
___
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

[Sythos]

On Sun, 3 Oct 2010 18:03:40 -0500
Argent Stonecutter  wrote:

> On 2010-10-03, at 17:39, Reed Steamroller wrote:
> > Run Unity in a VM.  Works for me.
> 
> Run a 3d graphical application in a VM?

Xen have a nice and working abstraction layer (tryed on nvidia) and
allow guest OS to use full 3D hardware from guest to host 

this don't mean performance are like use from native os...
___
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] Question about LOD debug setting

[Henri Beauchamp]

On Sun, 3 Oct 2010 13:37:49 -0400, Ponzu wrote:

> I picked up a notecard that says to increase RenderVolumeLODFactor to 4.  Is
> this reasonable, do you think?  And if so, why not increase the default a
> bit (currently seems to be 1.125

4 is OK for viewer v1.23.5. For Snowglobe (v1 and v2) and viewer 2, you
should not use more than 3, because when using larger values, you will
get graphic glitches with very small prims, especially with attachments:
zooming out, they will vanish (as expected), but zooming back in, they
will stay hidden 4 times out of 5 (zooming fast out and back in may
get the small primes to appear again)...

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] Unity 3D as possible base for future (maybe even official) SL Viewers

[Robert "Exile In Paradise" Murphey]

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

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

[Brandon Husbands]

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.
---
---
___
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

[mysticaldemina]

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
 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.

---

---

___
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

[dz]

Folks,

Apologies if this is NOT the place to post this...but I really don't know
who else to ask.

Yesterday I encountered an avatar who exhibited a very strange behavior.
Whenever someone in the club spoke in local chat, a Look At target would
attach to them.  I understand there is a toggle to have your look at swap to
the the most recent to chat,   but this look at target was white...  which
is not a standard cross hair color.

The other incredibly odd thing  was that the look at target stayed locked
once there..  Because I was using the phoenix browser, which puts names on
the targets, I could see that there were as many as 30 of these targets
active at once.

Does anyone know of a way to determine  what the white target denotes, how
it gets attached to multiple targets at once?

When i asked the avatar  I got a very rude response...  When I carried my
concern to the club owner, I got more rudeness and denials.. but it seemed
clear that there was some intent behind the crosshairs, as they were removed
shortly after I expressed my concerns.

D
___
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

[Latif Khalifa]

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.

Latif

On Mon, Oct 4, 2010 at 3:37 AM, dz  wrote:
> Folks,
>
> Apologies if this is NOT the place to post this...but I really don't know
> who else to ask.
>
> Yesterday I encountered an avatar who exhibited a very strange behavior.
> Whenever someone in the club spoke in local chat, a Look At target would
> attach to them.  I understand there is a toggle to have your look at swap to
> the the most recent to chat,   but this look at target was white...  which
> is not a standard cross hair color.
>
> The other incredibly odd thing  was that the look at target stayed locked
> once there..  Because I was using the phoenix browser, which puts names on
> the targets, I could see that there were as many as 30 of these targets
> active at once.
>
> Does anyone know of a way to determine  what the white target denotes, how
> it gets attached to multiple targets at once?
>
> When i asked the avatar  I got a very rude response...  When I carried my
> concern to the club owner, I got more rudeness and denials.. but it seemed
> clear that there was some intent behind the crosshairs, as they were removed
> shortly after I expressed my concerns.
>
> D
>
> ___
> 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 for future (maybe even official) SL Viewers

[Brandon Husbands]

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,  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
> pr

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

[mysticaldemina]

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 gro

Re: [opensource-dev] Question about LOD debug setting

[Ann Otoole]

Whats the jira for this defect you say exists that I have never once observed 
despite always using a setting of 4?

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.





From: Henri Beauchamp 
To: opensource-dev@lists.secondlife.com
Sent: Sun, October 3, 2010 7:46:24 PM
Subject: Re: [opensource-dev] Question about LOD debug setting

On Sun, 3 Oct 2010 13:37:49 -0400, Ponzu wrote:

> I picked up a notecard that says to increase RenderVolumeLODFactor to 4.  Is
> this reasonable, do you think?  And if so, why not increase the default a
> bit (currently seems to be 1.125

4 is OK for viewer v1.23.5. For Snowglobe (v1 and v2) and viewer 2, you
should not use more than 3, because when using larger values, you will
get graphic glitches with very small prims, especially with attachments:
zooming out, they will vanish (as expected), but zooming back in, they
will stay hidden 4 times out of 5 (zooming fast out and back in may
get the small primes to appear again)...

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



  ___
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

[Brandon Husbands]

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 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