Development Update December 7, 2005

There are several points to discuss this week. Here's a summary:

1. Downtime, December 6, 2005

The downtime on December 6, 2005 was successful. Our Operations department did a great job reorganizing our core servers and network hardware to prepare for future growth!

Because of the potential problems during the downtime, we chose not to deploy new server or client side code at that time.

2. Second Life 1.8.0 Preview!

Second Life 1.8.0, now in preview, will introduce two new features: point-to-point teleport and ripple water. Please visit http://secondlife.com/preview/ for details and join us in testing 1.8.0!

3. We are working on bug fixes that will go into 1.8.0. The list so far includes:

-- Objects are no longer momentarily visible at <0,0,0> before moving to their correct position
-- Resolved a crash that occurred after declining an offer of inventory
-- Fixed a crash when dragging texture onto base terrain swatch in Region/Estate tools

Check out the latest release notes for more information!

Also in the works are resolutions for:

-- A *second* sit target bug (more rare than the one fixed in 1.7.4.7, but still happening)
-- An issue where opening the Finder would cause Second Life to slow down (on all sorts of machines, it's been pointed out).

4. Issues that are under investigation

We have ongoing investigations into reports of texture loading problems. While things have improved greatly for most users, we know there are still issues and are working to resolve them as soon as we can!

Thank you for posting this. Do you know whether anyone is working on the "Scripts running absurdly slow in some simulators" or "Disk cache does not appear to work" bugs?

Is that why I notice a suddenly huge performance drop & my hard drive pings like crazy every so often? LoL

There is also a serious problem with avatar attachments causing EXTREME lag (like from 60fps to 5fps). I narrowed it down to one guy with ~300-prim hair (all twisted toruses/rings/tubes). I first thought it was listens, then particles, but now I'm pretty sure it's avatar attachments, but it might just be prim/polygon count/complexity...

This has been a problem for some time. The problem with such complex hair - 300 prims, twisted torii and such, is that on top of that, they apply a 32-bit alpha'd targa on top of it! The math required brings the viewer to a screeching half. Damn hoochie hair!

I'd like to see Hun's questions answered as well, in addition to an update on when the Time Dilation / sim fps bug will be quashed; I still see many sims that have 10 minutes per hour of un-usable time dilation.

Thanks for the updates - these are great, and the improved, regular communication is sincerely appreciated!

-Flip

I've had experiences with prim/poly-heavy hair before SL 1.7 and it didn't lag like it does now. Before, only the LOD rendering (polygon complexity relative to camera distance) would cause lag but now the lag is constant (but not LOD-related, that I can tell).

Any updates on the linux client? 1.7 is significantly slower than 1.6 with my FPS under windows emulation dropping from 7-10 FPS to 1-2 FPS on a GF6600! basically making SL unplayable for me.
I'm thinking of selling my land and dropping back to a basic account until I can actually play again.

How about giving attachments the same restrictions as vehicles... you can only attach to an attachment point if you have 31 or fewer prims? Unless they're in a HUD and so only slow down the guy doing the attachment...

This is comparatively minor, but I and others have been frustrated with moving attachments not working correctly. There seems to be a number of situations where llTargetOmega will simply not affect an attachment or the child prim of an attachment. I've also heard someone say that using llTargetOmega can sometimes break the functionality of the other movement functions as well, though I haven't tested this out myself. I've filed a few bug reports in Preview, but there's likely other related issues besides the ones I found.

Moving attachments are an awesome concept, if they can just be made reliable. I get the impression many folks haven't done more with them simply because they aren't.

The issue that I am having, and others have reported the same problem to me, is that for the last several updates, when in my house or at a club like say the edge, my sound feed refuses to stay on, at times it is so bad that i have to turnoff/on my music control every 20-30 seconds to keep it playing, and that can get irritating very fast, i am currently using s soundbaster audigy card on my machine. I would be so grateful if this could be fixed somehow.

I will personally off any one who dares implement this. pjk

The majority of attachments are in the vicinity of 35-80 prims and many of the firearms i make are in the 100-110 range.

Such a ludicrous limitation could cause mass hysteria, and SL would loose clients like its going out of style.

On the other hand I'm praying for proper H2 implementation so I may make my super cruiser. All I want is 512 vehicle prim linking with a 200m link distance limitation. O and a space sim layer added onto the current grid at a high altitude ;D

^ Yeah, in addition, I wouldn't be able to wear Eze's headphones either.

SL really just needs better polygon optimization. Hidden surface removal would be a good 1st step since SO many polygons are unnecessarily rendered that are covered up. LOD helps but not as much as what COULD be done...

In terms of that my goal for SL would be for a client on a 2.8HGZ machine with a Radeon 9700 Pro (arbitrarty componants, simply an object example for machine performance level) to be base to run a 256m visibility at roughly 50FPS with shiny and bump mapping on with an average of 6 visible other users. This alone would be a staggering improvement for the average user. As for users with higher performace modern machines, I shuold expect a full 512 visibility maintaining about 45-65 fps.

Every once in a while i will crank my vis un dampered to 512 and it reminds me of how nice SL could look if the client software could tolerate it. I understand that "everything is dynamic" in SL. But, seriously if you do processing on the basis that all non active (aka not containing script or being physical) objects are to be rendered as static geometry vs suddenly spring to life at any given momet, I hsould imagine there could be a huge bolster in graphical performance.

One thing that concerns me is that SL may be backed in to a corner in terms of what can be done iwth the current graphics engine and its litteraly an issue of just having ot wait til a 2.0 sized revision where an entire new engine could be implemented properly.

Have you noticed any difference with "Object-Object Occlusion" under the Debug menu in Rendering?

What in the name of all that's holy are you doing with all those prims? No wonder people take a minute and a half to rez at a telehub!

My mantra:textures should only be used where gemotrey simply cannot, preserveing the higest possible detail.

Either way, geometry uses less bandwith then say several 512x512 textures.

Yeh, but it's amazing what you can do with lower-density textures and still get great detail... without ending up with a gun you can't rez in-world in your own house!

SL is mostly CPU bound. That would have a negative impact.

Sometimes the cost of doing occlusion is greater than just rendering it all, also some perspective is needed here;

The average scene in Doom3 had around 60,000 polygons. Some people's hoochie hair can reach 300,000. It's a tragedy of the commons really.

Granted, people need to learn to build more efficiently, but there are still things SL could have that would improve framerate. Removing hidden surfaces (at least manually) would be a first step. There are so many covered prim sides (and, hence, wasted polygon rendering) it's ridiculous!

Yup, I reported that bug in 1.8 Preview. It isn't hardware-related...it's lag. Anybody who was around during early main grid releases of 1.4 probably remembers that in laggy sims it wasn't unheard of for sounds to play one hour after they were triggered...

Yes, the workaround is turn it off.

Yes! Yes!! YES!!!!

With a little imagination, you can create almost any look you want on a prim with just color, bump-map texturing, transparency, and light.

Wood textures?!? Stucco textures?!?

When will they ever learn???

please tell me ! lol. im interested in that!.. so can any one direct me to any tuts?...... etc?.

There's only the info in the Linden basic building tutorial. Maybe there's a faq in the Library of Prims?? You can use Find in-world to check that out. There's nothing in the Wiki, and don't seem to be any classes...but there is a class on Giant Snail Racing!

Seriously, there needs to be a class on decorating without textures, as well as one on low-prim building techniques. (I think Hank Ramos who used to teach a class on low-prim building.) Likely, most people aren't aware you can make realistic furniture like desks, tables, lamps, and decorative sculptures out of one prim, using no textures at all or one texture at the most. I used to design one-prim furniture which I sold out of a stall in the Boardman open market. Also used to have a Sculpture Garden in Natoma where everything was one-prim. The only stuff of that type I've ever displayed in my store (check my sig) is the Twisty Light (non-textured one-prim lamps), and some one-prim sculptures.

If I wasn't so freakin' busy I wouldn't mind teaching a class or writing something for the Wiki. But, the basic pseudo-texture techniques are pretty simple. Everything you need (Bump-map texturizing, Shine, Color, and Transparency) can be found on the Texture tab in the Build window, except for Light which is listed under Materials on the Object tab:

Woods simply use bump-map wood grain texturizing with appropriate colors...reddish-brown for cherry wood, darker brown for maple, brown for oak, yellowish-brown for pine, etc.

Likewise, stucco uses stucco texturizing with a beige or very light grey color.

Decorative glass panes use some degree of transparency and whatever colors you want.

Metals use a silver-grey color with some degree of shine.


Edited for correction as noted in next post.

Bumpmapping doesn't work with transparency.