Ran into a stupid issue where Maya puts scientific notation into some of its floats…..  8.5372651e-005  ARRG so annoying.  It was easy to strip out but that kinda of thing is silly.  It makes interfacing with stuff frustrating when all of a sudden there is that kind of number.

global proc makeOpenSpiral()
{

//tweakables
int $points = 180;
float $startRadius = 0;
float $endRadius = 2;
float $xOrigin = 0;
float $zOrigin = 0;
float $yOrigin = 0;
float $degrees = 1800;
//

float $increment = ($degrees/$points);
float $radiusIncrement = (($endRadius-$startRadius)/$points);
float $step;
float $radialStep;

string $cmd = “curve -d 3 “;
for ($i = 0; ($points+1) > $i; ++$i)
{

$step = $increment * $i;
$step = `deg_to_rad $step`;
$radialStep = ($startRadius + ($radiusIncrement * $i));

float $xPos = ($xOrigin + ($radialStep * `cos $step`));
float $zPos = ($zOrigin + ($radialStep * `sin $step`));

// float $yPos = `sin $i`;
// float $yPos = ($points / ($i+1));
// float $yPos = (($i+.01)*.01);
float $yPos = $yOrigin;

$cmd = ($cmd + ” -p ” + $xPos + ” ” + $yPos + ” ” + $zPos);

}

eval $cmd;

}

global proc makePolyCircle()
{

//Tweakables

int $points = 20;
float $radius = 1;
float $xOrigin = 0;
float $zOrigin = 0;
//

 
float $increment = (360/$points);
float $step;

string $cmd = “polyCreateFacet -ch on -tx 1 -s 1 “;
for ($i = 0; ($points+1) > $i; ++$i)
{

$step = $increment * $i;

$step = `deg_to_rad $step`;

float $xPos = ($xOrigin + ($radius * `cos $step`));
float $zPos = ($zOrigin + ($radius * `sin $step`));

$cmd = ($cmd + ” -p ” + $xPos + ” 0 ” + $zPos);

}

eval $cmd;

}

Maya has some strengths and weaknesses as a world editor. A major strength is that its pretty flexible and using mostly .mel scripting you can make it do most things you need. A major weakness is that is meant for working on individual models and it takes some work to make it effective at creating worlds.

OK onto the components you need.

Geometry Exporter: This needs to be done as a plugin. Typically I like to separate the geometry export (or model export) process from a level export. The reason being is that when you use Maya as an editor it really has two functions. 1. creating and exporting of models or instances. 2. the layout and design of levels. They are really two different things. The layout mode is merely a placement mode where you are creating terrain and placing the models you have already created and exported.

I always make the geometry exporter an automatic process. meaning that the system should handle the data management as well as checking in/out of perforce. You can also generate a openGL preview of the model for use later in the design/layout phase.

Level Exporter: This is also a plugin. It exports all the design layout and tagging in a usable level file. Depending on what the programmers want to do this can be the exact same export as the geometry exporter. But from the Maya tool side its good to treat this process differently so that your system can handle all the data automatically.

Instancing : Maya’s instancing sucks rocks. It can easily break and causes a ton of clutter in your level. In the past my solution has been to have the modelers create a special “Icon” of their model that gets tagged as the instance icon. This is merely a single mesh with a special attribute on it to signify that it is an icon. So then when it comes time to import the model into your level the system imports the object and throws out anything that is not an “Icon”. So what you are left with is one single mesh that is representing the whole model. This mesh can now be duplicated around your level. Then when it comes time to export the level exporter can see from the special attribute that it is an instance and it can then take the proper steps to handle it.

Material System: I already covered this in an early post HERE

Tagging: Tagging is what designers and artists add to levels an models trigger game functions. These can be volumes, splines, material properties, etc… Typically a plug in gets created to handle this case. The reason being is that you want special openGL icons for these functions. They show up better in the level and the exporter can easily handle them. Then you can create a series of .mel editors to handle the filling out of their properties.

Decorators : is the term I use to describe things such as grass, garbage, pebbles, etc… Anything that needs a special render pass to handle their sheer multitudes. There are a few ways to handle them, You can have spawners that you place in your level that have attributes on them which direct the “growing” of decorators, you can designate them using materials, or you can paint them directly onto the surfaces using your instancing pipeline. The last option is a bit troublesome bit is also very powerful because your artists and designers have explicit control over where the objects render. You will have to create a system to merge them into large groups tho because Maya begins to choke when there are too many objects in the scene.

Portaling: If your game requires portaling you need to support in the editor. Now I have found that because of the sheer size of today’s levels, they need to be broken up into their individual portals. A typical process would be to lay out the level as basic geometry. Decide that you like the layout then break the level up into its portals and export each piece into a separate file. Then you can work on these separate files without having to load them all into Maya. Then have your level exporter stitch them back together for your engine to read.

Material system. You have to decide what this is going to look like. What shaders your game is going to use, etc. There are a few ways to approach it.

Using a .fx plug in Maya: This is nice in that your model will use your shaders in the viewport. Gets you a very close approximation of the final output. This would seem like the way to go but there are a few issues.

1: Maya and mental ray renders wont like it at all. They will not render correctly using these. That means that for doing PR shots you have to re-create all your stuff as Maya shaders. Gets to be a royal pain.

2: Texture baking does not play nice. So it can make that step much more frustrating.

3: Using mental ray to create lightmaps also gets angry when you use .fx shaders.

Using maya’s materials: This method basically means that you use the maya materials and you create custom string attributes on each material that house the textures that are used by your shaders. Then you plug the output of those attributes into the standard material attributes. The nice thing about this method is that you can now use all of maya’s render features as well as the texture and lightmap baking commands. The downsides are…

1: The viewport does not really reflect how the final ingame model will look. This means that that you are not seeing teh effects of your ingame shaders.

2: If your shaders use multiple UV sets for differnt texture effects, those will not show up in the viewport.

So what should you do? Well that really depends I have create both pipelines for different projects and I am kinda on the fence about it. But my current thinking has me using maya materials because of the issues the .fx method has. The fact that the object does not really reflect the ingame look in the viewport does not bother me much because its a quick export from maya into our game.

In both cases I created a custom material editor that has a bunch of nice features in it. The reason for this is that you can have really tight integration with your data structure and your file management system. In both cases for me it was perforce.

So I wanted to hack into the Maya UV window and change some things. The first thing I wanted to change was the marking menu.

After hunting around I found the texturePanel.mel file in …Maya8.5\scripts\others\

Around line 2095 you will find

global proc textureWindowCreatePopupMenubar( string $editor, string $editorCmd )

This is the command used to generate the popup menu under the standard marking menu.

I tore this out and put in my own menu items. If you tear it all out you will get an error on line 109. There are a few ways to deal with it but the shitty brute force method is to change line 108.

change: if ( $reason == 101 )

to: if ( $reason == 999 )

Now this may cause some later issues I’m not sure yet. But I am exploring as a go.

More on this as a discover things.

The best part about my taste in keyboards is that those style of keyboards are usually the cheapest ones you can find. Huzzah!

The first thing I do when I get a keyboard is to remove the Caps-lock and left Windows key. Why you ask? Cause both of those are a terrible nuisance if you hit them while working in Maya. And really the Caps-lock key is stupid anyway. Who needs to have caps all the time? I MEAN C’MON! Since the majority of the Maya hotkeys I use are situated right around those two it makes sense to axe em.

Mice are an even bigger task for me to find. I hate all the weird shapes and spheres and whatever wacky shit people do to make their mice different or ergonomic. The original Microsoft Intellimouse is the best thing ever in my option. The newer ones are OK but somewhere along the line some flimsiness was introduced into the buttons… yuck! Also no stupid ass tilting scroll wheel. And the scroll wheel must, I repeat, must have a good tactile click when you roll it. no mushy shit allowed here either.

Postie.exe

http://www.download.com/Postie/3000-2369_4-6935052.html?tag=lst-0-1  

After installing to the default location.   c:/postie/

I setup the .mel to use it.

global proc mayaEmail(string $mailServer, string $to, string $from, string $msg)
{

string $progPath = “c:/postie/postie.exe”;

string $cmd = ($progPath+ ” -host:”+$mailServer+” -to:”+$to+” -from:”+$from+” -msg:”+$msg);

system($cmd);

print $cmd;

}

Example Use:

mayaEmail(”mail.test.com”, “test@test.com” , “Maya@test.com” , “\”Your Lightmap Is Done…\”");

Simple as that.   Of course if you change the path where Postie is installed you are gonna have to point the $progPath Variable to where it is located.

This script will create a rocket engine that is controllable with the right trigger of an Xbox 360 controller. Since the script utilizes Maya physics you can do all sorts of fun stuff. You can make rocket powered cars or tow things around or whatever you can imagine with physics. Here is how it works…

It takes the Input from the Right Trigger and maps it to an expression that controls the impulse of an active rigid body. So whatever way the rocket is pointed is the direction the rocket will go. Also I hooked up a particle emitter to it so that when you are applying thrust particles will shoot out. To get started just download the following and follow these easy steps. Also I have included a quicktime of the rocket in action in a few different scenarios. Don’t worry about the frame rate in the video. Fraps causes the frame rate to drop dramatically when you are capturing. I was consistently getting well over 60 fps.

Quicktime of the Rocket in action

Daves Xbox 360 Controller Server

xboxRocket.mel

1) To use first make sure the xbox 360 controller is installed and plugged in…

2) Install the Controller Server

3) Start the Controller Server. (This must always be running before you run the .mel script)

4) Open Maya and run xboxRocket.mel

5) At any time just hit the play button on the maya timeline and start hitting the right trigger on the controller!

Happy Boosting!

Now because its using maya physics you can add all sorts of jumps and whatnot to make a fun rocket playground. Make maya passive and active physics objects and watch them interact with the rocket.

To make a passive physics object (such as the ground or a jump)

1) Place a piece of polygon geometry in the world.

2) Select it and go to the maya Physics module

4) Click on the Soft/Rigid Bodies menu and then select Create Passive Rigid Body

1.   Simplicity:   This can not be overstated.   Your pipeline needs to be as simple as possible.   Everything from directory structure to export pipeline needs to be as simple as possible.   Now of course this can not always be accommodated as we would like but its a good rule to always keep in mind when designing the pipeline.

2.   Automatic:     Everything that can be automated should be automated.   The artists and level designers that are using your pipeline should never have to worry about mundane issues.   They should be focused on making great art and great levels.   If your content people are spending time doing lots of setup and content management then your pipeline is failing you.

3.   Foolproof:     A good system will tell the user exactly what must be done to achieve their current goal and do so while also allowing for allot of flexibility.   Meaning that it should handle everything in a graceful and easy to understand way but also allow people to get into the nuts and bolts of whats going on behind the scenes if they wish.

4.   Data Driven:     Make as many features data driven as possible.   This allows for allot of flexibility and adjustment after the tool has been rolled out.   For example:   Many of the buttons in the UI should be driven by something other than hard-coded .mel.   That way things can be added and tweaked without having to roll-out and new version of the .mel.

5.   Fast:       Make everything run as fast as possible.   If your content people are waiting for the tools then they are non-productive during that time as well as distracted.   Most people will get more done if they are never broken out of their work-groove.

(* I will be adding more commandments later.)

On the good side there are decent Photoshop tools for using it. It can auto-generate Mips. It compresses reasonably well. The 360 can read them easily. They load in Maya.

On the baaaaad side. It is a lossy format so you have to store uncompressed source. (.psd for us). If you keep editing the files and saving them they will get horrible artifacts. Yes Maya does load them but… Menstrual Ray Renderer does not like them at all. In fact if you even have them in your scene it shits out. Why does that matter you say? Well when you are using Menstrual Ray as your light-mapper its a problem. The easy thing to do is just delete all and assign the default Lambert to all your geo. The issue with that is that if you are doing any global illumination or any light model that uses color transmission you no longer have the texture colors to transmit. Boooooooooooooo.