Invisiprims, Why?

Why?

Why do designers use alpha layers and invisiprims in boots? Then to add insult to injury, the boots are no mod so you can't rip out the invisiprims.

Please stop doing this.

Shadows on Really Old Macs!

Shadows on a Mid-2007 iMac, a photo by Milla Janick on Flickr.

Shadows have finally hit the official Second Life viewer! Yay! But real time shadows come with some pretty steep hardware requirements. Many graphics adapters capable of displaying shadows simply aren't capable of doing it at a tolerable speed.

More good news is the Macintosh viewer finally gets shadows. If you have a fairly new Mac. If you have a brand new Mac, they look great and run fast. Older Macs (like last year's models) not so much. There are two graphics preferences requirements for shadows, atmospheric shaders and hardware skinning. The hardware skinning box has always been greyed out on Macs with HD2xxx series graphics adapters. However, with a little editing of the graphicstable_mac.txt file, you can enable it and get shadows on your HD2400 or 2600 equipped iMac! Huzzah!

Right click the SL app, and select show package contents. Open the Contents folder, then the Resources folder. Open the featuretable_mac.txt file in TextEdit. Towards the bottom of the file is the section labeled

"// Avatar hardware skinning causes
// invisible avatars on HD 2600... so I masked
// out other possible bad ones till it's fixed"

Remove the entry for your Mac's crappy graphics adapter, save it and start the viewer.

Go to Preferences, graphics, and select advanced. Hardware Skinning should be available now. Check it, and Lighting and Shadows becomes selectable (as long as Atmospheric Shaders is checked, too).

Yay shadows! At about 4fps, so it's probably not something you'll want to run all the time. It's nice to have for snapshots though.

Oh yeah, do this at your own risk. I didn't see any problems, but I didn't run it much, either. Linden Lab apparently disabled hardware skinning on these adapters for a reason. Maybe it's fixed and they just forgot to turn it back on. Maybe not.

Oh For Fuck's Sake.

https://jira.secondlife.com/browse/WEB-3494

Oh, hey I'm terribly concerned about my privacy. I think I'll post a picture of my junk in the Real Life tab in Second Life! What? Linden Lab is switching to web based profiles? So like people can see my junk now? Of noes!

Fucking retards.

Seriously, people who bitch about Linden Lab never improving anything, then screaming the sky is falling every time they do, just shut the fuck up

Benchmarking Viewer 2

Watching textures load
Originally uploaded by Milla Janick

Viewer 2 brought HTTP textures to the viewer, and presumably improved performance with it. Curious to see just how much better, I decided to run some texture benchmarks So here's the plan, start with a clear cache and time how long it takes a scene to load. The timing was started when the world became visible on login, and ended when the activity in the texture console stopped. I started running the tests at J Peace Island, home of The Mother Road. It's a very texture heavy region that's also fairly quite. It would give the rendering pipeline a workout and low chances of avatars dropping in on me and altering the results.

The results were interesting. With Viewer 2.1.1, UDP was actually faster, HTTP taking about two minutes to fully load the scene, UDP about a minute and a half. This appears to be resolved in the 2.2 Development viewer which renders textures incredibly quickly. 2.2 is by far the fastest viewer at loading and rendering textures.

Other questions arose while I was doing this. How does 1.23 stack up? Terribly. 2.1.1 and 2.2 are much faster on every system I tried them on, and the margin isn't even close. Even on older systems, Viewer 2's texture rezzing performance is much faster than any previous viewer.

The second question was llkdu vs. openjpeg. They're the bits that decode the jpeg2000 files Second Life uses for all its textures. Conventional wisdom is llkdu is faster. TPV developers and users have taken advantage of this by copying the llkdu file from an installation of the Linden Viewer to speed up rendering. Word is Linden Lab is going to crack down on this practice and prohibit TPVs from using llkdu. Let the wailing and gnashing of teeth commence! Linden Lab is trying to kill TPVs! It is the end of days!

Is it really? KirstenLee Cinquetti has released an llkdu free version of her viewer, and it's fast. Really fast. It's easy to compare llkdu and openjpeg performance simply by removing the llkdu file from the viewer's directory. On reasonably fast systems openjpeg renders just as fast as llkdu. Even on old, slow systems like my old Pentium 4 the difference is marginal with llkdu having an advantage of maybe 10%.

My conclusion? Newer is better. The 2.2 development viewer is incredibly fast at loading and rezzing textures, even on very old computers. This is great news for anyone who hates lag.

So Long, Second Life Forums

The Vanity Pics Thread Today
Originally uploaded by Milla Janick

I've finally had it with the Official Second Life forums. I've put up with the stupid reindeer games of the people there long enough. The twatbadgers who get their kicks out of using the abuse reporting function as a griefing tool can have the place. I'd also like to give the Linden Lab moderators a big shout out for making it an effective griefing tool.

I really don't see much point in contributing to a forum where someone can AR anyone out of spite and get a whole thread deleted. The regular suspects all point fingers at each other, denying and accusing, then finally someone brings in a sockpuppet to take the fall with an implausible explanation. Who is doing it really isn't as important as the fact they continue to do it, and Linden Lab keeps letting them get away with it.

Thanks to all of you who helped ruin it. You know who you are. Go fuck yourselves. Good luck to the decent people who still think it's a good idea to stick it out there.

Windows x64 Goodness

Bay City, 1024M draw distance
Originally uploaded by Milla Janick

I love the eye candy in Second Life. I want to see things the way they were meant to be seen. I monkey with debug settings to make things look better, and I love long draw distances. The downside to this is, it can eat up a lot of memory very quickly. I finally figured out what was happening when I was taking pictures in Avaria, with the draw distance set to 512M. Every 10-15 minutes, the viewer would crash. Watching the Task Manager, it became clear what was happening. When the SL viewer got to between 1.2 and 1.3GB of memory, bam, straight back to the desktop. Even a 256M draw distance at the Relay for Life pushed the viewer past this limit pretty quickly.

The problem is 32-bit memory addressing. 32-bit editions of Windows are limited to using 4GB of memory. About a gigabyte of that goes to memory mapped I/O and other flux capacitor stuff (actually much of that is the memory on your video card). 32-bit applications get 2GB to play with themselves. Why the SL viewer barfs up a lung well short of that, I don't know, but it does.

The solution is 64-bit Windows, a crapload of RAM and a 64-bit SL viewer. 64-bit flavors of XP, Vista and Windows 7 are available now. 8GB of DDR2 memory is available for well under a hundred dollars. The missing piece is the 64-bit viewer. There isn't one for Windows.

There is a hack, though. It's possible to make 32-bit applications "large address aware". This increases the amount of memory available to a 32-bit application to 3GB. The result of this hack is a viewer which is much harder to crash with long draw distances.

Details of the process can be found at Tom's Hardware Guide:

http://www.tomshardware.com/reviews/64-bit-vista-gaming,2250-5.html

It doesn't make SL run faster, it just increases stability when you push the viewer past its current memory limits.

Of course, I have to say use it at your own risk. Microsoft dude quoted in the article warns of potential weirdness with /largeaddressaware hacked executables, but I've encountered none so far.

I'm so Laaazy!

Ah, six months! Epic fail! I'll try to get something useful posted before the year is over, I promise!