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.
Saturday, September 25, 2010
Friday, September 24, 2010
So Long, Second Life Forums
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.
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.
Monday, July 20, 2009
Windows x64 Goodness
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.
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.
Tuesday, July 7, 2009
I'm so Laaazy!
Ah, six months! Epic fail! I'll try to get something useful posted before the year is over, I promise!
Tuesday, December 9, 2008
'Tis The Season
For Epic Treasure Hunts and OCD.
I'm hooked on lucky chairs, treasure hunts and all manner of freebies designed to lure you into stores.
http://gridwidehunt.blogspot.com/
300+ stores (they keep adding them!) and the compulsion to go to every one of them. What am I going to do with crap from a virtual adoption agency? Do I really need virtual organic shampoo?
Probably not, but now I feel compelled to complete the entire hunt, because if I miss something, I just know it will be that perfect skin or hair I can't live without...
Then there are the hunts I run into while I'm doing the big one, and picking up the freebies I run into along the way. I'll probably have 40,000 items in my inventory by Christmas.
I need help.
I'm hooked on lucky chairs, treasure hunts and all manner of freebies designed to lure you into stores.
http://gridwidehunt.blogspot.com/
300+ stores (they keep adding them!) and the compulsion to go to every one of them. What am I going to do with crap from a virtual adoption agency? Do I really need virtual organic shampoo?
Probably not, but now I feel compelled to complete the entire hunt, because if I miss something, I just know it will be that perfect skin or hair I can't live without...
Then there are the hunts I run into while I'm doing the big one, and picking up the freebies I run into along the way. I'll probably have 40,000 items in my inventory by Christmas.
I need help.
Sunday, November 2, 2008
I Haz Photostreams!
See my awesome photos from Second Life on Flickr & SLUniverse!
The SLUniverse pics give SURLs to the locations where they were shot so you can go see them to. Sometimes the SURLs even work. If they don't, you can still do a search for the place.
The SLUniverse pics give SURLs to the locations where they were shot so you can go see them to. Sometimes the SURLs even work. If they don't, you can still do a search for the place.
Wednesday, October 22, 2008
Nautilus
The Lindens "discovered" a new city in Second life, and it seemed like a good idea to check it out before they auctioned it off to be tastefully redecorated.
There's some nice scenery. Especially if you can get a tolerable frame rate at a 512M draw distance.
The auctions start the 24th, so get there quick, and try not to get run over by a blimp while you're looking around.
http://slurl.com/secondlife/Nautilus%20-%20Mysehi/118/32/23
There's some nice scenery. Especially if you can get a tolerable frame rate at a 512M draw distance.
The auctions start the 24th, so get there quick, and try not to get run over by a blimp while you're looking around.
http://slurl.com/secondlife/Nautilus%20-%20Mysehi/118/32/23
Subscribe to:
Posts (Atom)
