Jump to content

Should 32-bit viewer code be killed off?


You are about to reply to a thread that has been inactive for 2798 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

My experiences of SL13B were mixed. I struggled to find a viewer that could cope with the volume of data generated by the comination of crowds and complicated scenery, and when the Viewer didn't crash, I wondered if the organisers had forgotten that ancient piece of technology that is the signpost.

I have known for a while that in busy regions, a dozen or more avatars (and the usual maximum is 40), there is slow loading of baked textures and meshes. In some cases, the sluggishness also affected script operation. It became apparent that these problems were affecting all os SL13B.

I tried several viewers, besides my usual choice of Firestorm, and both the 32-bit and 64-bit versions of Firestorm. So, at first glance, there's nothing to be gained from 64-bit code. There's the same patterns of sluggishness and crashes. But then I noticed that Cool VL Viewer, right from the point of startup and login, was using far less RAM.

For those who don't know, Cool VL Viewer harks back to the UI of the v1 Viewer, although it has all the code changes needed to handle mesh items, baked avatar textures, and even the new Avatar Complexity system.

I am led to believe that we can only have 64-bit code if we given up on featyres, such as being able to upload a new mesh, that depend on the HAVOK drivers, which are still 32-bit-only. Which seems a bit strange, although most of these game-engine code packages still seem to be 32-bit. I have got a couple of games that are using 64-bit equivalents, and it seems to take so long to write a game that a good 64-bit game engine wasn't available when they started.

I don't think Firestorm has done a good job. It looks like their problem is partly bloated code, partly a more general weakness of the 32-bit code that Linden Lab has been using since the introduction of Viewer 2.

Cool VL Viewer is an existence proof of what good 32-bit code can do.

Firestorm suggests that it will do no good to just take the existing source and compile to 64-bit

Maybe that code quality in Second Life explains the effort on Project Sansar. If you need to start from scratch on the Viewer, why not everything? Some of the problems are bloated meshes and textures. Get rid of the old stuff, use "professional" tools. But I have some idea of what to do, how to make efficient meshes and use smaller textures, and it has nothing to do with using expensive software.

SL13B pushed hard at the limits. The Landmarks for some of the stages seemed untested, delivering people to the wrong place in the region. Aim for the cluster of dots on the map, and you got nowhere close to the teleport that had been provided.

I told them. One person offered me a teleport, but nobody fixed the problem.

And the viewers still kept crashing as they consumed all the memory, real and virtual. 

Link to comment
Share on other sites

You get no advantage by using  64 bit code in this case. And the code needs more memory and the data structures too.

But the viewer can use more memory. I caught my viewer lately using 4.7 gb and still running fine. A 32 bit viewer will use less memory and probably would have made it too. But by my observations it crashes on that numbers.

I don't see a difference in performance between 32 and 64 bit versions, so there is no reason to use the 32 if a 64 is available. And about crashing: I can't even remember when i crashed the last time (with 64 bit viewer). So if I read that some ppl are crashing all the time - there more to investigate in every case than just the viewer.

Just saying: you need to have more than 4 GB of ram of course or there is no need for a 64 bit OS and viewer.

 

Link to comment
Share on other sites

The codeset is in parts more than 13 years old, held together with duct tape and chewing gum. The libraries are specialised and somewhat hacked by the Lab. The task to make it a 64 bit application would be daunting and wouldn't provide that much of a benefit.

In the end the fault is the builders and guests, and less of the applications. It's not 32 bit code causing the slowdowns and crashes as much as our video cards are being swamped with huge textures, bad mesh and excess draw calls.

Until the builders invited to any of these events learn to stop using 1024x1024 textures there isn't much that can be done.

In most cases using 256x256 textures instead of 1024x1024 will cause no discernable loss of quality. The biggest advandatge being 256x256 is also 1/16th the size.

 

Link to comment
Share on other sites

The Lab and some third party developers track crash stats on their viewers. 64-bit viewers have a much lower crash rate then 32-bit viewers. Using a 64-bit operating system helps 32-bit viewers crash less often. 

In general many viewer problems are memory related. 64-bit systems can spread out and use more memory generally avoiding problems longer than 32-bit systems.

Having a lower crash rate does not mesn they have better performance. But, having lots of memory in the system can improve viewer performance. 32-bit systems are limited to a 4gb memory space. Taking out room for the OS the apps have 3.5gb to work in. 64-bit systems are generally only limited by what the motherboard can handle, typically 64gb. Taking out 0.5gb for the OS that leaves 63gb for apps.

I don't know of anything the 32-bit Firestorm Viewer can do that the 64 bit can't... 

Link to comment
Share on other sites


Nalates Urriah wrote:

I don't know of anything the 32-bit Firestorm Viewer can do that the 64 bit can't... 

Apart from the mesh upload physics issue you mean? But that is easily overcome simply by switching to a different viewer for mesh uploads. As far as I know, there is no law against using different viewers for different purposes.

Link to comment
Share on other sites

  • 4 weeks later...


ChinRey wrote:


Nalates Urriah wrote:

I don't know of anything the 32-bit Firestorm Viewer can do that the 64 bit can't... 

Apart from the mesh upload physics issue you mean? But that is easily overcome simply by switching to a different viewer for mesh uploads. As far as I know, there is no law against using different viewers for different purposes.

And that should hopefully become a thing of the past once the Lab's onw 64 viewers are released, as they will use 64-bit Havok libraries, which all TPVs signatory to the Havok sub-license agreement (Firestorm being one) will also be able to integrate into their 64-bit offerings.

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 2798 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...