Friday, 7 July 2017

MAJOR RELEASE: PMAC 2.5 with RLV and Lockguard Add-Ons

This release updates my Paramour Multi-Animation Controller system with a few small enhancements and is accompanied by the release of two brand new add-on that now makes a PMAC system fully RLV and LG capable. For the convenience of creators, I've also added a same script to convert existing RLV and LG content from a MLP system to a PMAC syste.

Due to the nature of the items and issues with script portability between Opensim versions, this release is entirely web-based -- you'll find links here taking you to the relevant scripts.

 PMAC 2.5 Core

 The core script has received only a few small enhancements and is fully compatible with all previous versions. There are no changes to the previous core functionality. You needn't update to 2.5 unless you specifically want one of the new features, most of which are geared towards creators who have requested a few handy utilities.
  • NEW: added configuration option to allow remote control of a PMAC object by touching it.
    The toucher must satisfy the user configuration options but no longer needs to be seated on the PMAC object. The remote user has full access to all menus and options they would have if they were using it but DO NOT USE THIS TO ENTER OR CHANGE THINGS IN EDIT MODE! (It will actually probably work just fine if you do but I haven't tested it thoroughly enough to be confident that it won't cause problems.)

    This configuration option is disabled by default. You can enable it in the core script's user settings section or by adding a line to your configuration notecard:
    allowRemoteControl=TRUE
     
  • TWEAK: if an invalid name is supplied for the default start group but PMAC is able to find any other menu notecards, it will warn you about the incorrect configuration and load the first of the discovered menu cards instead. Note: NO PERMISSION CHECK is done for that card.
     
  • TWEAK: in EDIT mode, the dialog box text is updated for each pose to show the names of the current animations being played. This is simply a convenience thing for creators and has no functional effect.
     
  • TWEAK: In EDIT mode, there is now a button allowing you to delete the current animation. This does not request confirmation and simply deletes the currently-playing animation from the menu's list. If you store the card, it will persist this removal. The revert button will not restore the pose...the only way to undo is to leave edit mode without saving changes and then either switch to a different group (which flushes the altered data) or to reset the PMAC system.

    Note that this DOES NOT clean up your inventory (since it's possible that the animations themselves might be used by other poses) so you'll need to manually delete any animations from inventory that aren't necessary.
     
  • TWEAK: In EDIT mode, there is now a swap button that will only work when the pose is for two positions. The swap actually swaps all position 1 animation data with all position 2 animation data (vs regular mode swap which just swaps the avatars' position assignment). IT DOES NOT SWAP ANY COMMANDS so if you're using any add-ons with position-based commands you'll need to edit those manually later.
The new PMAC 2.5 Core script is located HERE. I will also soon be putting a sign in my shopping region which will provide a link to this release announcement when clicked on.

NEW ADD-ON: Full RLV Support

This is in answer to the request I've received the most: "when will PMAC support RLV?" The answer is that PMAC has always supported it via an add-on; it just needed someone to write one. With the invaluable assistance of  +Walter Balazic, Dirk Mathers, and +Toy McBride of Littlefield Grid I can now release the new "..addon PAO RLV" add-on which does exactly that.
  • NEW: added a new RLV add-on which gives PMAC full support for the RLV API v2.9 (see http://wiki.secondlife.com/wiki/LSL_Protocol/RestrainedLoveAPI).
     
  • NEW: Included in this add-on is an integrated capture/release utility registered to the Options>Specials menu.
     
  • This add-on is 100% supported by the new PMAC2.5 ability to control the menus without being a seated user
     
  • The add-on supports the older (pre v1.10) RLV itmes that are most-often seen in Opensim which requires each command to be sent individually but it also supports the current v2.9 API that allows multiple commands to be sent in a single string. This dual support is on a per-object level (so your entire item must use one format or the other...you can't mix them within a system).
This is intended for creators who have solid working knowledge of both the PMAC and RLV systems. There are a ton of different variations out there in the metaverse and it is completely impossible for me to support every one of them so if you encounter issues unique to your item you need the expertise to solve that issue yourself via modifying the script(s) and/or set-up. DO NOT flood my IM box with support requests.

I will post a tutorial sometime in the next week or two to cover the basics of both this and the Lockguard add-ons for anyone who needs more detailed instructions than the ones included in the header of the script.

You can download a copy of the new add-on HERE.

NEW ADD-ON: Full LockGuard Support

A companion to the new RLV add-on, this separate add-on adds the ability to draw particle chains/ropes/whatever using the LockGuard v2 protocol. Again, big thanks to the people at LFG who kindly provided their time and expertise to answer my questions as I wrote this.
  • NEW: added new POA Lockguard add-on which gives PMAC full support for the LSL Lockguard Protocol as defined in the Wiki (http://wiki.secondlife.com/wiki/LSL_Protocol/LockGuard)
     
  • I have only written and tested this for LGv2. If you have an older system it's possible some changes will be needed
 Again, this add-on is intended for creators who are already familiar with the systems. I successfully tested this with multiple common items but yours might require some adjustment to work properly depending on the item and version. You need to have a sufficient level of expertise to feel comfortable doing this yourself.

As mentioned above, I will supply a brief tutorial sometime in the next couple of weeks to walk you through adapting or creating a basic system.
 
You can download a copy of the new add-on HERE.

NEW CONVERTER: MLP RLV & LG to PMAC

For creators and users with existing MLP systems with RLV and/or LockGuard elements, I am offering a sample converter script that I have written and used successfully to convert a dozen or so test objects. I cannot guarantee that it will work for your specific item, but there's a reasonable chance that it will or can be made to do so with only very minor tweaks.

You will first need to ensure that your starting system is completely functional since I made no attempt at all to catch or correct errors. If your starting system is broken, it will still be broken after conversion. Assuming you have a fully working MLP object, make a copy of it a then....:
  • use the MLP to PMAC conversion utility that Seth wrote and is included in the PMAC 2.0 builder's kit to convert the main system from MLP to PMAC (you can get this in my shop at RefugeGrid.com:8002:Paramour Shopping)
  • after conversion, add in the assorted required items (edit handle, base animation, core PMAC 2.5 script, etc) and test to ensure poses are working as expected (except the RLV/LG components won't be yet).
  • make a copy of this converted version just in case anything goes wrong during the next step
  • drop the new MLP RLV/LG conversion script into the object...it will read the RLV and CHAINDATA cards and then attempt to locate the corresponding poses and write the correct commands into the menu notecard data, saving the new result and deleting the old
  • now drop in the PAO RLV and/or PAO LockGuard add-ons (whichever your system uses)
  • finally, reset the core PMAC 2.5 script...with any luck you now have a perfectly working system
I cannot possibly support broken systems or all of the assorted versions and combinations out there in the metaverse. I'm offering this "AS IS" and if you run into issues you'll need to sort them out yourself to figure out how best to adapt an old system to a new one. In some cases it might be faster and easier simply to configure a PMAC one from scratch.

The system integrates a capture capability which is registered to the SPECIAL menu (in OPTIONS). The capture range is set in the RLV addo-on script header.

You can download a copy of the sample conversion script HERE.

PMAC RLV & LockGuard Tutorial

Yes, I will be doing one sometime in the next couple of weeks and will post a link to it here once it is completed.

In the meantime, here is a link to a sample notecard that is from an object that is set up for 2 users and incorporates both RLV and LG for one of them.

Wednesday, 17 August 2016

Avatar Complexity Oddities

Linden Labs has rolled out their new "Avatar Complexity" in their most recent viewer code, and most third party viewers have either already followed suit or will do so very soon. In testing it, I've discovered some very counter-intuitive aspects to it that all creators should be aware of.

What is Avatar Complexity?

This is a new evaluation that a viewer does of each avatar it has to display for you, and loosely speaking it gives you a general measuring guide for how difficult it is for a graphics card to display that person on your screen. Basic "Ruth" has a complexity of 1000. As you add some hair, clothing, shoes, jewellery, etc, the avatar becomes progressively more difficult for the viewer to draw, and the complexity value rises.

The exact calculation used (currently) can be found in the LindenLab documentation here as can instructions for how to see your values in-world.

The new viewer code has a sort of "scene culling slider" which checks the complexity of each avatar before drawing it for you. If the complexity is too high, it draws it as a very simple (and ugly!) jelly blob instead. The only exception is your own avatar...you will always appear fully rendered on your screen no matter how insanely high your complexity value is.

This "too high" cut-off value depends on the graphics setting you use, so if you have a fairly new graphics card you're likely able to run in Ultra graphics mode and only avatars with a complexity in excess of 350k will be turned to goo. If you have a somewhat older or less powerful card and can only run in Very High or High graphics mode, that number drops down towards 200k. For very underpowered cards running in Medium graphics mode, it's closer to 100k. There is a slider that allows you to override the cutoff, either raising or lowering it as desired.

Note that this has absolutely zero impact on the region simulator you're in. The data all gets sent to each viewer and this in no way reduces the server load. All it does is provide a mechanism for increasing your own personal viewer's frame rates if there are a lot of very complex avatars in the same region you're in.

My suspicion is that Linden Labs was sick and tired of hearing how laggy their region servers are when in many cases it's simply the user's graphics card incapable of sustaining a decent frame rate when there scene gets complex. Now they can point to a number and say "see, that avatar is way too complex so it's their fault and the lag is only due to your graphics card's performance, not our region." And that's true in many cases.

I also suspect they hope that by having these number visible to users, it will put some pressure on creators to be somewhat more prudent when making things. As a merchant you'll be able to point to your amazing new Product X and boast about how low a complexity value it has. If that means creators are making more efficient products (mesh in particular) then so much the better.

That's the theory. In practice, though...

A Number is Only Meaningful if it's Accurate

Here's the funny thing about using metrics: they're only as accurate as the method you use to calculate those numbers. The initial implementation of the Linden Lab viewer calculation isn't, or at least not when it comes to mesh.

Without getting into specifics (yet) I can assure you that the numbers you'll see in viewer are incorrectly misrepresenting the complexity of meshes. I'll assume that they're in the right general ballpark for a single prim or sculpty, but there's definitely something weird happening when it comes to mesh, causing it produce some artificially high values depending on how it has been created and textured.

As a general Opensim user, you should be aware of this before you start pointing fingers at someone and criticizing them for creating or wearing something that's too complex. Sure, maybe they are. But maybe they aren't and it's simply the viewer miscalculating the value.

Some Details

Let me give you an example:

My own in-world body is an all-mesh one. In Blender it's just under 30k triangles (15k verts) which is just a little under 4x as complex as the basic Ruth avatar (roughly 8k triangles/4k verts). Yes, it's definitely going to be harder for a graphics card to render so I fully expect it to carry a not-insignificant complexity value. It also uses 7 different materials (arms, legs, torso, face, lips, eyes, eyelashes) which is two more than the SL avatar uses, although the actual texture count is comparable...I simply break it up into more pieces for my own convenience.

Here's where it gets strange.

When I first uploaded it as a single mesh and put the textures on it, it reported as having a complexity of just over 30,728. I was expecting it to be somewhat high, but not that high. After some reading and experimentation, I discovered that the culprit was the 252 triangles of my eyelashes which use a texture that has an alpha (transparency). If you refer to my calculation link above, you'll see that having an alpha results in a 4x multiplier being applied to it and it seemed that the entire mesh was being hit with this penalty instead of only the portion of it that was using the eyelash texture.

I did a second upload, this time with the eyelashes as one object and everything else as a separate object. After putting the identical textures on it to my first test, suddenly my reported complexity was down to 13,796.

There is absolutely no different between them in terms of the work required by the viewer or your graphics card to draw either of them on the screen. They're 100% identical.

And it gets even stranger because next I broke my entire body into pieces, uploading each as a separate object, then wearing them all. Again, completely identical in all respects, but now the complexity was being reported as 10,364.

So the viewer is reporting three rather wildly different numbers for what are in all respects identical in terms of the metric they're supposedly supplying.

Which one is right? More importantly, which one is useful?

[Side note: just before you say I'm crazy to be wearing a body with 10k complexity, try putting on your favourite flexi-prim hair. I bet that more than half of the hair styles being commonly worn in the metaverse are over 20k which is double what my body is....]

From a simulator and asset-server point of view, the single-mesh object of the complete avatar is far, far more efficient. It's one request and one block of data to send. As the mesh is progressively broken up into more and more pieces, the burden on the simulator increases because each piece is a separate call to the asset server and a separate send to the viewer. Further, for the viewer to animate the avatar it has to move each of those mesh pieces separately on its own "rig" bound to the body, so (to a very small degree) it's actually more work for the viewer to have more pieces to have to do this for. And yet that complexity values being show reflect the opposite.

The exact same issue applies to all mesh objects that you might wear so that includes clothing or even unrigged mesh items. If it has a texture with an alpha, glow, bump map, or specular map (or basic glossyness setting) the penalty is applied to the entire object.

The Take-Away

There is already a Jira in Linden Labs' system to have them review this, and hopefully they'll adjust the code to have it only affect the actual surfaces (triangles) with that texture on them.

Until they do, though, you should be aware that some avatars are going to be reporting some much higher values than they really ought to be, so temper your criticisms of the wearer or creator, at least for the time being.

For the creator, it's a tougher call. Right now if you work with mesh, you'll get the lowest values by breaking up your work at least into 1 object per material and make it a linkset. You can get even lower by going wild and breaking it up into hundreds of little pieces to get even lower values. However, by doing so you'll be adding to the load of region simulators that are often already under strain, so perhaps find some happy middle ground and pass the word around that you shouldn't believe the numbers just yet....

Wednesday, 3 August 2016

RELEASE: Paramour Clubmaster Dance Machine v2.1

I'm happy to announce the release of the Paramour Clubmaster Dance machine v2.1.


This is a minor revision/update and is in most ways identical to version 2.0 in terms of features and contents. The new version contains only the following two changes:

Shorter Script

An issue was discovered where certain viewers (notably the current version of Singularity) were truncating the main danceball script if it was opened or edited using that viewer. Firestorm users were unaffected.

To resolve this problem required reducing the overall script length (technically, reduce its character count) which posed a problem as it was already as "lean" as it could be without making it unreadable for people interested in modding it. However, since very few people modify the set-up and those who do are typically able to do their own error-checking, I decided to remove the entire debugging and error-checking utility which was optional (and disabled by default) in version 2.0. In doing so, I was able to bring the script down comfortably under Singularity's limit without in any way affecting normal performance.

Less Spam

I've had a few requests to reduce the chat spam when a couples poseball self-destructs due to someone not sitting on it or having vacated it. I've altered the poseball script to stop it from saying anything at all, now, and will simply notify the other ball's occupant instead. Otherwise it will be silent.

Do I Need To Update my v2.0 Ball?

If you use Firestorm to edit scripts and don't mind a bit of chat spam from the couples poseballs, no. There are no other changes to functionality or contents and you can continue using v2.0.

Where Can I Get the New One?

The main place to obtain a copy is to pick one up from my Paramour Shopping region in RefugeGrid. You can get there by hypergridding to:
RefugeGrid.com:8002:Paramour Shopping
You'll find the boxed version of the danceball in the middle of the three pyramid-shaped buildings, on the wall beside the assorted club dance items. While you're here, have a look around and see if there's anything else you'd like.

As always, my products are free so don't hesitate to come and get one. If you really enjoy my products and want to help me a little with the cost of keeping the shopping region available, I'd encourage you to make a donation (even a very small one) to RefugeGrid...there's a sign on the wall of the building that you can click to take you to the web page where you can do so securely. Believe me, every little bit helps immensely and is very, very much appreciated!

EDIT: I had one person who picked up a copy earlier today from my shopping region who discovered upon getting home that it wasn't full perm. If that happens to anyone else, you can try taking a new copy or you can go ahead and use God Mode to force permissions...the danceball, script and animations should all be full perm.

Tuesday, 2 August 2016

IMPORTANT NOTICE re Paramour Dancemaster v2.0 Danceballs

A couple of recent issues I've been trying to help people solve with the Paramour Dancemaster v2 Danceball have uncovered an interesting issue: if you open and edit the main script using the Singularity viewer, it truncates the script at line 937 which then causes it to fail to work and there is no (easy) solution. This is caused by a character limits for script length that appear to be shorter in that viewer than they are with Firestorm or Kokua.

I will be preparing a new version of the script that trims out my instructions, comments, formatting, and changes variable names to be very short (and non-intuitive) variable names to bring the total script length down under the Singularity limit. In the interim, please do not edit and save this script using the Singularity viewer. You may safely use Firestorm (which I use) and I believe Kokua would also be fine.

I will post a notice once the new version is ready.

Weight Transfer Utility Settings for Blender v2.77a

In a previous tutorial post I went into considerable depth about Blender's weight transfer utility. That post was written under Blender 2.76 when that particular function in Blender was under revision in the code base and was subsequently changed somewhat under Blender 2.77 (currently Blender 2.77a at the time of this writing).

Here are my new recommendations:


As a reminder, the "quick steps" for weight transfer are as follows:
  • In Object Mode, select the object that will be acting as the source of your weights. This will either be your base avatar model or a piece of clothing that you have already weighted to fit and move perfectly.
  • Hold down the shift key and now select your target object -- the one you want to transfer your source's weights to. This should now display in the 3D View as having both items selected, with the target having a bright orange outline to indicate it's the primary active object of the selection (your source object will have a somewhat duller, redder outline).
  • Switch into Weight Paint Mode and your target object should be the one you see. It will be completely black if you use my recommended option setting to have "Show Zero Weights" set to "Active" (otherwise it should be a dark blue).
  • On the Toolshelf, in the Tools tab, click the Transfer Weights button
  • Immediately after doing so and before doing anything else at all  look at the most recent action settings area and you'll see the "Transfer Mesh Data" options shown in the above image.
Remember that as soon as you take any action you'll lose the ability to change those settings and would have to re-do the transfer.

The data we want to transfer is Vertex Group data, and we want to be creating new data. The "Vertex Map" option is the critical one in terms of how Blender goes about calculating the weights for the new mesh. In the vast majority of cases you will want to use Nearest Face Interpolated since it will typically give you the best starting point for this type of application. It will rarely be perfect, but generally requires a lot less tweaking afterwards than the other methods do. You can refer to the Blender Wiki for details of what each of the methods are and how they go about calculating the resulting data -- they were the same under 2.76.

The part that changed between 2.76 and 2.77 is the options needed for the Source Layer and Destination layer. Under 2.76 they were a bit bugged and confusing whereas now under 2.77 they've been cleaned up and make a lot more sense.

Your Source Layer setting needs to be By Name for a full mesh weight transfer, and your Destination Layer needs to be set to All Layers. Mix mode remains the same and should be set to "Replace" so it overwrites any existing weight group data in the target mesh.

I then strongly recommend following the transfer up with a "Normalize All" and a "Clean" as per my previous tutorial's suggestions.

Happy weighting!

Sunday, 8 May 2016

RELEASE: Paramour Skirt Builder Utility

It gives me pleasure to announce a new release: a flexi-prim skirt-building utility based on the very popular opensource "primskirtbuilder" by Daltonic.


This utility comes about as a request from Isis Ophelia who had a copy of the original SL script and asked whether I could adapt it to work under Opensim. After some rewrites I was able to make it work, although there is currently a bug in Opensim that requires a dialog work-around. This new release is the product of that work and is released under the same GPU license as the original.

The utility is essentially a "super loop-rez" script used to help make flexi-prim skirts. In addition to doing all the nasty math necessary to rez a nice flared circle of prims, this version of it also supplies special control prims to make the creation process even easier.

When you touch or sit on the main controller pad, you will be asked to choose how many prims to use for the skirt, and then rez them. The utility then rezzes the initial skirt as well as two special controller prims. One prim is used to change the shape, size, texture and flexi settings of the skirt's prims, and the other is used to change the shape and arrangements of the prims (the waist width in the x and y directions, the "saddle" shape, and its "poof" angle). When you change a control prim, it is updated immediately for the skirt.

Once you're finished, simply click "link" and the utility assembles and links your finished skirt.

You can pick up a copy for free from my shopping region:

RefugeGrid.com:8002:Paramour Shopping

You'll find it in the central pyramid-shaped building, on the wall with other boxed products.

EDIT:

 
A few people have asked me about good starting parameters if you switch to a cylinder shape. It will depend a bit on what you're making and how many prims you're rezzing but here is a starting point that you might find useful:
  • Size: make the x and y sizes approximately the same...I'll often begin with 0.5m
  • Path Cut: start 0.35 to end 0.65
  • Hollow: 95% (or 99%)
  • Taper: -0.5 to as much as -0.8 for both taper directions

This will give you the traditional arc-inward segments that are used for many flexi-prim skirts.

If you switch back to a cube you'll need to revert those settings back to zero them.
 

Monday, 28 March 2016

Release: "The Dancer" Series 11-16 Statues

This morning I've added the next 6 statue versions corresponding to my "The Dancer" series of renders in G+.

As with the previous ones, these are textured with a slightly cream marble and are full perm to scale or change the base, and you may change the texture to anything else you like.







Note: by Opensim standards these are not particularly light meshes (each statue is about 100k tri  for figure, hair, dress, and plinth combined) and would not be suitable for very high traffic areas. I suggest keeping them phantom, too, and just put an invisible prim cube on top of it if you need to collide with them.

You will find the entire series currently displayed in the eastern pyramid structure at RefugeGrid.com:8002:Paramour Shopping and, as always, they are free.

Enjoy!