Introduction

This script gives you access to pre-built poly bevel shapes and allows you to apply them at any scale in either group or single mode. You can easily add your own bevels to the preset shape list or remove/refine the ones that already exist. The script is now tightly bound in with a sister script - PolyBevel_Grabber v1.0 - that will let you 'grab' preexisting bevels or draw bevels and then populate the presets.

At its simplest level, you can use the script to fire off specific bevels, shifts and insets (grouped or ungrouped) by binding the script to a key e.g. shift+F10 could fire off a 2cm concave bevel with group on; shift+F11 could fire off a .25cm convex bevel with group off etc.

You could even just use it to fire off a range of preset shifts and insets e.g. shift at 1mm, shift at 2mm etc. The benefit over modo's conventional shift and inset is that it will group or ungroup polys.

However, Poly Bevel Presets comes to life when you use it with a form. Within a form, you can keep the poly bevel interface open and 'build' up combinations of bevels, shifts and insets in real time. If you make a mistake you can just undo and then recreate the bevel. Better still, if you want to record the whole sequence as a macro, you can. Take a look at these demonstration movies to see how you can quickly build up complex shapes. (I'm not suggesting for one minute that you go beveltastic as in the demo movies - they're just bevel heavy to illustrate the features!).

Demo Movies

Basic Usage (QT) 1.5mb

With Group on/off (QT) 1.4mb

With Macro and Macro Repeat (QT) 1.7mb

With Edge Bevel (QT) 0.7mb

What's New in 1.5?

Although there are no functionality changes in Vesion 1.5, the structure of the script has been amended to allow for much more efficient preset capture and creation. The most important change is that the actual bevel data now sits in an external file - PolyBevel_Beveldata.txt - which makes it much easier to amend either by hand or by using PolyBevel_Grabber. There's one caveat, however, and that is if you move the data file then the script will have to relocate it. If it can't find the data file it will ask you to find the path to it.

When you first use v1.5, you'll be asked to specify the path to the directory where the PolyBevel_Beveldata.txt file resides.

The actual format of the data is slightly different, too, in that the Perl hash structure it used in version 1 has been replaced with a simpler structure.

Finally, the form has been tweaked to accommodate temporary presets passed to the script from PolyBevel Grabber.

Using Poly Bevel Presets with the Supplied Form

The form that ships with Poly Bevel Presets gives you access to the standard presets. Here's how it looks in action:





With the panel open, click on any of the predefined bevel shapes to build up your overall profile. Each bevel will be applied at the scale set in the Scale field. It's easy to change this form to incorporate your own bevel shapes or create a new one. I'll outline the steps involved later on.

How to Install Poly Bevel Presets with the Form

There are currently four components to Poly Bevel Presets - the script itself, a small macro to fire the script (I'll explain why that exists later on), the bevel data file and a configuration file to set up the form.

pb_loader.lxm - the macro that fires the script from within a form.
pb_menu.cfg - the file that creates the form.
PolyBevel_Beveldata.txt - the data file for the presets.
PolyBevel_Presets.pl - the perl script itself.

Option 1
The way the form is configured at the moment means that if you place pb_menu.cfg directly into your modo resrc folder (on OSX you'll need to open the modo package contents and place it in the Resources folder), the form will become available to you next time you launch the application. modo automatically loads all config files stored in the resrc/Resources directory.

In the unedited pb_menu.cfg you'll see that the script is called by simply using '@PolyBevel_Presets.pl'. If you then place the script itself in the same directory as modo.app/modo.exe it will be available to the form without any alterations being required. This relies on modo's default behaviour of looking in the application directory for scripts if you prefix the script name with @, but can result in a very cluttered application directory.

Option 2
Alternatively, you can create your own location to store the files but will need to adjust the path locations in the pb_menu.cfg file and the pb_loader.lxm file. The benefit of this approach is that you have control over where you keep your external files and they won't get overwritten should you update modo.

Firstly, you'll need to decide on a permanent location for these three files. I like to keep all my third party scripts in a dedicated third party directory. It doesn't really matter where you put them so long as you make sure you have correct paths in the relevant files.

Once you've got a location then you need to open up the macro file (pb_loader.lxm) and put in the relevant path to the actual script. Make sure you don't mess with the %1 stuff ;-) - it looks weird but is there for a reason.



If the path has a space in it then the script needs to enclosed in curly brackets e.g.

@{/Users/julianjo/folder with spaces/PolyBevel_Presets.pl} %1 %2 %3 %4 %5 %6 %7 %8 %9

On a PC, the paths are written like this:

@{C:\Directory with Spaces\subdirectory\PolyBevel_Presets.pl} %1 %2 %3 %4 %5 %6 %7 %8 %9

Do exactly the same with the third file (pb_config.cfg). You'll see numerous entries containing the path to the macro, each of them needs to be changed to the path pointing to your macro with a single search and replace. Make sure, again, that you use the appropriate path format for either Mac or PC and enclose the script path in curly brackets if you have a space in the path name.


It's easy to mistakenly delete a quote mark or a space, so make sure you find and replace just the path.

Once you've configured the paths in the two files you're nearly ready to roll. Fire up modo, go to File:Config Import and import the pb_config.cfg file you've just amended. This tells modo to load that file (i.e. the menu for Poly Bevel Presets), every time you launch modo.

For ease of access to the form simply assign the form to a key by going into the key editor:



How to Add New Presets to the Script and Access Them with the Form

Use PolyBevel Grabber v1.0 - it was designed to do just that.

To add new bevels manually you need to provide the script with shift and inset values for the the bevel. All the bevel data is stored in the PolyBevel_Beveldata.txt file. Open it with a text editor. Pick a number for a new 'container' - it might be sensible to start any user presets at b100 and then use b101, b102 etc.

Type out the shift values in sequence and then the inset values using exactly the same grammar as the pre-existing bevels- making sure the colons and commas are all in the correct position. The shift values have to be called 'b' and then the number. The inset values have to begin with 'i' as below. The poly bevel tool in modo does the first shift and inset pair, then the next so in b1's case does: shift 0.00618034, inset 0.00097887, shift 0.00557536, inset 0.00284079 and so on.

b1:0.00618034,0.00557536,0.0044246,0.0028408,0.0009789
i1:0.00097887,0.00284079,0.00442463,0.00557541,0.0061803

To change the form in order to add your new bevel preset, it's just a question of going into the form editor, duplicating one of the existing menu entries and changing the argument (the bit of the text that tells the script which bevel to fire) i.e. if you've created a bevel called b101 all you need to do is replace the b'n' entry for your b101 in the duplicated command.

I'll go into what all the other arguments ( user, scaler etc.) mean later on. Essentially, however, it's as easy as that to add new bevels and fire them off from the form.

One important note: if you change the form at all then from that point onwards modo ignores the original form you imported right at the beginning of this process. It creates a duplicate of the form with your amended entries directly in the modo.cfg file or the com.luxology.modo file on a mac. This 'layered' preference system means that the amended form in the config file will take precdence over the original form.

What are the temporary bevels in the drop down menu for?

PolyBevel_Grabber can instantly pass grabbed bevels to PolyBevel_Presets if you assign the grabbed bevel number to one of those in the temporary slots. As it stands, the temporary slots range from 900 to 905 (but you could use as many as you like). If you try and use any of these nothing will happen unless you 'populate' one of the slots with some bevel data from PolyBevel_Grabber. To do that, use PolyBevel_Grabber to grab a bevel and then assign that bevel to one of the temporary slots i.e. 900, 901 etc. The new bevel will then be available indefinitely in that slot unless you remove it manually or overwrite it.

How to Use the Script Without the Form

You can use the script without the form, by hitting F6 and selecting the script itself. On first run, the script will do nothing because you haven't passed it any information - the bevel you want or the size you require. Worse still, you're going to get a barrage of warning messages: a) telling you you need to be in Poly mode with at least one poly selected (if you're not in that mode) and b) several 'General Failure' messages!



The trick here is not to worry. Luxology have released a fix for this error message on Vertex Monkey:

http://www.vertexmonkey.com/scripts_bugfix.php

Alternatively, you can just set the 'In the future' drop down to let modo know you don't want to see this message again. The error sounds dramatic but isn't, it's totally inconsequential. Luxology's bugfix script does simply that - it turns off that specific error message.

After you've run the script once, you'll see in your command history that you have an entry for 'Run Script Implicit'. If you click on it, it will place the command to fire the script directly into the command line:



In my case the command says:

@{/Users/julianjo/Desktop/PolyBevel_Presets.pl}

Remember that as I'm on a Mac, the path format is slightly different to that on a PC and that if the path has spaces you'll need curly brackets. On a PC you'd see:

@{C:\Directory with Spaces\subdirectory\PolyBevel_Presets.pl}

You could copy and paste the path to the script directly into the command line, too. The key to making the script work is to provide it with some 'arguments' - these tell the script what to do. Here's how a set of arguments looks:

@{/Users/julianjo/Desktop/PolyBevel_Presets.pl} 1 b3 groupoff

or,

@{/Users/julianjo/Desktop/PolyBevel_Presets.pl} .25 b7 groupon

I've highlighted the arguments in red to illustrate where they should be placed. The first argument is the scale of the bevel. In example one it's 'standard' size. In example two it is .25.

The second argument tells the script which bevel to use - b1, b2, b3 etc.

The third argument tells the script to either group or ungroup the polys.

The critical thing about these 'arguments' is that there need to be spaces between them ( and a space between the first argument and the script).

The script always expects the first argument to be the scale and the second to be the bevel. The remainder can go in any order. There is one exception to this rule:

@{/Users/julianjo/Desktop/PolyBevel_Presets.pl} last

The 'last' argument always appears on it's own and lets you fire off the last bevel the script invoked.

What About All These 'User', 'Scaler' Arguments?

OK, this is where things get slightly complex - it's really arcane from here on in and I'm not sure how much of this anyone really needs to know.

At the moment, you can't place calls to scripts directly in a popover form like mine without it taking about 10s to appear on my trusty old G4 Mac! To resolve this issue, I've used a small macro (pb_loader.lxm) which calls the script from the form. In calling the script it needs to hand over the 'arguments' that we've just talked about and in order to do this I've had to send the arguments first to the macro, and then to the script. The format for sending these arguments to the macro means that you have to write:

@{/Users/julianjo/Desktop/pb_loader.lxm} 1 b1 user scaler 0 0 0 0 0

We know what the 1 and b1 are doing but the rest must look pretty bizarre. Basically, however, the 'user' argument is only for use with the form and tells the script to use the group bevel setting that the user sets via the form. Similarly, the 'scaler' argument is only there when you use the form to tell the script to look for the scale value set in the form. This new scale value overwrites the one right at the beginning of the argument but the one at the beginning still needs to be there because the macro is expecting the slot to be filled with something. The final five zeroes are empty slots for future arguments (but they do need to be there for now i.e. the nine argument slots need to either have a value or 0 and, again, are only there if you're using the form to call the macro which, in turn, calls the script).

If you choose to use the script via a form and you want to have fields for group bevel and scale, then the format above is how the command should be written. If you're just calling the script from the command line or you're making your own form which doesn't contain fields for group or scale then you can ignore this whole section and just use the conventional format i.e.

@{/Users/julianjo/Desktop/PolyBevel_Presets.pl} 1 b3 groupoff

Send Me Presets

If they're generic enough, please send me any presets and I'll incorporate them in future versions of the script.

Problems

1. The very first time you access the form and before you've tried to invoke the script from the form, you'll see that the scale field and the group bevel field on the form are missing. This is because modo hasn't created these pieces of data yet - it can't do so until you run the script and then, finally, it knows they exist and will display the fields correctly from then on in.

2. This one is under investigation but it looks like any warning messages that the script sends you will not appear when you use it via the form (but will appear if you call it from the command line). A good example is the warning to let you know that you must have polys selected and be in polygon mode - this will appear if you run the script from the command line and you are in edge mode. It never appears if you're using one of the presets on the form and you're in edge mode. The script does nothing. There seems to be a small bug in modo which prevents scripts called by macros from displaying error messages.

Questions

I've changed my paths in my Form e.g. pb_menu.cfg but they're not reflected in modo

Classic. One of the things to look out for if you use Config:Import to keep your custom menus seperate is that if you modify an external form within modo (e.g. you go into Form Editor and change a command or name within the form) the whole form is imported into the modo.cfg (com.luxology.modo on OSX) file and takes precedence over the external form because of the way the XML hierarchy works. Any changes you make to the external imported .cfg file will, from then on, be ignored totally. So, if you change your paths in the external form you'll find that won't be reflected in modo itself. You'll either need to cut the new form entry out of the modo.cfg file and paste it over the old form in the external file or adjust the file paths directly using Form Editor or within modo.cfg itself. Don't be surprised, if you've made many edits to a form over a period of time, to find that there are multiple versions of your form in the modo.cfg file - the very last one will always take precedence (and a new one seems to get created for every edit session).

What's the deal with bevel numbering?

The script was designed to be a container for your own bevel shapes, the presets are simply my suggestions but you could and should (probably) replace them with bevels that suit your own purposes at resolutions you need. Bevel and inset pairs can have any number system you think is meaningful. For my presets, I've used the ranges 1-20 to describe basic shapes, 40-50 to describe panels, 901-905 to be the vacant slots for temporary bevels. The organisation of the bevels is up to you. Provided your b'n' argument calls a valid number the script will work.

To Do

- I'm currently working on how to construct an interface that is icon driven and that lets you hop between the standard presets at fixed sizes and user scaled ones. Evaluating whether to dynamically 'swap' the bevel data file depending on the resolution you require.

- The two most obvious flaws with the script are that you can't see the bevel until you've fired it and you currently have no control over the segmentation of the bevel. I'm looking at providing two or three different popovers - one specifically for subdivision bevels; one for medium res bevels and one for high res.


16th July 2005

Julian Johnson
julian@exch.demon.co.uk