Saturday, 29 August 2015

RELEASE ANNOUNCEMENT: PARAMOUR MULTILIGHT 1.0

I'm happy to announce the release of a new product today: the Paramour Multilight 3-in-1 scripted lighting system designed for photo studio or other special snapshot lighting applications. Think of it as a fancy point-light prim, saving you the trouble of rezzing and configuring one yourself.



This is a single multi-piece mesh object with included script that activates on touch to present you with a variety of handy menu options, changing the object's appearance and its lighting properties to give you quick, flexible control over your lighting for portraits, product shots, or even for larger in-scene subjects. Intended to be used in conjunction with TVP windlight and camera controls, this will help to simplify your workflow when making your snapshots.

This product requires OSSL to be enabled in the region. When not in use it has very close to zero impact on a region and only slightly more than this during use (a listener is opened for a short while and then automatically closed after use).

The Menu

  • "DONE" closes the dialog. Just touch the light again to bring the dialog back up.
  • "HIDE/SHOW" lets you turn the entire object invisible and visible again, allowing you to quickly hide it so it doesn't appear in your snapshot but still provides its lighting effect. Don't worry if you hide it and then forget exactly where it is. After a little while it will un-hide itself automatically (by default, 5 minutes after you last used the dialog menu but you can change this in the script to any delay you like).
  • "TURN OFF/ON" lets you quickly disable and re-enable the lighting effect so you can easily see the effect of your light
  • "SPOTLIGHT" changes the appearance of the Multilight to look like a spotlight flashhead and loads preset point-light settings that mimic the hard, heavy-shadow lighting typically supplied by this type of studio light
  • "UMBRELLA" changes the appearance of the Multilight to look like a spotlight flashhead directed to reflect into an umbrella, loading the corresponding preset point-light settings to provide a mixture of direct and ambient light, softening the shadows while still maintaining a directional appearance
  • "SOFTBOX" changes the appearance of the Multilight to look like a studio softbox and loads preset point-light settings to deliver a very soft light with strong ambient fill and only a gentle directional component. It's not quite like a "real" studio softbox light but it's as close as the point-light capabilities of Opensim can deliver
  • "COLOUR" lets you choose one of nine preset colour gels to apply to the light. You can tweak these colours in the script if you don't like my preset defaults.
  • "INTENSITY" lets you change the overall coarse strength of the light via a sub-menu
  • "RADIUS" lets you change the radius of the light, providing direct control of how it impacts on other objects in your environment and also allowing more fine-tuning of the overall lighting strength.
  • "FOV" lets you change the field of view for the light. The three different light types (softbox, umbrella and spotlight) automatically set a roughly appropriate FOV for the light but your can further fine-tune this (or even completely override it to give a spotlight the FOV of a softbox if you want).
  • "FOCUS" is another parameter for fine tuning your light's appearance; although this will have only slight impact due to the point-light texture supplied with the system. You can change this to a different texture if you want more defined edges to your lights or are after a similar effect to using gobos
  • "AMBIENT" allows you to fine tune the amount of ambient light delivered by the point-light source, giving a reasonable amount of control over the harshness of shadows. You can even make your spotlight behave like a softbox -- or visa versa -- if you want.

Customization

The Paramour Multilight doesn't do anything you can't do with a simple prim cube. It just provides a cosmetic appearance and handy dialog-based set of controls to the point-light settings.

When you select one of the three light types -- spotlight, umbrella or softbox -- the object's appearance changes to match the selection and a set of point-light parameter are loaded to make the lighting approximate the effect of this type of light in a real-world studio. Almost all of those settings can be overridden  via the dialog, and everything can be changed just by directly editing the root prim. The system is all just a matter of convenience, saving you the trouble of setting up a generic prim with those values (and looks fancier :p)

Everything is configurable via an easy set of user settings in the full-perm script that requires almost no knowledge of scripting (though it helps if you're familiar with point light settings for prims).

The entire object is full perm, too, so you can change other aspects of its appearance if you want.

The Paramour Multilight (object and script) is released under Creative Commons Attribution-Non-Commercial-ShareAlike 4.0 International license

Does It Do Everything?

No.

This only supplies point-lighting as an addition to your scene. You will still need to use your viewer's controls to select an appropriate windlight setting as well as any other camera controls that might suit your subject matter (depth of field, field of view, focal length, etc). The controls available to you depend on which viewer you use. Consult your viewer's instructions.

If you use higher graphics settings you can use an unlimited number of these to paint your scene with light, even to the point of using a windlight setting that completely eliminates all region lighting (in Firestorm try "Phototools No Light"). I generally use a blend of a suitable base windlight, selectively enhanced by 1-3 few Multilights (much as I did throughout 30+ years of professional studio photographic work). Limitations in Opensim and the viewer rendering capabilities prevent you from achieving perfectly "real" results, but in most cases you can get pretty close.

Where To Get It

You will find this item, boxed, in the Paramour Shopping center building on Refugegrid (currently it's on the 2nd floor on the south side of the building). HGTP to refugegrid.com:8002 then take the local portal to "Paramour Shopping". The unit is not available at my Hedonism club.

There's a unit on display there for you to play with too.


Cost: as with all Paramour products, the Multilight is completely free. Enjoy!

Sunday, 23 August 2015

ADVISORY: ALL PARAMOUR PRODUCTS

For sim owners who use bleeding-edge Opensim code, please be aware that a recent commit will result in most Paramour products being broken as a result of changes made to list handling.

I have tested and can confirm that the products will run perfectly under opensim-c53f732 r/26180 2015-08-17 but are broken under opensim-62f3399 r/26181 2015-08-18 and later.

Mantis: http://opensimulator.org/mantis/view.php?id=7691

I have determined what changes would be necessary to make my products work under the new git master, but I will wait until the developers determine whether the recent change will become a permanent one or whether they will revert to the previous handling.

If they do retain the new methods I will release a revised version of all my products as rapidly as I can. There will probably be other scripts in your regions that would need updating as well -- very likely this will break MLP functionality as well, for instance.

For the time being I strongly recommend using r/26180 or earlier.

EDIT: ***** UPDATE  *****

These changes were reverted today and a new fix has been implemented in r/26193. I will test this as soon as I can and report back on its suitability.

EDIT **** UPDATE *****

I have now tested Melanie's most recent git commits to fix the issue and the current git master continues to fail and break the Dancemaster system and PMAC systems.

opensim-a9beee7 r/26193 2015-08-23 has not yet fixed the issue


***** UPDATE *****

As of opensim- 87247dc r/26194  2015-08-23 the issue appears to be resolved and scripts will behave as expected.

Saturday, 22 August 2015

ANNOUNCEMENT: Paramour Shopping Region Now Open

It gives me great pleasure to announce the opening of the new Paramour Shopping region in Refugegrid. This is a completely new region that will gradually be expanded over time, but I've been getting some requests recently that make me think it's worth opening sooner rather than later.

Where It Is and What You'll Find There

To visit the region, HGTP to refugegrid.com:8002 where you'll arrive in the main Refugegrid Welcome region. Then take the local portal to Paramour Shopping (Seth will have this portal set up this weekend) or do a map search for "Paramour Shopping". Please don't HGTP directly into the region because of the heavy HG login hit on the simulator -- our Welcome region is set up to handle it, my shopping region might struggle.


So, why would you want to visit Paramour Shopping? Here's what you can expect to find there already, and I'm constantly adding more and more items to it.

More than 50 unique, mesh statues

Over the course of the last few years I've made a fairly large number of mesh statues, in both marble and metalic textures. Some of these were made as art for my Paramour region, others were part of my OSG7B exhibit in the summer of 2014, others were made for my Roman Bath build, others are part of an upcoming installation I'm participating in at Nara's Nook, and still others are ones I have made for some of my private regions.
 

There are more than 30 of couples, and more than a dozen single figures. as well as a set of lions and a variety of plinths that can be used for all statues. All of these are full perm so they can be textured and scaled any way you like. All are of my own creation and very few are available elsewhere. I add to the collection on a fairly regular basis.

Price per statue: free

More than 150 fine art paintings at 1024 resolution

I frequently use fine art paintings as decor in my builds. I also use them as reference sources when creating new statue poses, buildings, clothing, and all sorts of other occasions. Over time I've built up a rather large collection of them, all scaled to make their long-dimension 1024 while preserving the aspect ratio. These can be placed in frames, or re-scaled to eliminate the edging (just remember to disable "stretch textures" before you scale if you're cropping the sides, and re-enable it if you're scaling the whole painting).

The majority of the paintings are from the Romantic, Neoclassical, and Orientalism art movements; but there are scattering of others. You'll find them covering the walls of the building -- both inside and all around the outside -- and I add to them as I collect new ones. All are public domain artwork and available from a variety of art websites so this just saves you the trouble of going out and getting them yourself.

Price per painting: free

Almost 1000 Female AO Animations

Over the years I've collected a huge number of female AO animations and many of the places I obtained them from have long since vanished so many are now hard to find. I've assembled all of the ones I have into a series of preview vendors, one vendor per AO action (walking, sitting, ground sit, etc).

Just hop onto the vendor's poseball and use its controls to preview the animations. Clicking the "buy" button will give you the one that's currently playing. If you really want to there's also an option to "buy all" but be warned that for the most common AO actions there could easily be over 100 animations so it will take a little while to transfer them all to your inventory.
 

Over time I intend to expand this area to also offer all of the assorted dance animations I've collected -- both singles and couples -- and eventually my entire animation and static pose collection (more than 4000 in total). Sorry, I have very, very few male AO ones.

With the exception of a handful of animations and poses I made myself, most are ones I've found as freebies while shopping all over the metaverse in the last half-dozen years or have been given to me by friends. I received them as full perm and open-source but if you are the creator of one and don't wish to be redistributed, please contact me and I'll remove it immediately.

Price per animation: free

The Complete Paramour Product Line

All of the assorted Paramour objects that I've released are now here as well. The PMAC System and Add-Ons, The Dancemaster dance system, the Polemaster dancepole, the Country Line Dance Floor, the Table Dancer table, and a Chair Dance system (sorry, the chair itself is pretty ugly still...I haven't gotten around to making a good mesh chair for it yet). My miscellaneous NPC items are there as well, and I'll be adding more scripts, utilities, and items as time goes by.
 

Currently, these items are all also available in the lobby of my Hedonism dance club but I would eventually like to remove them from that location so I don't have to keep duplicates of everything up-to-date as I release new products (and so people who want to just come to shop aren't hampered by any parties going on upstairs). Hopefully I can complete that transition later this year provided the shopping region holds up under the traffic -- something I will monitor fairly closely for a while. You can get these products in a handful of other places around the metaverse.

Pricing: all of my products are free

Limited Time Public Showing: Roman Bath Build (not for sale)

For a limited time I have placed my complete Roman Bath build on the south side of the region. This is not for sale, although the statues and paintings there are all available in the shopping center building. It's merely there as an opportunity to see a very highly detailed build that I normally don't have open to the public.

To fully appreciate it as it was intended:
  • make sure you are in ultra graphics mode with objects LODs set to max
  • make sure advanced lighting is enabled
  • make sure shadows are enabled and set to "Sun/Moon + Projectors"
  • make sure "bump mapping and shiny" is enabled 
  • make sure water reflections are enabled and set to "everything"
  • try viewing it under several different windlight settings (see below)
  • take a close look at things...there are details that the viewer won't show you until your camera is within the necessary LOD range
  • keep a fire extinguisher handy in case your graphics card catches fire...it's a very graphics-intensive build :p
The region itself is set to a fairly bright, flat lighting to make it a better shopping environment; but this lighting model is not suitable for the original design of the Roman Bath build which was for a warmer angular light.
 

This means to see it as it was originally intended you'll need to switch your viewer's windlight to something closer to my original custom lighting model for it which was a slightly soft angular light. It's worth checking out under SL 6am and 9am lighting, or SL 3pm and 6pm lighting, or AnaLutetia Avatar Opt (in Firestorm...not sure if other viewers have that one) or any windlight setting where the ambient light level is fairly low and most of the light comes from the sun or moon. It needs to be casting shadows that aren't too harsh, yet aren't so weak that it fails to show the extensive normal and specular mapping that (almost all of!) the surfaces have.

The building's central roof area is touch-to-hide/unhide. Normally only I can do this but I've enabled it for everyone to touch and see the effect of it being either an open-air or closed structure. If you can remember to, please leave it with the roof visible.
 

The original building also had a controller that lowered the region's water level, emptying the pool of water and turning the entire building into a dance hall instead (complete with Dancemaster system and a few Polemaster poles rising into position). I didn't include that part of the build here so you'll just have to imagine it without the water.

It's here for show only, not for sale; and will only be there for a few months -- it's more or less a visual space-filler so the region doesn't look quite so empty until I expand the shopping area with an additional building or two to house even more artwork and objects that I will slowly be releasing to the public.


And It's All Free? There's No Catch?

Yes, I do not charge for anything I create. It's all completely free.

For the time being I will be hosting the shopping region on my own server. That means you'll need to be a little bit patient when you first arrive since there are a lot of objects and textures that have to be sent to you. If there isn't a huge amount of traffic at any one time you should find the load times (and the time it takes to transfer things you "buy" to your inventory) fairly short. My "test guests" generally had the entire region rezzed and visible within 30 seconds of arriving. If there are a bunch of people at the same time it might get a little sluggish, for which I apologize. Hopefully you'll find it worth the wait.

Once in a while people ask me if I accept tips and I decline. I want to give back to the community that has so generously given me all sorts of things over the years. However, if you'd like to contribute the price of a cup of coffee or two to the cost of Refugegrid's servers -- which host my Hedonism dance club and serve all of the assets for my self-hosted regions -- you can find a secure Paypal link on the main Refugegrid web page. If there's significant region traffic and people are kind enough to make the occasional donation, it might become viable to move the shopping region to a dedicated instance on the main RG server. If not, I'll just continue to host it myself.

Anything Else?

Over time I intent to add:
  • a lot more statues -- I enjoy making them and I'm starting to get my workflow down to a reasonable time investment
  • more Paramour products for dance clubs as I think of them and script them...I'll happily take suggestions if you think there's a demand for something that either doesn't currently exist or exists but is simply too hard on sim resources
  • more Paramour products for NPC management, handling, and other utilities of that nature
  • a full line of PMAC furniture products (beds, sofas, etc) I'm slowly creating
  •  various other miscellaneous objects I create or scripts I write
  • other, more varied artwork -- potentially including installations by other interested artists
Most of the things I make are for my own consumption but if I think they might appeal to the broader public I will often try to make a more generic version and release it (the Dancemaster system is an example of that, as is the PMAC system). I do occasionally take requests if the project appeals to me, but please don't be offended if I decline...I'm happily retired now and want to enjoy it so I'll pass on anything that feels too much like work.

I hope you enjoy your visit and find at least a few things you like.

Friday, 21 August 2015

TUTORIAL: New PMAC System From Scratch

This tutorial is for users of the PMAC system who want to create a new item from scratch rather than convert an old MLP system. Once you've done it once or twice you'll find that it's pretty easy. The instructions are also relevant to someone with an existing PMAC system (perhaps one converted from MLP or one made by someone else) who wants to add a new group to the system.

I'll start by giving a quick overview of what we'll be doing:
  1. Getting ready: figuring out what object we're going to use and and what animations we're likely to want to put in it.
  2. Create one of more blank menu cards.
  3. For each menu card, populate it with the animation names and a guessed-at starting position.
  4. Add anything else we want and add the core items.
  5. Use PMAC's built-in position editor to get the real positioning we want.
An object with a very large number of animations in it is going to take a little while to do so don't plan it as a quick one-hour task. Make sure you've got some time and do it right the first time.


Getting Ready

One common mistake is to just jump in and start doing something without thinking ahead to what you really need and how best to achieve it. The "dive in" approach works, but you can later find that you've wasted quite a lot of time or limited the flexibility of your object. Instead, planning it carefully in advance will save you a ton of effort later.

Here's what I do:

My very first consideration is "what object am I going to put this in?" The PMAC system can go into anything: a chair, a sofa, a bed, a blanket, a rock, a flower, a tree, a coffee cup...all you need is a single prim or mesh or sculptie, or a linkset of multiples of these (PMAC must always go in the root prim). While it's possible to put the system into a slow-moving object, I don't recommend it and would advise strongly against attempting something like that until you've set up a number of other more simple systems first.

The example I'll be working with for this tutorial is a divan that I made for my Paramour region. The object doesn't have to be in its final position...you can rez a copy of it in your sandbox or anywhere else you like and work on it there. In many cases, though, it's better to have it in situ since the way you position your animations may depend on the surrounding space.

Next, we need to think about how we intend to use our chosen object in terms of the sorts of animations we will want to have in it. As you can see, my divan is very large, easily seating 3 or 4 people at once while they're chatting with one another, and having plenty of room for a several people to recline or sleep on it...or get extra-friendly. So this means we'll have several different purposes to the object, hence we'll want several different groups of animations.

The fundamental way that PMAC animations are organized is in "Groups" where a group is a set of similar animations which I think of as "poses". That's the "top level menu" and in PMAC each group has a separate notecard that contains the data for those poses.

A "pose" is one animation. If it's just a single person, a pose is the inventory animation I want to that person to play and a bit of data saying where to position them on the divan (or whatever object you're using). If it's two people, a "pose" is two inventory animations (even if they're actually both going to play the same animation) and the position data for each person. If it's three people, a "pose" is three animations....etc. PMAC supports up to nine simultaneous avi (or NPC) for each pose.

For example with my divan the sorts of groups I might want are:
  • one person sitting or lounging on it by herself
  • two people sitting/lounging and casually chatting
  • three people sitting/lounging and casually chatting
  • four people sitting/lounging and casually chatting
  • two friends wanting to cuddle together
  • two very good friends want to do more than just cuddle
  • potentially for the adventurous, three people wanting to cuddle or more-than-cuddle ensemble
The list could get pretty long if I also want further subdivisions of some of those categories. For instance I might want to break the "more-than-friendly" couples poses into gender combinations of M-F, M-M and F-F. I might conceivably want to try shoe-horning five people on it, too. As you'll see in a moment, it's good practice to think about that in advance.

It's also possible that I might want to add a few things that don't specifically involve the object itself, such as a handful of couples slow-dances that I might want to be able to use to dance with someone on the nearby carpet. As long as the positions aren't going to be too far away (try to stay within 10m although you can push that distance quite a lot further) and it makes some sense to have them in the object, why not?

There is no limit to the number of different groups you can have in PMAC and there are only two rules:
  1. Group Rule #1: The number of simultaneous users for the poses in any one group must all be identical. I can have one group for single person poses and another group for two-person poses, but I can't mix one-person and two-person poses in the same group. One very important thing to keep in mind, though, is that each position in a pose doesn't have to be occupied in order to play it.
     
  2. Group Rule #2: The name I use for a group has to be relatively short (under 20 characters and ideally under 10) because it has to fit on a dialog button in the menu system; and the group name must be unique. I can have some sit poses for one person and some sit poses for two people, but I have to give them different group names...perhaps "Sits (single)" and "Sits (couples)"
Here's where thinking about it a little in advance can be handy: I have four different groups of "sit/lounge" poses in my list above, depending on the number of people involved, but most likely I'll be using the same general poses for all of them and simply moving adjusting the locations for each person (and probably trying not to have everyone playing the same pose at the same time).
 
Because PMAC can play the pose even if all positions aren't occupied, I could actually just do a single "Sits  (max 4)" group and position things to "fit" nicely for four simultaneous users. If fewer people are using it they'll still look fine and there will be an added bonus that you can use PMAC's "Swap" feature to switch positions around between  people.

If I do this and am using it by myself, each pose actually becomes 4 different places I can put myself depending on which position I swap to. If I have just one guest I'm chatting with, I can use swap to move us into 12 different position-animation combinations. All with just a single pose and only having to set up 1 group! Much less work than setting up four different groups (being lazy, that sort of economy appeals to me).

I'm also going to skip doing the "3+ very friendly people" group because my divan isn't really intended to be used as an orgy bed (just not my style :p). I can envision using it for more than just cuddling, though, so I will include those (which I normally break into a number different groups because that's my preference but for this tutorial I'll treat that as two groups: "snuggle" which is sort of foreplay type things, and "together" for more explicit ones).

Now that I have my "groups plan" and I know roughly which animations I want to use, I can get started.

Create A Blank Menu Card For Each Group

In my inventory I now create one (blank) notecard for each group I plan to put into my object. The names of the notecards are extremely important in PMAC and detailed in the Read-Me notecards that come with the builder's kit. The naming format must be exactly:
.menussup group name
where:
  • the name must begin with ".menu" (the leading dot is important, and it must be lower case)
  • replace "ss" with any two valid characters (numbers or letters, upper or lower case) that are only used for sorting the order of the groups in inventory. Whatever order they appear in object's inventory is the order they'll be listed in the groups menu. The don't even have to be unique...you can have several groups that all use the same two sort characters and they'll simply be sorted by whatever follows them in the card name.
  • replace the "u" with a number between 1 and 9 to indicate how many simultaneous users this group's poses will be set up for. For a set of singles-only poses you'd use 1, for couples you'd use 2, and for larger groups you'll use however many the max is.
  • replace the "p" with one of three letters: O, G, or A to tell PMAC who is allowed to use (or even see) this group. If you use "O" only the owner can see this group in the menu and access it. If you use "G" only a group member can see and use that group (someone with the same active group set as the group assigned to the object). If you want everyone to be able to see and use that group, use A.
  • Then a space, and then lastly a fairly short, unique, group name.
When assigning a group name, remember the rules that each group name must be unique for this object and has to be fairly short. Anything more than about 20 characters will actually generate an error in the system when you try to use it. Anything longer than about 8 or 10 characters will tend to have the end shopped off on the button but will be shown in the dialog box above.

I should stress (because several people have asked me) that it's the group name itself that must be unique. You can't use the same group name twice, even if the sort or number of users or permission setting is different. PMAC needs the name itself to be unique. The names are case sensitive, though, so "Sits" and "sits" and "SITS" are all different groups names (if you can remember which one is for which group...).

For my divan I created four notecards:
  • .menu004A Lounging (4)
  • .menu012A Cuddle (2)
  • .menu022G Snuggle (2)
  • .menu032O Together (2)
If a casual visitor uses the divan they'd only see and be able to pick the first two menu items. A group member would also see the Snuggle group but I'm the only person who would see the Together group (because my Paramour region isn't a place for people to come and have sex...go use your own beds! :p).

As a side note: yes, if they inspect the contents of the divan they'll see the animations, extra "invisible" group notecards, etc. so you're not really hiding anything from anyone...you're just not making it accessible to them.

Now that we have our four empty notecards in inventory, we're going to work on them one by one until we've got a complete system assembled.

Contents of a Group Notecard

We need to do this section for each of the groups in our system (each of our notecards).

Each line in a group notecard is a "pose" that will have a dialog button when that group is selected. There is no limit to the number of poses you can have in a notecard although just for the sake of memory conservation and speed of use you'd want to keep it to under a hundred. PMAC only loads data for the currently active group -- not the entire system -- so you can easily have hundreds of poses available to you...just break them up into smaller groups.

My general rule-of-thumb is to try to keep it to about 24 or fewer poses in a single group because that's 4 pages to flip through in a group when looking for a specific pose and it keeps the memory usage to a minimum. Most people won't want to flip through 40 pages of poses just to find the one they're after anyway.

For each pose (each line in the notecard) we need to supply a name for the pose and it needs to be fairly short -- ideally short enough to fit completely on a dialog button but in any event it can't be longer than about 20 characters. It cannot contain the pipe symbol ( | ) because that's used as the data separator in the notecards; and it has to be a unique name within the group.

You can have a pose "Sit" in one group and use that same name again in a different group, but you can't use if for another pose in this group.

There is one further complication about "unique" names: if you use a pose name that is identical to the name of an animation in inventory that is being used in this group, that animation name can't appear anywhere earlier in the notecard. So, for instance, say you have an animation that you want to use that has the name "Sit 4". You can only name a pose "Sit 4" if that pose appears in the notecard before any other time the "Sit 4" animation is being used. The pose "Sit 4" could use the animation "Sit 4" because it will be later on the same line, but you couldn't have an earlier pose called "Sit 1" that also uses the "Sit 4" animation.

A good rule of thumb for avoiding these problems is to use naming conventions for your inventory animations that aren't likely to conflict with the names you want to use for a pose.

Pose (and animation) names are case sensitive, so an animation "sit 4" wouldn't cause any problems at all if your pose names always begin with a capital letter. Similarly, if you really wanted to you could have a pose "Sit 1" and another one called "SIT 1" and yet another one called "sit 1" and then even three more that don't have a space in the name.

In the notecard line, the next thing PMAC expects after the pose name is the pipe symbol ( | ) which is acting as our data field separator. PMAC doesn't trim leading or trailing spaces so be careful not to add any!

The next field for a pose is called the "commands field" which contains data for any add-ons you might want to use. Each add-on will have a specific format for the way it needs its data so you'll need to refer to the add-on's instructions for what it needs. It's beyond the scope of this tutorial to get into any details about that so for our example we won't be using any add-ons at all. This means our command field needs to tell PMAC that we aren't using any, which is done by supplying "NO_COM" as the command (NO_COM is short for "no commands").


Next, another pipe symbol ( | ) to indicate a new field.


Now for each position in this pose we have to supply three pieces of data, each separated with the pipe symbol: the exact name of the animation in inventory, the local reference position we want to move the avatar to when playing that animation, and the local reference rotation we want them to be turned to when playing it. The animation name part is easy: just be very careful to ensure that you spell it correctly, don't insert any extra spaces, and pay attention to capital and lower case letters since, like everything else, names are case sensitive.

The scary part -- particularly when creating a new system -- is the local reference position and rotation because you don't know them yet. They will vary depending on the object you're putting the system into, and on how the animation was made. There is little (if any!) consistency in any of this so that means every single animation is going to need to be custom-positioned and you will never know these values until you've done it. You could guess, if you've done this a lot and are familiar with your animations, but luckily we don't have to worry about it really...we're going to "cheat" and use a built-in PMAC capability to do the dirty work for us instead.


What we're going to do is supply just a generic position and rotation for now, and then later we'll use PMAC's position editor to get the positions where we really want them -- something we'd have to do anyway so why bother jumping through any extra hoops now? So...what values should we use? The answer depends a little bit on the object and also on the number of users the pose is for.

The very first time you do this it's going to feel nasty, confusing,  nd a bit like witchcraft. Once you've done one system you'll probably have a really good sense of how it all fits together. I'd suggest that for a first time user, start by setting up just one group, then adding others later. That way as you add you extra groups you'll have gone through the whole thing once and will have a bit better idea of the workflow.

My recommendations for starting positions and rotations:
  • If your pose is for just 1 person it's simple: a very good starting position is <0.0, 0.0, 0.5> if it's a sitting or lying down pose, or <0.0, 0.0, 1.0> for a standing one. If your object is very thick in the z-axis, you might want to increase that z-value a bit. When we play this animation it will put the avatar just a little bit above the center of the object which is a decent starting place for editing positions.

    Use a starting rotation of <0.0, 0.0, 0.0, 1.0> which will result in the avatar facing in the direction of the object's local x-axis.
     
  • If  you're using a bunch of singles animations for a multi-person pose it's pretty easy...just offset the position in either the x- or y-axis by some reasonable amount (perhaps 0.25m or 0.5m) to make the handles easy to select later. So, for example, for a two-person sitting or lying pose put the first avatar at position <0., -0.25, 0.5> and the second one at  <0.0, 0.25, 0.5>. That will put one a bit to the left and the other a bit to the right of the center of the object. for a three-avatar one you might put the first position in the center, then the other two +/- 0.5m in the y-axis. The idea is to give yourself a little room between each when you go to edit them later, so this half-meter offset will keep the positioning handles nicely apart and easy to select.

    Again, use <0.0, 0.0, 0.0, 1.0> as your rotation.
     
  • If you're setting up couples poses (ones made specifically that way) it depends a bit on the animation creator. Some animation creators set couples animations root positions to be identical, while others will offset them by 0.25m to as much as 0.5m, and it varies from creator to creator (and some creators aren't consistent in what they do either). This means that for some animations it would be better to start both at position <0.0, 0.0, 0.5> while for others you'd want to incorporate that creator-intended offset. Unfortunately there's no easy way to know other than to put them into a pair of poseballs, hop on each, and see what sort of space you need to put between the poseballs (if any) to get the positions right.

    If in doubt, I generally go with the same recommendation I made above and offset them by +/- 0.25m in the y-axis.

    For rotation I'd again use the <0.0, 0.0, 0.0, 1.0> starting point since almost all couples poses are either made that way (relative to one another ) or with one rotated exactly 180 degrees which you'll see instantly when you go to edit it later and can quickly change with no effort.
I'm sure the above is going to be confusing for someone doing a set-up for the first-time so just try to follow along with those recommendations as best you can, and if all else fails set everything to a position of  <0.0, 0.0, 0.0> and rotation of <0.0, 0.0, 0.0, 1.0> and sort it out later when you're editing the positions.

Here is an example of one notecard line for one pose for 2 people:

Hugging|NO_COM|hold_f|<0.0, -0.25, 0.5>|<0.0, 0.0, 1.,0>|hold_m|<0.0, 0.25, 0.5>|<0.0, 0.0, 0.0. ,1.0>

This would be a pose that will have the (unique!) button name "Hugging" where the first avatar plays the animation called "hold_f" and is positioned a little to the left of center, while the other plays the animation "hold_m" and is a little to the right.

Note that I have been careful not to insert any extra spaces before or after the pipe symbols. It makes it slightly harder to read a notecard line but PMAC does this because by not having to strip leading and trailing spaces from all names it can greatly increase the script's efficiency during operation. This would normally be the only time you'd ever need to manually edit or even look at a PMAC notecard.

If your group is for three avatars, each line would need another animation name, position and rotation. For four it will need 4 sets of those. For a single person item it would have only one.

Now you just need to repeat that for each pose you want in this group. Then repeat that for any other groups you want to add. I did mention at the beginning that setting up a new system from scratch wasn't a short process, didn't I? It isn't. If it makes you feel any better, setting up MLP from scratch is significantly more time-consuming and prone to error.

Needless to say, doing this manually for a large number of animations is a lot of typing and therefore a very high risk of typos or other errors. If you have a modest skill in scripting you can automate this task and virtually eliminate the chances of making a mistake.
By using a specific naming convention for your couples animations you can even write a script to automate it for them. For that to work, all you have to do is edit the animation names (if necessary) when you get a new couples animation from somewhere to make them comply with your own naming system. Of course if you haven't already done this with your existing inventory you'd need to spend a while making them conform, too, but you'd only need to do it once. If there's a way to automate that I'm not aware of it (other than having direct database access to the inventory server).

If you're planning to use an add-on you should also put some starting command strings for them into the commands field instead of the default NO_COM. Again that's easy to do if you're automating that process via scripting.

Add The Rest of the PMAC System Stuff

Now that we have our group notecards all nicely prepared with some pose data in them (using generic starting guess positions) it's time to do the next steps.

  1. Place all of those notecards into your object if you haven't already.
  2. Place all of the animations those poses are asking for into inventory.
  3. Place the "~~~positioner" object (from the builder's kit) into the object's inventory
  4. Place the PMAC base animation into the object's inventory (usually the "~~~~~base_DO_NOT_DELETE_ME!!!!!" animation from the builder's kit)
  5. Place the READ ME notecards into the object's inventory (because they really should be there in spite of the fact that many people don't read them)
  6. Place any add-on scripts you're using into the object's inventory (and any objects they might require)
  7. Add any NPC notecards you want to the object's inventory
  8. If you use a PMAC configuration notecard, put that into inventory and specify one of your group notecards as the default one for PMAC to load
  9. The last item you put into the object's inventory should be the core PMAC script (currently "..PMAC 1.02 Core"). If you don't use a configuration notecard the script will complain that you haven't specified a valid default group so you'll need to open the script and change it to have the default group be one of the ones you've created, then save.
If you've done everything correctly, you should be able to sit on your object and PMAC will work perfectly but be using the generic starting positions you've supplied from the previous step. Our final step will be to fix these by using PMAC's built-in position editor.

Edit Poses to Their Final Positions

I am going to assume that you've edited positions for a PMAC system before -- perhaps from a MLP system you've converted -- so I shouldn't need to go into this in detail. Remember that to enter edit mode all positions for that group need to be filled (and no extra positions can be occupied) so you might need to rez or remove NPCs to get the correct number of users.
 
You simply need to pick a group, then enter edit mode and position each pose using the handles, then save notecard. PMAC stores everything for you, correctly formatted, with the correct new relative position and rotation data based on where you moved things with the handles.

Then repeat with each of the other groups. For a large system this is going to take a while...drink lots of coffee and save often!

Congratulations...if you've followed all of the above steps you have a fully working, custom-positioned PMAC system. With my divan (which I haven't yet completed) I expect the process to take about 2-3 days of work, depending on how many animations I use and how many of them I've already used in other PMAC objects where I can simply copy-paste and do a quick position tweak to fit the new object (I can pull a bunch from my bed, for instance, and simply move the location to wherever I want them to play for the divan).

The good news is that the more of these systems you do the faster you'll get at doing it. You'll also be able to copy-paste portions of previous systems into the new one's notecards and then just do a tweak to edit positions for the new item, agains speeding things up and reducing the chances of error. You may even begin storing PMAC group notecards along with your animations just to make it even easier (which is something I've begun to do but haven't gotten around to for all of mine).

Saturday, 15 August 2015

Paramour Returns

As some of you may recall, this spring I had a serious system error that required a complete (unscheduled!) factory reset of my computer and one of the casualties of this was my Paramour region -- a sim styled after the 19th century Orientalism art movement.

I began work on the region in November of 2012 and it had gone through a number of iterations until I got the overall style and look I was after. With the variety of other projects I was working on, it wasn't until the summer of 2014 that I opened it to the public, even though it was still under construction as I added more furnishings and scripted objects.

All of that came to a crashing halt in August when OSG went down, taking my region with it. I had many OAR back-ups of it, but all as no-asset ones to keep down my storage requirements. My full-asset back-up was only February 2014, long before I began adding the core interior objects.

I resurrected the region from that OAR and resumed working on it in its new home in Refugegrid and by March 2015 had redone -- and improved on -- most of what I'd lost. That's when my own computer crashed and burned and, like an idiot, I hadn't burned copies of any new oars to CD so it took my backups with it.

Lesson learned. Now I back up no-assets nightly; do full-asset backups weekly which I mirror to an external drive as well;  and burn a hard copy of my most recent OARs once a month. That did nothing to recover any of my earlier losses but at least I won't be subject to that particular nightmare again (knocking on wood).

After having lost all of that work a second time I didn't have the heart to even contemplate doing the Paramour region yet again. The first time is fun...it's creative! The second time is a bit more like work with a lot less creativity and a lot more repetition. As I contemplated doing it yet a third time I just didn't have the heart for it.
 

Instead, I've been working on some other things...a Roman Bath, and a collaborative story project with some friends (the HG Safari got a sneak peek at it last Wednesday), and I finished some assorted scripting porjects (the PMAC system was a direct result of my working on something I needed for Paramour).  During that time I've been patiently waiting for some of my earlier enthusiasm about Paramour to return, for the idea of working in it again to be something I might look forward to rather than dread.


That time has come.

A week or so ago I reloaded my old OAR from February 2014. A couple days later I mustered up the "courage" to TP there and look around, taking stock of exactly what I needed to redo again and mulling over some ideas of how it might be improved upon compared to its two previous incarnations.

So all of that is to say that Paramour is once more under construction, and while I'm working on it I'll leave it open to the public to visit if they wish. In time it will regain more of the lost opulence and be the site of some new creations.

If you'd like to have a look, you can HGTP to refugegrid.com:8002 and then take the local portal to Paramour. It's still a bit sparse, needing exterior landscaping and more interior furnishings, but it's still a pleasant enough place to visit that I won't be ashamed to show it.

Be patient, though...it's on my home server so it will take a little longer to rez and the vast majority of the region is mesh with both custom normal and specular maps so there's quite a lot of data to send (and you'll need to be in a high enough graphics setting to allow Advanced Lighting model rendering if you want to get the full intended visuals).

There could also be brief periods where I will need to take if offline to do system and software updates but it should be accessible most of the time.

If you do visit, feel free to come back periodically to see what things are added, replaced, updated, scripted, or otherwise enhanced. Maybe by Christmas 2016 it will be "finished" -- or as finished as any region ever is.




Note: all photos from this post are "current" in the sense that this is what you can expect to see when you come. This is the region reloaded from the original OAR.

Friday, 14 August 2015

Because It Needs To Be Said

This week Dorothea Lundquist of OSGrid announced that she and Jay (JayMaze Yao) will be taking a sabbatical from Opensim -- and virtual worlds in general -- with their final Friday party being held on Friday, September 4th.



I suspect there are very few people in the Opensim metaverse who haven't attended at least one of the Friday parties that Doro and Jay have been hosting, weekly, for nearly seven years. I doubt there are many who don't have at least one -- if not many! -- of Doro's creations in their inventory since she has produced so many great items of furniture and clothing over the years, all freely given to anyone who wanted them. Doro and Jay have, in many respects, been the very heart and soul of the Opensim community for years and years and years...to the point that it's hard to contemplate what it will be like while they're away.

I first met Doro and Jay more than 5 years ago when I first came to OSGrid and haven't missed all that many of her parties since then. During the years I like to think we became very good friends, helping one another with various little projects here and there and generally providing one another many moments of social pleasure.

They've been doing this for so long now that they both feel in desperate need of a break -- time to recharge the batteries and an opportunity to rediscover some of that inspiration and creativity that drove them for so long to do and make the things they have. Fridays will feel like "just another day" once there's no D&J Party at Close Encounter to go to (they will be removing their regions once their sabbatical begins).



Hopefully after a while they'll miss our company, the weekly interaction with the many, many friends they've made, and will return to the community. If not, I can only wish them both the very best, and hope that wherever their interest lead them next, they're happy and inspired. It has truly been a privilege and honour to know you both.

To everyone out there in the community, if either of these two stalwarts of Opensim have touched your virtual life in any way, I beg you to take a moment or two to drop them an IM just to say "thanks", or to make an extra effort to come to one of their final parties (held Fridays starting 11:30 grid time, at "hg.osgrid.org:80:Close Encounter") to do it in person.

And to you both, Doro and Jay, I can only say thank you so very much for your friendship, your generosity, and many, many moments I will never forget. I love you both.