Tips

Interesting Debug Settings

by

Strawberry Singh has a post on her blog titled Debug Me. Whether you follow her blog or Plurking you know she does some great pictures, which is an understatement. In Debug Me she is explaining some of the Debug Settings she uses to improve her pictures. You’ll have to visit her site for her settings. I’ve written a little about the settings from a performance aspect.

  • RenderGlow – This is mostly a visual change with little impact on render time. The viewer has a number of glow settings that do affect performance. So, you can control glow in most any scene of visual and performance aspects. Use your web browsers page search/find on the Debug Settings page to find them all. Some improve the rendering of glow at the cost of a slower render, but it is not a big performance factor.
  • RenderVolumeLODFactor – This changes how objects in SL are rendered. It has an impact on performance, but the amount of impact depends on the scene and camera location. So, you won’t see a 1-to-1 relationship between the setting value and performance. Berry gets good results with the value high, but that is in photos. If you are exploring SL, a setting of 1 or 2 is going to improve rez time and FPS. But, you will see the distorted sculpties and mesh objects that change shape as you get closer or move away. Higher values stop that changing. For photos a large setting can solve the problem sculpties looking funny.

Read more

Viewer Performance

by

A resident by the name of Nala Spires did some testing to see what affects the SL Viewer performance the most. You can read about his test and the results here: CPU / RAM/ VGA what sl likes More ? ((attempting to answer that ! ))

Nala Spires

She used this viewer: Windows 7 professional 64bit firestorm Viewer v4.1.1.28744

She also used FRAPS to benchmark the performance. FRAPS slows my system so I would expect the numbers to be a bit lower than normal.

A lot of the numbers make no sense to me. Since it is FRAPS I assume they were FPS numbers. But jumping around between 200+ and 20 seems a bit beyond anything that makes since to me.

I did read her Conclusions and they are interesting. Nala concluded  memory speed had a significant impact on performance. Buying FASTER memory did the most for performance.

Read more

#SL Viewer Problems

by

If you haven’t run into viewer problems, you must be new. A couple of problems have come up recently. Readers have asked or sent me IM’s on them. So, I’ll mention them because they seem to be biting some people. Also, because when I started experimenting I started running into problems.

Second Life Viewer 3.3.3

In most day-to-day use you are not going to run into these problems. But, it is depressing when you do.

Groups

You probably already know large groups, over 5,000, can be a problem and over 10k are a problem. They can be slow to load and nearly, if not completely, impossible to edit and work with.

One of the problems that seems a bit worse is opening a large group can lock up the viewer for over a minute and reportedly in some cases 3 or 4 minutes. I saw my viewer locked up while opening the Phoenix/Firestorm Support group, the largest group of which I’m a member.

See VWR-29124– Severe performance issues on 3.3.2 (258114) Release and 3.3.3 (259197) Beta in “Add scroll list item.” Thanks to Stephan Gaudio for pointing it out.

You’ll notice we currently are past those versions. But, I’ve run into the problem with 3.3.3 (260300) Jun 21 2012.

Baker Linden has been working on the problem for a couple of weeks with some help from other Lindens. But the previous article on Chnages Coming to SL shows there is lots going on. So, I suppose some of of the changes, like fixing groups, are shooting at moving targets.

Read more

#SL Pyramid Warning Symbols

by

Recently a number of us have been seeing a flock of organdy-yellow pyramids appear around us when trying on mesh. They look very much like the script warnings we see when a script fails. However, they are a little different in that they do not have the little piece of paper denoting a script within the icon.

These non-script inspired pyramids are caused by mesh failing to rez. It is unclear whether this is solely a viewer issue or a viewer and server issue. Whatever the case, the quick fix is a relog or teleport to another region.

One can also change the viewer settings to reduce the likelihood of being a roosting perch for a flock of pyramids. The setting can only be founds in the Debug Settings.

This is hard to test so I’m doing some speculation on whether or not the change is worth the effort.

MeshMaxConcurrentRequests – Number of threads to use for loading meshes. Default value 32. It is probably better to reduce this setting if you have a slower connection. Try increasing it if you hang out in places like TRUTH Hair. I know at least one person setting this at 256 and claiming it cured the problem. I’m not convinced.

I suggest leaving it at 32 unless you have a significant and persistent problem. If you do decide to change it, try 16 or 64.

I can’t find any other settings that limit mesh render. I seem to remember there were more. But, they have disappeared from recent viewers. So, there is little we can do to avoid the problem.

Blender 2.63 Import Problem

by

Drongle McMahon has been posting this information around. Seems there is a problem when importing mesh into Second Life.

In case anyone else gtets into a mess with this …

Th name of an imported mesh in SL is taken from the “name” attribute of the <geometry> tag defining the mesh. Im Blender 2.49b, the exporter took this attribute from the Blender object name. Unfortunately, in Blender 2.63 it is taken instead from the data block. This means that renaming your objects so that they have reasonable names sfter import is no longer effective. Instead you have to rename the data blocks. You can do that in Outline view or in the property editor for object data (the inverted triangle of vertices).

If you use the same datablock for multiple objects, the exporter uses instancing, with the geometry appearing only once in the collada file, referenced in multiple nodes of the scene, each with their own transformations. Unfortunately, the uploader does not use instancing (although it does reads it properly from the collada). Instead, it ulpoads separate meshes. Since only one of these can use the dtablock name, the others appear to be renamed to “Object”.

Gaia Clary points out in a follow up post that the problem is being fixed in Blender 2.64. See her post.

This issue has been “fixed” by adding a new select option.In fact i believe that the SL Importer takes the Object name from the wrong place. It should use the information provided in the visual scene description. But well…

The new option will be available in Blender 2.64.