Viewers

General Viewer Information

Catznip Viewer R7 Soon

by

A new post on the Catznip site announces the coming Spell Check and Auto-Replace features coming to Linden Lab’s Beta Viewer. The LL version is from Kitty Barnett and I think first seen in Catznip R6, the current release of Catznip.

In the back-and-forth development to submit the code to the Lab the features have undergone some change. The Catznip Team considers this to be one of the largest third party submissions via the Contributor Agreement process.

See: Catznip Spellchecker Official LL Beta.

 

 

Firestorm Announcement Today

by

We have some news from the Firestorm Viewer Development Team today. Seems they have been suffering from burnout for a time. So, they have taken some time off and are now back.

It seems they have some new developers. Holy Gavenkrantz has apparently been a code contributor to Phoenix and Firestorm for some time. Now he is officially on the development team.

Navmesh (white) w/Static Objects (red) Showing

Armin Weatherwax was a lead developer for KoKua viewer. For whatever reason he has moved over to the Firestorm team and will be handling development of Firestorm for other grids, like OSGrid.

You may remember there is a thing floating round not so officially called the Havok Licensing thing. That is about Pathfinding, which if you don’t know is about creating Artificial Intelligence Characters or NPC’s (Non-Character Player) and your hopelessly uninformed, which I don’t understand if your are reading this.

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.

Singularity Viewer Update

by

The Singularity Viewer team has been quite and it has been some time since we saw a version release. Work is proceeding and we got a bit of information from Siana Gearz, the managing developer.

Well, the question when it’s coming is something we’re trying to figure out too. What can be said though is that we abandoned non-multiwearable branch recently and all work is being done for multiwearable release. Also we are reorganizing ourselves, i want the team to share the management duties and not just me alone cause my availability can be very mixed. Abandoning half of my life and all of my Second Life for Singularity was not a very awesome plan in the long run i suppose.

Reference SLUniverse: Singularity Viewer

It’s lots of work releasing a viewer. The time to a new release also depends the time developers have available to work on the project. Working on a viewer means one is not in Second Life. I can see it turning into work.

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.