Re: [opensource-dev] Viewer 2 beta crash osx
I would attach that video, any logs you can collect, and possibly a screen of anything odd in your inventory to a jira. I might also attach some logs of a successful login in with 1.x I knwo the codebases are different, but theres always the slim hope that by comparing the two something might become obvious. beyond that i dunno? Date: Sat, 16 Oct 2010 01:10:50 -0400 From: m...@inworlddesigns.com To: opensource-dev@lists.secondlife.com Subject: [opensource-dev] Viewer 2 beta crash osx Ok so I have been having the crashing problem on login every since viewer 2. I can still login fine with the viewer 1.x viewers but none of the viewer 2 viewers login fully they just crash. I have tried clearing cache and deleting everything blah blah even reinstalled osx and same thing. Here is a video of when it crashes http://www.youtube.com/watch?v=nw9I1W6ugvI What else can I provide to help figure out what it might be? ___ 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] Viewer 2 beta crash osx
Well I think I just narrowed it down. I turned off streaming media and I am able to login now. I guess viewer 2 auto loads the media even if it isn't set to auto play? I should have thought of it earlier and I don't know why I didn't. I can't play streaming media in the v1.x viewers either but they don't try to play the streams auto or something because I don't have to disable it on them I just can't play them. On Sat, Oct 16, 2010 at 2:11 AM, Erin Mallory angel_of_crim...@hotmail.com wrote: I would attach that video, any logs you can collect, and possibly a screen of anything odd in your inventory to a jira. I might also attach some logs of a successful login in with 1.x I knwo the codebases are different, but theres always the slim hope that by comparing the two something might become obvious. beyond that i dunno? Date: Sat, 16 Oct 2010 01:10:50 -0400 From: m...@inworlddesigns.com To: opensource-dev@lists.secondlife.com Subject: [opensource-dev] Viewer 2 beta crash osx Ok so I have been having the crashing problem on login every since viewer 2. I can still login fine with the viewer 1.x viewers but none of the viewer 2 viewers login fully they just crash. I have tried clearing cache and deleting everything blah blah even reinstalled osx and same thing. Here is a video of when it crashes http://www.youtube.com/watch?v=nw9I1W6ugvI What else can I provide to help figure out what it might be? ___ 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
[opensource-dev] latest viewer-development checkout doesn't build...
... it tries do download some of the prebuild libraries by scp which of course dies at LL's external firewall... any reason for this? bye, LC ___ 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] What is the expected behaviour when double clicking floater edges? (VWR-23452)
Personally, I didn't expect double clicking the edges or corners of a resizeable floater to do anything at all, so I didn't do it until it happened to me yesterday by accident. I was surprised to see the floater change size and figured I must have been moving the mouse, thus dragging the edge. But when trying again, noticed this also happened when the mouse pointer wasn't moving at all, so I filed bug VWR-23452 https://jira.secondlife.com/browse/VWR-23452. Further investigation revealed that the double clicked edge became aligned to the edges of other floaters or the edge of the Second Life window. While unexpected to me, this might be useful for arranging floaters and doesn't look like a bug but rather like a deliberately coded feature. Is it? I didn't know about this yet, but it looks like this was already present in 1.23. Cheers, 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] latest viewer-development checkout doesn't build...
Actually there is a jira on this issue generated last night. https://jira.secondlife.com/browse/VWR-23455 From: opensource-dev-boun...@lists.secondlife.com [mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Lance Corrimal Sent: Saturday, October 16, 2010 5:10 AM To: opensource-dev@lists.secondlife.com Subject: [opensource-dev] latest viewer-development checkout doesn't build... ... it tries do download some of the prebuild libraries by scp which of course dies at LL's external firewall... any reason for this? bye, LC ___ 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 _ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1136 / Virus Database: 422/3199 - Release Date: 10/15/10 ___ 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] Project-MESH viewer
On 2010-10-15 18:00, Trilo Byte wrote: But on the flipside, the Project MESH viewer has working shadows for nVidia GPU's on Mac (never happened before on any known config), and anti-aliasing's fixed. If we could get that bit out of the mesh viewer and into the 2.2 pipeline, we'd really be in great shape IMO. The AA fix is in the 2.2 pipeline (I did that merge) ... not sure about the other (since I don't know which change that was). ___ 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] O.O Display name code DROP!
On 2010-10-15 19:22, Boroondas Gupte wrote: On 10/16/2010 12:59 AM, SuezanneC Baskerville wrote: What happened to that jira issue? It appears to have been moved to SEC or something like that. It has been moved to DN-179 https://jira.secondlife.com/browse/DN-179. (I guess DN stands for display names.) Why we can't see that jira project although display names has been on Aditi for some while now, I don't know. The fact that it became invisible when assigned to the development team is a configuration error. I've put in a request for a fix, and expect that it will be done in the next few days (the person who normally makes such changes returns from vacation on Monday, I think). As Boroondas noted, the part of that issue that broke the creation of personal chat logs has been fixed and integrated into the current development viewer. The issue of whether or not to create .txt and/or .llsd logs is being tracked separately: https://jira.secondlife.com/browse/VWR-22940 Please don't add comments to that issue that amount to just agreeing with or disagreeing with one or another of the points already made there (this list is an ok place for that, if you feel you must do it somewhere). The Jira tracker isn't a forum, and comments like that don't add much value. The various points of view are pretty well represented there now. This issue won't be dropped... watch this thread and the issue for updates. ___ 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] Project-MESH viewer
Are you planning to enable shine on prims with lighting/shadows on or is full lighting effects disable shininess something we need to accept as permanent and texture around? (Note that lighting in Kirstens also disables shine) From: Oz Linden (Scott Lawrence) o...@lindenlab.com To: opensource-dev@lists.secondlife.com Sent: Sat, October 16, 2010 11:01:38 AM Subject: Re: [opensource-dev] Project-MESH viewer On 2010-10-15 18:00, Trilo Byte wrote: But on the flipside, the Project MESH viewer has working shadows for nVidia GPU's on Mac (never happened before on any known config), and anti-aliasing's fixed. If we could get that bit out of the mesh viewer and into the 2.2 pipeline, we'd really be in great shape IMO. The AA fix is in the 2.2 pipeline (I did that merge) ... not sure about the other (since I don't know which change that was). ___ 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] Project-MESH viewer
Shiny does work with the deferred renderer (or Lighting and Shadows as it's now called in the Mesh viewer). It's simply handled differently; it reflects light in the form of what's known as specular reflectance, instead of reflecting the sky environment (at one point it reflected both around 2008 and 2009). Different shiny settings effects the overall brightness and distribution of the specular exponent. On Sat, Oct 16, 2010 at 11:24 AM, Ann Otoole missannoto...@yahoo.comwrote: Are you planning to enable shine on prims with lighting/shadows on or is full lighting effects disable shininess something we need to accept as permanent and texture around? (Note that lighting in Kirstens also disables shine) -- *From:* Oz Linden (Scott Lawrence) o...@lindenlab.com *To:* opensource-dev@lists.secondlife.com *Sent:* Sat, October 16, 2010 11:01:38 AM *Subject:* Re: [opensource-dev] Project-MESH viewer On 2010-10-15 18:00, Trilo Byte wrote: But on the flipside, the Project MESH viewer has working shadows for nVidia GPU's on Mac (never happened before on any known config), and anti-aliasing's fixed. If we could get that bit out of the mesh viewer and into the 2.2 pipeline, we'd really be in great shape IMO. The AA fix is in the 2.2 pipeline (I did that merge) ... not sure about the other (since I don't know which change that was). ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] O.O Display name code DROP!
On 2010-10-15, at 16:36, Ricky wrote: All that's needed is a linked XSL stylesheet to make it just as easy to read as the text files were. 1. It's not in XML, it's in notation format. This is a good thing, because... 2. LLSD is really badly designed from the point of XSL transformations. Instead of having the type and value as attributes, they have them in completely separate tags, so the ordering of tags matters so you have to use streaming XSLT. 3. There are more tools people use for browsing and reading log files than text editors. If you can't grep it, for example, it's junk. ___ 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] Project-MESH viewer
There is no shine at all when lighting/shadows is enabled. Sorry. None whatsoever. Full shine black is just flat black. Full shine white is just flat white. Full shine textures are just the textures. It is completely broken. And this, in turn, breaks content that was sold with the expectation it was shiny. On the bright side it might make people rely less on shine to hide things that cannot be textured properly (sculpts generated from a wad of prims) or to cover a lack of decent texturing. I'm already discontinuing use of shine as much as possible because of this content breaker. And yes we will need the other aspects of texturing for mesh as soon as possible if possible. Wet looking skin with bulging veins on Cthu'lhu would indeed be awesome. But shine was broken once with windlight. Now it has been obliterated with deferred rendering. I don't expect to live long enough to see real time true reflectivity in Second Life. Like latex that actually reflects. Would be nice but there are miles and miles to go to get that gpu capability for real time translated to opengl and then farther to go to show up in Second life. Or third life or whatever this concept is called at that point 50 years from now if there is still an internet (doubtful) and civilians are allowed to be in possession of computers beyond what they are chipped with. From: Geenz Spad ge...@geenzo.com To: opensource-dev@lists.secondlife.com Sent: Sat, October 16, 2010 12:41:48 PM Subject: Re: [opensource-dev] Project-MESH viewer Shiny does work with the deferred renderer (or Lighting and Shadows as it's now called in the Mesh viewer). It's simply handled differently; it reflects light in the form of what's known as specular reflectance, instead of reflecting the sky environment (at one point it reflected both around 2008 and 2009). Different shiny settings effects the overall brightness and distribution of the specular exponent. On Sat, Oct 16, 2010 at 11:24 AM, Ann Otoole missannoto...@yahoo.com wrote: Are you planning to enable shine on prims with lighting/shadows on or is full lighting effects disable shininess something we need to accept as permanent and texture around? (Note that lighting in Kirstens also disables shine) From: Oz Linden (Scott Lawrence) o...@lindenlab.com To: opensource-dev@lists.secondlife.com Sent: Sat, October 16, 2010 11:01:38 AM Subject: Re: [opensource-dev] Project-MESH viewer On 2010-10-15 18:00, Trilo Byte wrote: But on the flipside, the Project MESH viewer has working shadows for nVidia GPU's on Mac (never happened before on any known config), and anti-aliasing's fixed. If we could get that bit out of the mesh viewer and into the 2.2 pipeline, we'd really be in great shape IMO. The AA fix is in the 2.2 pipeline (I did that merge) ... not sure about the other (since I don't know which change that was). ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] What is the expected behaviour when double clicking floater edges? (VWR-23452)
Oh, wow, that's cool. Never knew that too. - Nexii On Sat, Oct 16, 2010 at 12:11 PM, Boroondas Gupte slli...@boroon.dasgupta.ch wrote: Personally, I didn't expect double clicking the edges or corners of a resizeable floater to do anything at all, so I didn't do it until it happened to me yesterday by accident. I was surprised to see the floater change size and figured I must have been moving the mouse, thus dragging the edge. But when trying again, noticed this also happened when the mouse pointer wasn't moving at all, so I filed bug VWR-23452https://jira.secondlife.com/browse/VWR-23452 . Further investigation revealed that the double clicked edge became aligned to the edges of other floaters or the edge of the Second Life window. While unexpected to me, this might be useful for arranging floaters and doesn't look like a bug but rather like a deliberately coded feature. Is it? I didn't know about this yet, but it looks like this was already present in 1.23. Cheers, 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 ___ 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] Project-MESH viewer
On Sat, Oct 16, 2010 at 12:27 PM, Ann Otoole missannoto...@yahoo.com wrote: There is no shine at all when lighting/shadows is enabled. Sorry. None whatsoever. Full shine black is just flat black. Full shine white is just flat white. Full shine textures are just the textures. It is completely broken. And this, in turn, breaks content that was sold with the expectation it was shiny. Shiny enables specular highlights, not reflections. Physically the two are the same thing, but in raster based graphics they are separate. That weird metallic colored blob we had before was just a quick and dirt hack, with lighting shadows enabled the viewer will do true specular highlights which depend on the angle of the light and the camera in order to be visible. I don't expect to live long enough to see real time true reflectivity in Second Life. Like latex that actually reflects. Would be nice but there are miles and miles to go to get that gpu capability for real time translated to opengl and then farther to go to show up in Second life. Or third life or whatever this concept is called at that point 50 years from now if there is still an internet (doubtful) and civilians are allowed to be in possession of computers beyond what they are chipped with. OpenGL has been able to do reflections for a long time now, it's just a very demanding process since you have to render the scene from the point of view of each reflective object in addition to the camera's view point. Older games would cheat and just render one cube map for the whole scene and use it for all reflections, but that may not be acceptable in sl. Once again, the dynamic, user made content in sl is what holds us back. There is no way to limit the number of reflective objects in view and using more then a hand full would bring all but the current top of the line cards to their knees. What we need is fine grain control over how objects are rendered instead of just everything in the view plain been drawn in full (LOD'd) detail. The shadow maps GI code does this with a distance based cut off. Having a distance / size cut off for reflections would help a lot with any over use of them. Adding in full impostors for all objects would be even better. Over all I'd say the viewer needs to start doing some serious resource management if we ever want to have a draw distance measured in kilometers. ___ 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
Why is it 2.0 seems to autodecline inventory for most people if they crash or get logged out before they can accept the inventory? this is really annoying. is there a way to change that somewhere? Im sick of throwing away money and losing gifts because stuff doesn't get delivered. ___ 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] Reflections in SL. Re: Project-MESH viewer
On 2010-10-16, at 16:58, leliel wrote: OpenGL has been able to do reflections for a long time now, it's just a very demanding process since you have to render the scene from the point of view of each reflective object in addition to the camera's view point. Older games would cheat and just render one cube map for the whole scene and use it for all reflections, but that may not be acceptable in sl. Sure it is. They had it working on First Look 1.13.57575. The source code for which is in the old viewer archives. It was nerfed some (the cube map was reduced to about 32x32) but the RenderDynamicReflections option was still there right up to Windlight. People LOVED it, particularly in rave-style clubs. ___ 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] Reflections in SL. Re: Project-MESH viewer
I'd be quite content with mirror surfaces that only, for example, reflected avatars. I think people would enjoy mirrors no matter how much restriction had to be placed on them to keep them from hogging excess resources. On Sat, Oct 16, 2010 at 5:27 PM, Argent Stonecutter secret.arg...@gmail.com wrote: On 2010-10-16, at 16:58, leliel wrote: OpenGL has been able to do reflections for a long time now, it's just a very demanding process since you have to render the scene from the point of view of each reflective object in addition to the camera's view point. Older games would cheat and just render one cube map for the whole scene and use it for all reflections, but that may not be acceptable in sl. Sure it is. They had it working on First Look 1.13.57575. The source code for which is in the old viewer archives. It was nerfed some (the cube map was reduced to about 32x32) but the RenderDynamicReflections option was still there right up to Windlight. People LOVED it, particularly in rave-style clubs. ___ 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 -- v i r t u a l w o r l d e n t h u s i a s t -- http://www.google.com/profiles/s u e z a n n e -- ___ 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] Reflections in SL. Re: Project-MESH viewer
On 2010-10-16, at 17:31, SuezanneC Baskerville wrote: I'd be quite content with mirror surfaces that only, for example, reflected avatars. They had a lot better than that... http://www.sluniverse.com/pics/pic.aspx?id=139865 ___ 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] Reflections in SL. Re: Project-MESH viewer
On 2010-10-16 19:04, leliel wrote: On Sat, Oct 16, 2010 at 3:31 PM, SuezanneC Baskerville sueza...@gmail.com wrote: I'd be quite content with mirror surfaces that only, for example, reflected avatars. I think people would enjoy mirrors no matter how much restriction had to be placed on them to keep them from hogging excess resources. I suppose low quality reflections are better then nothing. But I think LL has their hands full with other things at the moment. If we want them we'll have to code them up ourselves. Now there's a sentiment I can get behind ! :-) ___ 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] Reflections in SL. Re: Project-MESH viewer
Now, wouldn't the vampire folks be delighted with a mirror that had a don't reflect my avatar option ... -- Jay Reynolds Freeman - jay_reynolds_free...@mac.com http://web.mac.com/jay_reynolds_freeman (personal web site) On Oct 16, 2010, at 4:45 PM, Oz Linden (Scott Lawrence) wrote: On 2010-10-16 19:04, leliel wrote: On Sat, Oct 16, 2010 at 3:31 PM, SuezanneC Baskerville sueza...@gmail.com wrote: I'd be quite content with mirror surfaces that only, for example, reflected avatars. I think people would enjoy mirrors no matter how much restriction had to be placed on them to keep them from hogging excess resources. I suppose low quality reflections are better then nothing. But I think LL has their hands full with other things at the moment. If we want them we'll have to code them up ourselves. Now there's a sentiment I can get behind ! :-) ___ 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] Project-MESH viewer
Case in point... http://www.flickr.com/photos/50275...@n04/5079086973/ The floors have Shiny set to medium. leliel wrote: On Sat, Oct 16, 2010 at 12:27 PM, Ann Otoolemissannoto...@yahoo.com wrote: There is no shine at all when lighting/shadows is enabled. Sorry. None whatsoever. Full shine black is just flat black. Full shine white is just flat white. Full shine textures are just the textures. It is completely broken. And this, in turn, breaks content that was sold with the expectation it was shiny. Shiny enables specular highlights, not reflections. Physically the two are the same thing, but in raster based graphics they are separate. That weird metallic colored blob we had before was just a quick and dirt hack, with lighting shadows enabled the viewer will do true specular highlights which depend on the angle of the light and the camera in order to be visible. I don't expect to live long enough to see real time true reflectivity in Second Life. Like latex that actually reflects. Would be nice but there are miles and miles to go to get that gpu capability for real time translated to opengl and then farther to go to show up in Second life. Or third life or whatever this concept is called at that point 50 years from now if there is still an internet (doubtful) and civilians are allowed to be in possession of computers beyond what they are chipped with. OpenGL has been able to do reflections for a long time now, it's just a very demanding process since you have to render the scene from the point of view of each reflective object in addition to the camera's view point. Older games would cheat and just render one cube map for the whole scene and use it for all reflections, but that may not be acceptable in sl. Once again, the dynamic, user made content in sl is what holds us back. There is no way to limit the number of reflective objects in view and using more then a hand full would bring all but the current top of the line cards to their knees. What we need is fine grain control over how objects are rendered instead of just everything in the view plain been drawn in full (LOD'd) detail. The shadow maps GI code does this with a distance based cut off. Having a distance / size cut off for reflections would help a lot with any over use of them. Adding in full impostors for all objects would be even better. Over all I'd say the viewer needs to start doing some serious resource management if we ever want to have a draw distance measured in kilometers. ___ 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] Project-MESH viewer
“Or third life orwhatever this concept is called at that point 50 years from now if there isstill an internet (doubtful) and civilians are allowed to be in possessionof computers beyond what they are chipped with.” We have to all stand together for our rights of free speech, creativity and don’t let them implant you chips then we all should be fine in 50 years from now. Just think about it there a general awakening that is happening, people start to realize that the gov has too much power, we just need to take it back. From: Jonathan Goodman Sent: Saturday, October 16, 2010 10:49 PM To: opensource-dev@lists.secondlife.com Subject: Re: [opensource-dev] Project-MESH viewer Case in point... http://www.flickr.com/photos/50275...@n04/5079086973/ The floors have Shiny set to medium. leliel wrote: On Sat, Oct 16, 2010 at 12:27 PM, Ann Otoole mailto:missannoto...@yahoo.com wrote: There is no shine at all when lighting/shadows is enabled. Sorry. None whatsoever. Full shine black is just flat black. Full shine white is just flat white. Full shine textures are just the textures. It is completely broken. And this, in turn, breaks content that was sold with the expectation it was shiny. Shiny enables specular highlights, not reflections. Physically the two are the same thing, but in raster based graphics they are separate. That weird metallic colored blob we had before was just a quick and dirt hack, with lighting shadows enabled the viewer will do true specular highlights which depend on the angle of the light and the camera in order to be visible. I don't expect to live long enough to see real time true reflectivity in Second Life. Like latex that actually reflects. Would be nice but there are miles and miles to go to get that gpu capability for real time translated to opengl and then farther to go to show up in Second life. Or third life or whatever this concept is called at that point 50 years from now if there is still an internet (doubtful) and civilians are allowed to be in possession of computers beyond what they are chipped with. OpenGL has been able to do reflections for a long time now, it's just a very demanding process since you have to render the scene from the point of view of each reflective object in addition to the camera's view point. Older games would cheat and just render one cube map for the whole scene and use it for all reflections, but that may not be acceptable in sl. Once again, the dynamic, user made content in sl is what holds us back. There is no way to limit the number of reflective objects in view and using more then a hand full would bring all but the current top of the line cards to their knees. What we need is fine grain control over how objects are rendered instead of just everything in the view plain been drawn in full (LOD'd) detail. The shadow maps GI code does this with a distance based cut off. Having a distance / size cut off for reflections would help a lot with any over use of them. Adding in full impostors for all objects would be even better. Over all I'd say the viewer needs to start doing some serious resource management if we ever want to have a draw distance measured in kilometers. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Reflections in SL. Re: Project-MESH viewer
On 17/10/2010 10:45 AM, Oz Linden (Scott Lawrence) wrote: On 2010-10-16 19:04, leliel wrote: On Sat, Oct 16, 2010 at 3:31 PM, SuezanneC Baskerville sueza...@gmail.com wrote: I'd be quite content with mirror surfaces that only, for example, reflected avatars. I think people would enjoy mirrors no matter how much restriction had to be placed on them to keep them from hogging excess resources. I suppose low quality reflections are better then nothing. But I think LL has their hands full with other things at the moment. If we want them we'll have to code them up ourselves. Now there's a sentiment I can get behind ! :-) A year or two ago, I was treated to a demonstration of working mirrors in SL. It was an override of Shiny, and I had to install a custom shader file to my SL viewer installation directory. As far as I know, the project died because - in order to work - it needs a bit or a texture property flag from Linden lab on the server-side, otherwise it is surprising or unexpected functionality that potentially breaks content, and thus is a no-no under the TPVP. -- Tateru Nino http://dwellonit.taterunino.net/ ___ 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
