I've decided that since I actually comprehend what Poser is doing when it reads a file, I'm going to start posting some technical documentation.

The place to start, to me, seems to be explaining how a Poser file reads in geometry. So I'll do that.

Poser only uses Wavefront OBJect geometry. If you import Lightwave or 3DS or CAD or VRML, a subroutine converts the geometry to Wavefront OBJect format and then reads it into memory as such.

Terminology

Hereafter, the term 'object' will be used to refer to all forms of Poser objects, be they actors, props, lights, waveDeformerProps, sphereZoneProps, magnetDeformerProps, baseProps or cameras.

The term 'geometry' will be used to refer to actors and props specifically.

The term 'non-geometry' will be used to refer specifically to all objects except actors and props, despite the fact that lights and deformers do, in fact, load non-rendering geometry.

The term 'pseudo-geometry' wil be used to refer to non-geometries that load an object but do not render; lights, waveDeformerProps, magnetDeformerProps, baseProps, and sphereZoneProps.

The term 'definition block' is used to name the code block of a Poser file that sets up the channels and other properties of an object.

The term 'declaration block' is used to name the block in which an object is declared and at which point its geometry, if any, is read in.

When you see something in <> brackets, it means it's required but you're responsible for putting something in there. For instance, means any integer, be it 1, 23, or 144.

Similarly, something in [] brackets means it's optional. Poser's syntax is pretty tight, but not every line is always required. You will inevitably find someone somewhere who left out a line that appears in [] that hasn't ever had anyone report a problem.

Anywhere a string is called for, you can replace this with a call to GetStringRes(), a runtime function which takes two numeric arguments. Rbtwhiz's webpage has a wonderful chart showing the various results of arguments to GetStringRes in English. If the user's language is not English, this will be replaced with their language equivalent word or phrase. It's only recommended to do this with human-readable names (i.e, generally anything defined by a name directive).

The term 'bool' meand a boolean, a true-false value. Poser seems to define these by using 0 for false and anything that's not 0 as true (or at least anything positive -- I've never tried a negative number). You'll notice that Poser files often have, for instance, forceLimits 4 in them. 1 works as well as 4. Don't be fooled by Poser's eccentricities. The term 'float' means a floatingpoint number; that is to say, one with a decimal point as opposed to an int which doesn't have a decimal point. 3 is an int, 3.14159 is a float.

Part 1: Standard Geometry

geomResource

The first and most basic type of geometry is an internal Geometry Resource. I have found three of these:

4 Ball 6 Ground Plane 7 Light Direction Indicator (No faces -- will not render!)In a poser file, this is indicated by using the line:

geomResource <int>

inside of the declaration block for a geometry or pseudo-geometry. This will generally be indented for clarity.

When Poser encounters a geomResource directive, it loads in the geometry referred to by the resource ID. If the ID doesn't match anything, no error message is displayed, but no geometry is loaded. This can, in theory, be used to define 'fake' items that have channels, fit into a heirarchy, and have JPs, but do not have any vertices. This would be effectively equivalent to loading in an external OBJect file with no actual geometric content.

objFileGeom

The second simplest form of geometry loading is by using the objFileGeom directive. This command tells Poser to load a geometry in a specific Wavefront OBJect file. It appears with the following syntax:

objFileGeom <int> <int>
<path>

Like geomResource, this directive can be found in the declaration block of an object.

The path can be either in the form of an absolute location (i.e. "C:Program FilesPoser 4RuntimeGeometriesMyStuffmyprop.obj") or as a Poser Relative path (i.e. ":Runtime:Geometries:MyStuff:myprop.obj"). If the latter type of path is used the quotes are not necessary (except, perhaps, if you have spaces in the filename -- I haven't tested that, so either use quotes or test it).

The Poser Relative path style is vastly preferred, and if you intend the file to be distributed and usable by people who may have Poser installed in a different directory than you have (for instance, under 'Mac Drive 1:Applications:Poser 4'), it's a must. Renderosity and DAZ both require this path style.

When Poser encounters an objFileGeom directive it reads in an entire Wavefront OBJect geometry file as the geometry associated with the object regardless of the groups defined in the Wavefront OBJect.

geomCustom

The third simplest, and frustratingly common form of geometry loading is the geomCustom directive. This type of geometry actually reads in custom geometry from the file itself. This is the default for how Poser stores props imported rom either Wavefront OBJ files manually or from other file formats. This format includes a block which contains the OBJect file itself plus a few other informational directives, as shown below:

geomCustom 
        { 
        numbVerts <int>
        numbTVerts <int>
        numbTSets <int>
        numbElems <int>
        numbSets <int>
        v <Vertex Coordinates>
        ...
        [usemtl <Material ID>]
        [g <Group ID>]
        f <Face Coordinates>
        [t <Texture coordinates>]
        }

The numbVerts should tell the number of vertices in the geometry. The numbTVerts directive should tell the number of texture coordinates in the geometry. The numbElems directive tells, I believe, the number of facets in the geometry. I'm not sure what numbTSets and numbSets indicate.

Note that this method of reading geometry, while convenient, is best avoided. Poser creates .rsr files for geometry it has read and stores the geometry in a binary format within that .rsr resource when it reads from an external OBJect file. This file is faster for Pose to read. It cannot do this with a geomCustom internal OBJect, and thus props and other objects using geomCustom are best avoided. There are a few easy ways to solve this, however.

If the original file was read in from a Wavefront OBJect and the entire OBJect (all groups) makes up the Poser object, that Wavefront OBJect file can be directly referred to with an objFileGeom directive (see above). If the file was read in from ome other file format (such as 3DS or LWO), the custom geometry can be removed from the file and placed in an external Wavefront OBJect file using the following simple technique:

1. Select everything within the of the geomCustom directive.
2. Cut it and paste it into a new text file.
3. Add an OBJ comment (#) indicator in front of the numb- directives at the beginning
4. remove all the leading whitespace (generally tabstops) from the lines*
5. Save the file with a .obj extension (for instance, 'myprop.obj'), preferably somewhere under the poser Runtime/Geometries/ folder (i.e. 'Runtime/Geometries/MyStuff/myprop.obj').
6. Remove the geomCustom line and thes
7. Add an objFileGeom (and, at least traditionally, a storageOffset directive (see below)).

• If you're using vim (www.vim.org), the text editor I recommend, you can strip out all whitespace using the command:s/^<tab>//g

figureResFile and geomHandlerGeom

The directives figureResFile and geomHandlerGeom work in combination to allow multiple object geometries to be loaded from a single Wavefront OBJect file. This is most often seen in CR2 files (and in PZ3 files that contain posable figures), but it can be used with any geometry. Here's how it works:

First, a figureResFile is declared outside of any block (except the enclosing unnamed block that surrounds the whole figure, though don't put one before the *version{ block). The directive tells Poser to open a Wavefront OBJect file and read it into memory, but it does not associate that geometry with any object by itself. The syntax is as follows:

figureResFile <path>

Then as the objects are declared, they define their geometry with geomHandlerGeom directives, which use the following syntax:

geomHandlerGeom <int> <Group ID>

This assigns a group within the Wavefront OBJect to be the geometry for the Poser object. The integer (int) is (at least traditionally) 13. I'm not sure why.

Traditionally, the figureResFile is declared again after all of the props or actors are assigned, between the declaration blocks and the definition blocks. I'm not sure why this is done, nor have I seen any difference when removing it.

You can, of course, use multiple figureResFile directives. If you do this, all geomHandlerGeom directives refer to the most recently opened Wavefront OBJect (and thus require the group requested be in that OBJect).

The mysterious storageOffset directive

You'll notice, if you crack open a CR2 or PP2 with external geometry, or a PZ3 (or even an LT2) that all the above geometry definition techniques except geomCustom are preceded by a storageOffset line. This line has the following syntax:

storageOffset <int> <int>
<int>

For objFileGeom and geomResource directives, the traditional numbers following the directive are 0 0.3487

. For geomHandlerGeom directives, the numbers are simply 0 0 0. I've played with these numbers trying to see what changes and found -- nothing. Nothing at all. As a matter of fact, I've removed the line altogether and it didn't seem to make a bit of difference in Poser 4.03. I can only surmise that this is a legacy directive from Poser 3 or earlier that's left in as a matter of course. It doesn't seem to be necessary at all. As a note, geomCustom directives are not preceded by this line.

If you include it (I do, though I do not know why, nor can I surmise what difference it een could make since the numbers are always set), it goes before the geometry assignment directive (but not before a figureResFile directive, which only reads geometry, it doesn't assign it).

Complex Geometry Reading

You can get as complex as you want with these. You can open a figureResFile OBJect for reading, read some body parts in from groups therein with geomHandlerGeom directives, open another figureResFile and read in more groups to other actors, read other actors in from internal geomCustom blocks, read in yet others from objFileGeom files, and even add a sphere or plane using geomResource. As long as your syntax is right, Poser will be happy.

As a note, you can theoretically load up geometry within a declaration and never assign it any definition -- if you do this, you will make Poser load up an object that cannot be moved or manipulated in any way (though it can be selected). Of course, it cannot properly work in a figure, but it might make a decent way of loading immovable walls without having to force 0 limits on the trans dials or something.

Extended Geometry - Dial-a-shape

The alternateGeom, defaultGeomName, and objFile directives

Ever wanted to make a Changing Something-or-other? Enamoured with Anton's Changing Fantasy Suits? Like dial-a-tile? Even just think the P4 skeleton hands are pretty nifty? Here's how it works:

All of this takes place down in the object definitions, not the declarations. All the object loading stuff in the prior section dealt with declarations, so just keep in mind that this is in the bottom set of object blocks, not the top set.

First of all, within the definition block for your object that has a change-dial, you need to declare the other geometries to replace the normal one. For this, you use the alternateGeom directive, each of which precedes a sub-block (a section). The syntax for this looks like what follows:

alternateGeom <string>
        {
        name <string>
        objFile <int> <path>
        }

The string should be a unique name to distinguish it from any other object or sub-object in the file. This will serve as the sub-object ID.

Within this block, you give the sub-object a human name with the name directive (for legacy purposes, if I recall correctly; pre-4 versions of Poser showed this name -- it doesn't seem to show anywhere in Poser 4.03). Next you define the Wavefront OBJect file to read the geometry from with the objFile directive, as shown above. The integer (int) should be set to a unique number from the other sub-objects, and to make it easier for you and others to see your code, you should probably make this make sense with the ID you gave it (and possibly the name if applicable). For instance, if you have changing left hands on a figure, your first alternateGeom ID might be lHand_2, and the objFile integer might be 1002 (this is what you will find in the P4 skeleton).

Here's a little note about how Poser does this: Poser reads in the alternateGeom declarations in the order it finds them and assigns them to a zero-indexed array. When you set up your geomChan channel (see below), each of the whole numbers available on the dial apply to the item in the array corresponding to that number. Poser doesn't give a damn what you use as the ID, name, or objFile integer. It doesn't put them 'in order' or anything like that, it just puts them in the order you declared them. This means that it might be prudent and easier to read if you don't do what the folks at MetaCreations did. Instead of making your first alternateGeom #2, make it #1 so that the numbers on the dial line up with what you put in them.

Making it work: the geomChan dial

Of course, now that you have all this wonderful geometry, you'll want to give someone a way to actually select that geometry. To do this, you need to add a geomChan channel to the object. This looks like so:

geomChan <Channel ID>
        {
        uniqueInterp
        name <string>
        initValue <float*>
        hidden <bool>
        forceLimits <bool>
        min <float*>
        max <float*>
        trackingScale <float>
        keys
                {
                static <float>
                k <int (frame)> <float* (value)>
                }
        interpStyleLocked <bool>
        }

• While a floating-point number is certainly allowed here, as in any channel, in a geomChan only integers really make much sense as only integers mean anything to a geomChan channel.

For those of you not familiar with channel definitions and key definitions, the above directives mean, in order of appearance (and to the extent of my knowledge):

• uniqueInterp: I'm pretty sure this means 'only display integer vaules on the dial' though I may be mistaken.
• name: The name that shows up for the dial (should be human-readable)
• initValue: The Initial Value; the value that it goes to when you 'Restore Element' (but not necessarily the value it has when it's loaded)
• hidden: As 0, the dial is not visible or usable, as 1 or higher it is visible.
• forceLimits: Whether or not to force use of limits regardless of the user's 'Use Limits' preference. Any value over 0 is yes, but for some reason Poser stores a true value as 4 here. I never do. It should be noted also that forceLimits really means nothing on a geomChan dial: limits are always forced on it, and regardless of settings cannot go over the number of alternateGeom sub-objects declared
• min: The minimum limit value
• max: The maximum limit value (see forceLimits above, though)
• trackingScale: The sensitivity of the dial. .04 is a good value for a geomChan dial.
• keys block: the pose information
• static: the 'default' value of a frame with no pose information (though such will be set to the previous value if any)
• k: a pose datum. The first number is the number of the frame, and the second is the value that's set for that frame.
• interpStyleLocked: I am pretty sure this defines whether or not the user can override the settings and, if so, will always be seen as '1' for a geomChan

That's it for the geometry lesson (heh).

To quote Keanu Reeves... Whoah...

Very good, dodger. It's nice to have all this info in one place for a change. I have it all scattered in various docs (by VK, Anthony Hernandez, etc). Plus, you've cleared up a few things that puzzled me. A couple of points. 'The mysterious storageOffset directive' I also messed around with this, thinking naively, that I might be able to move an externally referenced obj for a figure in poser space, without going to the hassle of moving every part of the assembled pieces one by one. No such luck. The damned thing doesn't make a hoot of difference. Pity... 'uniqueInterp' If this does mean only use integers, would this force MTs to jump from 0 to 1? I must try this. It could be useful for some things. 'trackingScale: The sensitivity of the dial. .04 is a good value for a geomChan dial.' Hmmm...Pity that no matter what you do, the tracking for morphs never changes. I'm ready to be corrected here, but I've never yet found a way to force morph tracking. mac PS Maybe you should give this doc to the guy who was compiling cr2 info on his site. I can't find the addy, but I believe he's japanese.

.

You are the man Dodger. This is exactly what i was looking for. Is it possible to elaborate a bit more on removing OBJ from CR2s and PP2s . Like a walk through sample I can follow along to make sure i did it right and didnt miss any thing. ?

Thanks for sharing the "Dial-a-shape" I was pretty interested in knowing how this was done and how to do it myself.

Reletive paths have been a BIG beef with me lately after i spent 3 hours crashing my sytem trying to load a item i got at RDNA . After giving up any possible rendering that nite i opened ther cr2 and saw it was trying to look for "C:DatenPoser 3DPoser 4Runtime .... on my hard drive. Hmm dont remember any daten folder in poser ( Sarcasm )
I do have a question about reletive paths though. I was always told to start it at runtime . like this textureMap ":Runtime:textures:Tasquah:Drum:X-Drum-Kopapelli001.jpg"
but lately i have see just this used : textureMap ":Tasquah:Drum:X-Drum-Kopapelli001.jpg"
Because supposably poser looks in the texture folder first. Any comments about this right or wrong ?

Thank you Shanna :-)

Thank you, this is just what I need.

Maclean: Here's a quote from the Helpfile from Ajax's EasyPose Underground: Because morph dials respond to mouse control at 1/50 of the rate of valueParms, all of the speed settings will automatically be multiplied by 50 to compensate when you choose to use null morphs as EasyPose master dials. Note that this is not the case when you use null morphs in the ERC control panel, where the control ratio you set is the control ratio you get. This indicates to me that you simply need to go more extreme when upping the sensitivity of those morph dials. Tasquah: Okay, for example, if you had a Poser prop with the following geomCustom directive this is (shortened, obviously):

prop thingy_1
    {
    geomCustom 
        {
        numbVerts     4
        numbTVerts    0
        numbTSets     0
        numbElems     1
        numbSets      4
        v 0.000000 0.000000 0.000000
        v 0.050000 0.000000 0.000000
        v 0.000000 0.050000 0.000000
        v 0.000000 0.000000 0.050000
        f 1 2 3 4
        }
    }

You would cut the stuff inside the and paste it into in a seperate text file, like so: numbVerts 4 numbTVerts 0 numbTSets 0 numbElems 1 numbSets 4 v 0.000000 0.000000 0.000000 v 0.050000 0.000000 0.000000 v 0.000000 0.050000 0.000000 v 0.000000 0.000000 0.050000 f 1 2 3 4

This would leave the Poser doc like this for the moment: prop thingy_1 { geomCustom { } }

Now in the new text file, you remove the leading whitespace, like so: numbVerts 4 numbTVerts 0 numbTSets 0 numbElems 1 numbSets 4 v 0.000000 0.000000 0.000000 v 0.050000 0.000000 0.000000 v 0.000000 0.050000 0.000000 v 0.000000 0.000000 0.050000 f 1 2 3 4

Then comment out the numb- directives (you can just remove 'em but I keep them in for informational purposes if I need such info). You can add other ntoes as comments this way, too. # numbVerts 4 # numbTVerts 0 # numbTSets 0 # numbElems 1 # numbSets 4

# thingy.obj file generated by hand by Dodger. Muahaha.
# Last revision 3 May 2003

v 0.000000 0.000000 0.000000
v 0.050000 0.000000 0.000000
v 0.000000 0.050000 0.000000
v 0.000000 0.000000 0.050000
f 1 2 3 4

Then save this to a file, for example, C:Program FilesPoser 4RuntimeGeometriesMyStuffthingy.obj Now totally remove the geomCustom block in the Poser file; it will look like this: prop thingy_1 { }

(which is a null declaration like you see with cameras) Next you add in an objFileGeom declaration (with a storageOffset declaration, at least traditionally), like so: prop thingy_1 { storageOffset 0 0.3487 0 objFileGeom 0 0 :Runtime:Geometries:MyStuff:thingy.obj }

If you're using vim (www.vim.org, still), then you can easily grab the entire block of geomCustom geometry like so:

1. Position the cursor over the opening '{' for the geomCustom definition
2. In command mode (i.e., not insert mode) Press shift-V ('V'). This puts you in line selection mode.
3. press shift-5 ('%'). This will jump the selection to the closing '}' (and it actually counts them, it doesn't just go to the next '}' it finds, but the one that corresponds -- this is one of the main reasons I recommend vim as a Poser file editor, along with my Poser syntax colouration extension available on the vim website)
4. In vim (even on Windows), selecting and pasting are also copying, like in X-WIndows on UNIX/Linux. Therefore, once you have selected the text, it's copied. You can just hit 'Delete' (or 'x' or 'd' both of which also delete in this mode).As a note, the standard CTRL-C, CTRL-V, CTRL-X things don't work in vim. It's designed after UNIX X-Windows interface. This means ctrl-keys are interrupts. ctrl-c doesn't copy in vim, it stops whatever vim is doing (like command-dot does on a Mac)
5. In another vim window, press the middle mouse button (or the mouse wheel or both mouse buttons at once, or just select 'paste' from the edit menu or press, in order, "*p) depending on your mouse's abilities).

Great stuff _dodger . I was pretty sure i had it all down but a walk through is always a added bonus to make sure i didnt miss a step or missunderstand directions. Now i can fix my freebie drum set i have had on hold till i figured out how to get the Geometries out of it and into its proper place.

BTW, if anyone has any corrections of fill-ins for this, I'd greatly appreciate them!

Oh, oh -- Mac! 'uniqueInterp' If this does mean only use integers, would this force MTs to jump from 0 to 1? I must try this. It could be useful for some things. It's worth a try, but I wouldn't put a lot of faith in it. From what I have seen, this only appears to make the dial show integers (at least that's what happens with geomChan dials). If you double-click the dial, you'll see the current setting as a floating poijnt number (and rarely stopped on an integer unless it's at a limit point). As a result, I don't know if this will force Poser to interpret 3.14 as 3, or if it will only show 3 but still interpret it as Indiana Pi. If you experiment with this, please let me know your findings!

Another note, Mac... If you want to make a morph that jumps from 0 to 1, you can always set up the morphed object as an alternateGeom instead and use a geomChan. This would also allow you to put more than one in one dial.

Dodger , Is it safe to remove these statements from the OBJ file . " usemtl side " originaly i was going to make it a figure so that i could make mat files but i changed my mind and its still hanging around the OBJ info .

if the material in question isn't used in the object, it's safe to remove them. If the material is used in the object, you need those in there. What a usemtl directive in an OBJect file (or a geomCustom block) does is sets the current material for all subsequent facets/polys defined until the next usemtl directive. Those are part of the geometry and should probably be there unless you know the material is not used. If you remove all the usemtl directives from an OBJ or geomCustom, you'll end up with only the default material on the geometry. (You can add more materials to the menu but they won't show anywhere, and these will show up under the always-showing default material in the menu). In other words, no, you probably don't want to do that. As a note, if you want to define the order that your materials show up in the Material Editor menu in Poser, you can add usemtl before the first existing usemtl directive in the OBJ file in the order you want them to appear .

'if you want to define the order that your materials show up in the Material Editor menu in Poser, you can add usemtl before the first existing usemtl directive in the OBJ file in the order you want them to appear'

I've become an expert on this subject.

This will work with props, but will not work with figures. I've tried it every which way and nada...

What will work for a figure is to add a dummy part which contains all the materials. I made a cube in uv mapper, deleted 5 sides and kept the remaining side with 36 faces, as a basis for all my dummy figures. Of course you have to name your materials, add it to the figure obj at the beginning, scale it down, lock it, hide it and exclude it from the menu in poser. But of a PITA, really, but it works.

If anyone has a viable alternative, I'm listening.

mac

speaking of that maclean, Maybe we should start a new thread about it I would like to know more about it as well as other peoples views or tricks . Anton said something about it in a post , were he used some kind of clothing dummy figure to do it. Cant remember exactly. I tried it myself and it was a bit a a disaster. Was some kind of ghost figure that kept showing up doing strange stuff. If i loaded up 2 of the prop/figure it even got weirder. If i deleted it the ghosty got left behind.

Attached Link: http://www.renderosity.com/messages.ez?ForumID=10139&Form.ShowMessage=1004558

I posted a couple of threads on this subject a while back. Here are the links.

In order to find anything more than a few weeks old in this forum, go to the bottom of the page and click on 'archive'. That's where everything gets dumped. And there's a lot of good stuff in there.

Anyway, to sum up, adding mtl lists to the obj works with props, but not with figures. The only odd thing is, if you open a prop obj with a material list in it in uv mapper, it has weird extra faces. I spoke to steve cox about this, and I think he will have corrected it in the next version of uvm pro. It was some small glitch in his code.

As far as figures go, you have to make a dummy part and add all the materials to it. You then need to scale it to zero, and hide it from poser. If you want to try this, let me know and I can send you my dummy obj and the cr2 code for the hidden actor.

mac

Attached Link: http://www.renderosity.com/messages.ez?ForumID=10139&Form.ShowMessage=1065374

Dodger, Re changing tracking for morphs, I tried your suggestion. Here's the original tracking trackingScale 6.28856e-005 I changed this to trackingScale 0.4 and it made no difference. I tried a bunch of other settings. Nada. Every time I resave the figure, tracking goes back to trackingScale 6.28856e-005 LOL. It sounds as though it should work, but I tried all this years ago and got nowhere. One thing I have noticed is that the slower MTs all have values over 1, ie. 7.75955e-005, all followed by 'e-005'. Ones that work ok are all values between 0 and 1, like 0.000124928. I've never figured out what the difference is between these 2 types of value. mac

The solution is soooo simple! I found it about a minute after I posted the reply above.

It's no use opening the cr2 to do this (which is what I've always done). You have to do it in Poser, not outside it. Too smart for my own good!

Just double-click the parameter dial to open the dialog, enter the value and save. The saved cr2 will retain that value.

I'd still like to know what that 'e-005' business is about.

mac

Mac, normally, i.e. in all programming languages, this is the format a floating point number has. So, 0.000124928 is equal to 1.24928e-004, and 7.75955e-005 is equal to 0.0000775955! The "e-005" means " ... times 10 raised to the power of -5" as in 0.00001 Willy

Oh cool, jobcontrol. So, the values I thought were greater than 1 are actually less than 1. That explains why the tracking was no faster. Good to know. Thanks. mac

Mac, can you examine the difference between what you set manually in the CR2 and what Poser wrote in its CR2 and post that difference here, if any? Not just that directive value but all of the values in the directive. If nothing is different, look for any different values in the actor's/prop's directives (esp. near the bottom). If not, try resaving again to see if the re-saved version stores slow again. This is how we figure this stuff out B^)

Already did it, dodger. 1. Open a cr2 - modify tracking from 0.000157 to 0.2 - save. Open in poser - value = 0.000157. 2. Change in value poser dialog box from 0.000157 to 0.2 - save to library. Open cr2 - value = 0.2 Re-open in poser - value = 0.000157 That's what I did. Any suggestions? mac

PS No changes anywhere in that geomChannel or the actor. mac

Excellent tutorial Dodger. It answered a lot of questions I had wondered about. Thanks :)

It's probably worth noting in the "Extended Geometry - Dial-a-shape" thing, that the extra geometrys you use will be written into the base figures rsr file.