Re: [opensource-dev] Version Numbering
On Thu, Aug 11, 2011 at 12:43 PM, Kadah kadah.c...@gmail.com wrote: (4) Deferred render pipeline with projected lighting Was mostly there in 2.7. Deferred rendering has been around since the 1.20 viewer, projected lights were added in 2.0. The only thing 2.7 did was put the options in the preferences floater. ___ 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] Media plugin is completely broken on Linux in the Autobuild branch
Commit 284e995627ed on viewer-autobuild2010 reverted the linux libqtwebkit to version 4.6 which has completely broken everything, even the side bar doesn't work. ___ 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] Linux build without the pausing behaviour
On Mon, Mar 28, 2011 at 7:50 AM, Francesco Rabbi syt...@gmail.com wrote: Il giorno 28/mar/2011, alle ore 16:41, Mike Chase mike.ch...@alternatemetaverse.com ha scritto: Is there a Linux build of V2 of any version that doesnt exhibit the annoying multi-second pauses that freeze the UI? I find myself without any useable V2 viewer at present. I've tried 2.5.2 and 2.6.3 and both still have this issue. http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/viewer-autobuild2010/latest.html How in the world did this every get past QA? It really renders the viewer unusable. I've been using Imprudence the last few days which is nice but a huge shift in UI and I've actually gotten both used to and productive with the V2 paradigm. I've been wondering that myself. Can you explain better the kind of pause? I don't notice sort of... STORM-809 ___ 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] Linux build without the pausing behaviour
On Mon, Mar 28, 2011 at 8:59 AM, Opensource Obscure opensourceobsc...@gmail.com wrote: QA department apart, I / we should have done more testing. I think I remember I had seen this, but I didn't bother to properly investigate it / compare to other releases / file a report. It was first reported on December 22, the same day the bug was introduced. And was subsequently acknowledged by several Lindens in late December and early January. Yet the bug still made it through 3 releases and counting. I don't think we as a community are the ones that dropped the ball 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] Linux build without the pausing behaviour
On Mon, Mar 28, 2011 at 9:16 AM, Mike Chase mike.ch...@alternatemetaverse.com wrote: On 03/28/2011 10:53 AM, leliel wrote: On Mon, Mar 28, 2011 at 7:50 AM, Francesco Rabbisyt...@gmail.com wrote: Il giorno 28/mar/2011, alle ore 16:41, Mike Chase mike.ch...@alternatemetaverse.com ha scritto: Is there a Linux build of V2 of any version that doesnt exhibit the annoying multi-second pauses that freeze the UI? I find myself without any useable V2 viewer at present. I've tried 2.5.2 and 2.6.3 and both still have this issue. http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/viewer-autobuild2010/latest.html Is this a special build with the fix? I hjave 2.6.3 which still exhibits the problem. And yes I'd agree with others. I've seen this problem reported for quite some time yet no fix seems to make it into the released builds. It's the autobuild development branch which has several updated libs including a fixed libcurl. ___ 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] Slowdowns with Viewer 2.5.x for Linux (getting too many data?)
If the viewer freezes for a few seconds ever time it loads a texture then it's probably STORM-809. ___ 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] (CTS-315) march choice for 64bit builds
On Sat, Oct 23, 2010 at 3:08 AM, Altair Sythos syt...@gmail.com wrote: On Sat, 23 Oct 2010 03:08:26 +0200 Boroondas Gupte slli...@boroon.dasgupta.ch wrote: Because SSE2 is now required anyway, -march=pentium4 is now passed for building lindenlab/mesh-development. Of course, this doesn't work for 64bit builds. (See CTS-315 https://jira.secondlife.com/browse/CTS-315.) What should march be set to for 64bit buids, if anything? pentium4 don't support 64bit, but nocona yes nocona also enables sse3 which would cut out many k8 cpus. the other (imho better) way to select right march/mtune is use generic and declare *all* parameters, sort of: This is the proper fix imho. for 32bit: gcc -march=generic -mtune=generic -m32 -mmmx -msse -msse2 -mfpmath=both etc.etc. for 64bit: gcc -march=generic -mtune=generic -m64 -mmmx -msse -msse2 -mfpmath=both etc.etc. Should use -mfpmath=sse, gcc isn't very good at doing both x87 and sse fp math at the same time. ___ 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] (CTS-315) march choice for 64bit builds
On Sat, Oct 23, 2010 at 3:44 AM, Altair Sythos syt...@gmail.com wrote: On Sat, 23 Oct 2010 03:19:24 -0700 leliel leliel.mir...@gmail.com wrote: the other (imho better) way to select right march/mtune is use generic and declare *all* parameters, sort of: This is the proper fix imho. for 32bit: gcc -march=generic -mtune=generic -m32 -mmmx -msse -msse2 -mfpmath=both etc.etc. for 64bit: gcc -march=generic -mtune=generic -m64 -mmmx -msse -msse2 -mfpmath=both etc.etc. Should use -mfpmath=sse, gcc isn't very good at doing both x87 and sse fp math at the same time. let GCC to choose the faster way to assembly machine code... (done under GCC4.5 a lot of test in KV enviroment, but on intel up) SSE2 is faster, mfpmath=both tells gcc to use x87 SSE at the same time which is not an easy task given how they work completely different. And it may not even give any speed up, many CPUs share execution hardware between x87 SSE. is time for a libs update too, especially on multimedia (opeonal, pulse, SSL0.9.7 is buged, etc.etc.), as change compilefarm upgrading GCC (mainly now, mesh need high performance compilated code) The first step towards that is to stop using the archaic and down right weird x87 ABI. ___ 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] (CTS-315) march choice for 64bit builds
On Fri, Oct 22, 2010 at 6:08 PM, Boroondas Gupte slli...@boroon.dasgupta.ch wrote: Because SSE2 is now required anyway, -march=pentium4 is now passed for building lindenlab/mesh-development. Of course, this doesn't work for 64bit builds. (See CTS-315.) What should march be set to for 64bit buids, if anything? It should be using -mtune not -march. Unfortunately the original k8 cpus didn't support sse3 so pentium4 is still the best cpu type to use on a 64bit build. ___ 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
Re: [opensource-dev] O.O Display name code DROP!
On Fri, Oct 15, 2010 at 2:04 AM, Lance Corrimal
lance.corri...@eregion.de wrote:
Am Freitag, 15. Oktober 2010, 10:00:44 schrieb Rob Nelson:
So basically, LL decided to go from simply changing the formatting of
their logs to (if what I am hearing is correct), of all things, LLSD XML
notation, possibly the worst formatting of log possible?
Has ANYONE over there at LL looked at the sheer amount of overhead LLSD
produces? We'll have log folders that are larger in size than our cache
folders.
My log folder is a whopping 35MB after almost 4 years. LLSD would have
to be very inefficient in order for my log directory to over take the
cache directory within the next decade.
[{TIME}] {DISPLAY NAME} ({REAL.NAME}) says: {STUFF} would have been
MORE than sufficient for logging purposes.
what about sticking to the old format (i.e. without the says unless its a
shout or a whisper)?
[{TIME}] {DISPLAYNAME} ({LOGINNAME}): {STUFF}
as it used to be..?
I'll play devil's advocate and say llsd isn't that far off from this.
It's definitely more verbose, but the main difference is the UUID
instead of LOGNAME. Here's an actual line from my log file.
{'from':'\xe7\xa4\xbc\xe5\xad\x90','from_id':udba66655-e06a-47d9-a241-f055b85041ef,'message':':o','source_type':i1,'time':'2010/08/31
17:38'}
___
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 Fri, Oct 15, 2010 at 4:38 AM, Carlo Wood ca...@alinoe.com wrote: I was hoping that log files are updated very frequently, so that if I crash I don't lose text. But writing several megabytes to disk every line of chat seems unfeasible. It's 115 bytes + display name + message per line. Just where are these several megabytes coming from? ___ 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 Fri, Oct 15, 2010 at 4:53 AM, Stickman stick...@gmail.com wrote: It's 115 bytes + display name + message per line. Just where are these several megabytes coming from? Lack of append in LLSD. Sounds a bit extreme to me. The latest Snowstorm build had no trouble appending to the chat.llsd file the Display Names project viewer created two months back, it even showed the last 8 lines when I logged in. I prefer Opensource's line of thinking, where this is simply some sort of oversight that can be repaired. The Display Names project viewer has been using this format for months, I doubt it's an over sight. The current format is missing important information, such as the username and display name, and only contains their UUID, which is less than ideal for a chat log to contain. It does have the display name, you can see it in the line I posted above. It looks like gibberish because I was using a Unicode name at the time. ___ 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 Fri, Oct 15, 2010 at 6:57 AM, Daniel danielravenn...@gmail.com wrote: Apparently you don't chat much, mine is ten times larger over the same period. I only logged IMs for two years. So my chat.txt file is 15409876 bytes and 265570 lines which gives me an average message size of 58 bytes. The 115 bytes for llsd would be ~66% over head per line which is a bit excessive (that's sarcasm). Just to be clear I think this is a stupid change. I'm arguing for it because so many people were screaming the sky was falling without backing it up with hard numbers or even a user story, which has now been provided. ___ 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] Local Lights
On Tue, Oct 12, 2010 at 10:21 PM, Ann Otoole missannoto...@yahoo.com wrote: When is the last time anyone checked on local lights. I recall that 7 limit was removed a ways back and then during a discussion people were still saying there was a limit of 7. So I decided to test it. The limit was never raised. The OpenGL fixed function pipleline only supports a maximum of 8 light sources, this has been true for the last 20 years. In the SLv2 Beta only 2 local lights worked at all. That's a bug, there's a jira entry for it somewhere. Any reason why the capabilities of the LL viewer keep being ratcheted down? This isn't a fare comparison. Kirsten's viewer has deferred rendering enabled by default, which lets it render an effectively infinite number of light sources. The official viewer still uses the fixed function lights since the deferred rendering code isn't quite production ready. If you test again with them both using either deferred or fixed function lighting they will behave the same. ___ 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
On Sun, Oct 3, 2010 at 10:37 AM, Ponzu lee.po...@gmail.com 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 the Too Many Open Files problem
I have exactly the same problem, except I'm using linux and my ulimit is 1024. When I have http-textures enabled and I teleport the open files hover around 850-950 with the viewer intermittently running out of file descriptors. This causes about 1/3 of the http connections to time out, presumably waiting for a free file descriptor, after this happens for 30 seconds or so the cache system will get confused and clear the whole cache, often 2 or 3 times per teleport. Eventually the viewer will give up on the textures leaving 1/3 of the world gray. As you might imagine, this makes http-textures completely unusable for me. Occasionally the viewer will run out of file descriptors for too long and crash, I had this happen to me once when some one IM'd me and the viewer couldn't open the log file. ___ 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] J2C fast decoder
On Sun, Sep 12, 2010 at 10:40 PM, Tateru Nino tat...@taterunino.net wrote: If we're using HTTP textures, is there actually any need for the JPEG 2000 format? There is the 500TB asset server full of jpeg2k images. Switching to a new format would be a massive undertaking. Would it be a huge problem, for example, to transfer HTTP textures as TGA or PNG and use one of the rather well-optimized decoder libraries for those instead? TGA is uncompressed so it won't work. PNG could work, but its compression ratio and file overhead isn't that much better than jpeg2k. So the gains would only be in decode time, which is the biggest cpu drain in the viewer so it may be worth it. ___ 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] J2C fast decoder
On Mon, Sep 13, 2010 at 12:24 AM, Tateru Nino tat...@taterunino.net wrote: Wouldn't we be making a network saving by omitting the discard levels entirely? Granted, I don't have hard data about that - would the base texture encoded in a lighter-weight format end up causing less data to traverse for a given texture in the long-run than the more-efficiently compressed j2c of the same texture including discard levels? My gut instinct says 'probably', but I can't prove that with data. If it *does* then we would have a double-bonus of also saving on decoding time. The problem is that discard levels save us on more then just bandwidth. when you look at an object 300m away it will only be taking up a few dozen pixels on the screen so the viewer will just download up to the first or second discard level, say 32x32 or so, and that is all that will be stored on your video card. Switching to a format that doesn't support discard levels could give us big savings in decode time, but at the cost of having to always download the whole file. We'd be trading cpu time for vram, and the average users machine has a lot more of the former than the later ___ 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] 1-bit alpha textures
On Sun, Sep 12, 2010 at 1:13 AM, Stickman stick...@gmail.com wrote: I was referring to what's mentioned in this Jira, actually: http://jira.secondlife.com/browse/VWR-6713 That issue is unresolved. I'm not seeing any promises in the comments, but I could have sworn it was supposed to be in viewer 2 somewhere. Anyone have information about what was planned for it that isn't in the Jira? The viewer has had an option for many years now to force all alpha channels down to 1 bit. This fixes most all the alpha sorting problems but it also breaks content (mostly hair and particles). Viewer 1 Advanced - Render - Fast Alpha Viewer 2-2.1 Develop - Render - Fast Alpha Snowglobe 2.1 viewer-development - Develop - Render - Automatic Alpha Masking (with separate options for deferred and non deferred) ___ 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] Retaining Newbies (Was: The Plan for Snowglobe)
On Sun, Sep 12, 2010 at 9:01 AM, Lance Corrimal lance.corri...@eregion.de wrote: Am Sonntag 12 September 2010 schrieb Altair Sythos Memo: 1.) My computer can't handle it. (This is, by far, the #1 reason people leave SL after trying it, I'm convinced. Maybe as high as 90%!) this point have no viewer side solutions :) actually it has... do not add more shinies that raise the hardware requirements even higher... Most of these people have machines that don't even support the shinies so that what does it matter if we add them? And adding support for shinies such as volumetric lighting would get rid of those ugly semi transparent cones around lights and speed things up for people on low end machines that have it disabled. See, it's a win win situation, I get my shinies and they get better performace. ___ 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] Code Review Request: VWR-21253 (Permissions icons in the friends list)
On Mon, Sep 6, 2010 at 10:37 AM, Marine Kelley marinekel...@gmail.com wrote: Err... color me stupid but... how does one show the friends list in this style on viewer 2 ? I can detach tabs from the sidebar, but I cannot find a way to show the permissions matrix. It would be so handy ! Hover the mouse over their name in the friends list and it will show the permission icons. Works fine for me on Linux. Looks like it uses the 1.23 icons which don't fit in with the theme on 2.x tho. ___ 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] This is how Linden Lab treats it's customers...
On Sun, Aug 29, 2010 at 4:25 AM, Argent Stonecutter secret.arg...@gmail.com wrote: What if the account doesn't own land, or has nothing but the original 512 square meters in something like a Linden Home? That's the majority case. An account in that situation is not *in default* when they skip a payment, because the account payment itself is not made in arrears. So you're saying a person that doesn't pay their membership fees should be able to log in and use their 512 square meters of land as if nothing was wrong? How long should this persist before they are considered in arrears? A week, a month, a year? Membership fees are paid in advanced, if you don't pay than you can't use the service (512m^2). If you don't own land you should be downgraded to basic. ___ 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] Anti-Aliasing
On Fri, Aug 27, 2010 at 12:02 AM, Marine Kelley marinekel...@gmail.com wrote: Actually it works, but I believe the RenderUseFBO and RenderDeferred debug settings must be set right (both FALSE), before seeing some antialiasing. I'm not really sure how I did it but I did see some AA on the latest 2.x viewers. AA works just fine for me with deferred rendering enabled. I don't even have to relog for the setting to take effect. This is with 208581 on linux. ___ 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] Draw Distance
On Sat, Aug 21, 2010 at 9:36 PM, Miro Collas miro.col...@gmail.com wrote: How about bbeing able to just type it in? Why a slider, or mouse wheel, which is inaccurate? How about being able to type it in chat? Instead of a one off thing just for the draw distance, I'd rather we had a general command input system similar to the console on id's games. So since we use /# for the channel and /me for emotes how about /set for setting debug variables with the following syntax. /set debugvar value Where value is one of bool, integer, float, or a vector using the lsl style of 0.0, 0.0, 0.0. With tab line completion of course. ___ 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] Draw Distance
On Sun, Aug 22, 2010 at 12:09 AM, Miro Collas miro.col...@gmail.com wrote: That's what I referring to, the command line commands. VERY handy! And dd is one I use a great deal. The problem I have with that is that the draw distance is only one of several debug settings that affect performance. I've been running with deferred rendering enabled for the past few months and I've had to enable/disable shadow maps SSAO all the time, but I hardly ever touch the draw distance. What's more, using a general method of changing debug settings through chat would let us create gestures that changed a whole group of settings all at the same time. So when entering a laggy sim you could trigger one gesture that did all of this. /set RenderFarClip 128 /set RenderVolumeLODFactor 2.0 /set WindLightUseAtmosShaders 0 With a system like this you could change any setting on the fly without ever having to open the UI which would be great for filming machinima. Cam into a building and turn on global illumination and crank up the SSAO settings for deep highlights, cam back out and put SSAO back to the defaults and turn off GI for a better frame rate. ___ 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] Draw Distance
On Sun, Aug 22, 2010 at 2:36 AM, Robin Cornelius robin.cornel...@gmail.com wrote: Thats a powerful idea, is there a new feature JIRA for this on the LL pJIRA currenty? if not could I kindly ask you to create one for it and post the issue number back here. http://jira.secondlife.com/browse/VWR-20887 The problem comes is its not just a case of updating the gSavedSettings with new values (which would be very easy to do in the way you have described). Many of the settings need applying in some way to push the correct values to the correct place, many of the debug settings would just work but some would not and thats where the work for this feature would start, but i do like where you are comming from with this. One thing I'd like to happen before this feature is implemented is to clean up the debug settings name space. There are too many settings with random, nonsensical names. I suppose we could copy id and put everything having to do with rendering under r_ and everything for the UI under ui_ and so on. ___ 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] RenderVolumeLODfactor (branch from Draw Distance)
On Sun, Aug 22, 2010 at 7:48 AM, Trilo Byte trilobyte5...@gmail.com wrote: Actually, it would be nice if RenderVolumeLODfactor could either persist from one version to the next (instead of getting reset with everey new version installation), or be set based on GPU detection. Put it in the settings_per_account.xml file. I imagine the default of 1.125 is based on class 0 (intel integrated graphics) but anybody using better than that can go to 2.0 at a bare minimum. More powerful GPU's can easily handle 4.0, and from my experience the ATI 4xxx series and above/nVidia 9xxx series and above can do 6.0. The default for class 1 and up is 2.0. On a side note, I've found that setting above 6.0 can have unexpected and unwanted results, most notably 'disappearing prims' with smaller sculpts (necklace chains, etc). That's because you're running into RenderMaxNodeSize. Having to manually jump into debug settings with every viewer release is a pain. If it could be auto-detected, that would save a lot of novice users from having to mess around in the Advanced/Debug menu I'll counter that by saying people shouldn't be making jewelery with 500,000 vertices. We need mesh uploads, if only so people can make necklaces that don't have more geometry data than half a sim. ___ 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
