Chris's Bat4Max Addons and Accessories (and Gmax too)

[Chrisadams3997]

I've been working in free time the last number of weeks (and it shows in the RRP thread, I know) on something of a makeover for our aging Bat4Max V2.0.  Not too much stuff 'under the hood' so to speak, though a few fixes and tune-ups have been in order.  The main goal is to (you'll hear this word a few times I'm sure as I ramble) streamline the process.  Not so much the modeling process(though I've got a few tools there for special 'things'), but the export process, as well as the way we work with lights and light rigs.

Also I had a few little issues and problems that always bothered me, and if you know me, I like to fix things .

But for now we'll start where it all started for me getting into the scripting business:

Night Previews

Simfox of course did a great job creating a working preview script.  For me, that was the first step, next was to integrate it into the Bat4Max lighting environment.  And that environment has two parts: Night and Day

Day is (mostly) easy, so let's walk through what needed to be done to see our model at 'Night' before:

-Set global lighting tint to RGB(128,128,192), this matches the original Maxis night, and is what the night render will be rendered in traditionally.
-Take a preview shot(whether with Simfox's script, or the old 'approximate' methodology)

Simple enough, right.  BUT, it doesn't come very close AT ALL to showing what the lights will look like in an actual render, as the rendering script also affects not only the global tint, but also the nitelite intensity and colors.  It could be like pulling teeth unless you have a LOT of experience with it.

Also, any instanced lights, which is generally a very useful practice to have in order to update a large number of lights easily, would go Absolutly haywire in a render.

So... what did I do.  I've built into the script methods that (essentially):

- Sets the Global Lighting Tint automatically for night previews
- Sets the nitelite color and intensity the same as the export render does (e.i. they render the same)
- Turns off nitelites for daytime previews
- Remembers which lights were on and off when turning nitelites on and off globally.
- Fixes instanced lights (standard and photometric) to appear correctly in BOTH preview and export renders
- Added in Night Material Library support for night preview renders

I'll spare you all the nuts and bolts (unless you really want to know) and move on to the pictures 


scene at day and night.  note the night mats.

Also, hopefully Mas san doesn't mind, but I'd like to show the image he posted testing these.  It shows the same scene as seen in a night preview and the final rendered bitmap.  As you can see, they rendered exactly the same .



QuickView

I've also added a way to get non-game view renders (or useful for previewing part of a large project without rendering the whole thing) that integrates these same features as the previews.  It's interface is just below the preview buttons and is called 'Quickview'.  Pretty straight forward, it has controls for quick access to resetting the render window size and a day and night button.


The day quickview will remove nitelites from the render, unlike a normal render in Max.  Otherwise it's essentially the same thing.


And at night, well... it's self explanatory at this point.

That'll conclude it for now.  Next time I'll be moving on to some of the integration features with Gmax (pssst, I've got a working batch render process), until then, looking forward to some comments and thoughts.

Chris

[callagrafx]

I say, well done that chap!

[toxicpiano]

This is great 
Is there some kind of new Bat4max collective effort going on? Because I know that simfox made some kind of suggestion in the thread over at simtropolis.

[autoVino]

I'm assuming you're using the coordsys mehtod that simfox was working with in the day preview (whcih I"m assuming is compatible with max 2009 mental rayrenderer... as I've heard taht the cropping method has problems).  What would be nice is to try to get that to work with the rendering utilities, if not to re-write them alltogether.  One thing that can be eliminated completely is the use of the night alpha render is the use of truNite is incorperated.  That would save time and lower the chance of crash. 

I think that the largest problem with the current bat4max rendering scripts are the way they're written.  A lot of ths "stuff" isn't really needed and can be optimized, lowering the chance of having problems with variable scope and type (which I"ve found is a huge cause of errors durring rendertime).

but this is a huge step up in the bat4max scripts already. 

[callagrafx]

I think that the largest problem with the current bat4max rendering scripts are the way they're written.  A lot of ths "stuff" isn't really needed and can be optimized, lowering the chance of having problems with variable scope and type (which I"ve found is a huge cause of errors durring rendertime).

The original script was a port of the GMAX script, with some changes to get it to work with Max (originally for Max 4 I think)...

[SimFox]

It is great to see this thread coming into existents although I sort of expected to see it in a different section – one where people who may be interested in the issue would be more likely to find it. None the less...

There are few points I would like to make in relation for this (long overdue) development. The main issues that should be addressed are incompatibilities that started to surface from Max8 (night window issue) and that accumulated over time making Bat4Max as it exists totally incompatible with current versions of MAX (2009 and 2009 design) provided that Mental Ray is used as a rendering engine.

This is far more pressing issue that addition of all sort of bells and whistles. The basics and core functionality have to be taken look at and sorted out. This is also necessary to gain understanding of what and why is there. Without it there is high risk of doing pointless things, or going in circles.

Some of "historical" incompatibilities are "not a great loss" such as Night Windows – they were never particularly good and are easily replaceable by use of night Library with much better result (if I may add). But new ones that had surfaced with introduction of Mental Ray 3,5 in Max 2008 are much more serious. And although they (so far) seem to have no effect to Scanline this is a hardly a reason to feel complacent. Better rendering is the key reason to use Max in the first place and particularly given the fact that Scanline is all but dead – no development of any kind since god knows when – compatibility with MentalRay (and preferably ANY third party integrated rendering solution) is of great importance.

To ensure such a compatibility as well as robust operation of the entire process it has to be closely examined and understood. Insight gained should be used to streamline the entire procedure, remove unnecessary leftovers from GMAX export – both procedures and scripted settings.
Without it the whole thing may, sadly enough, amount to little more than waste of time...

[callagrafx]

I use Max 2008 with MR and have had no render issues with BATs... The problems can be avoided if simply use the target lights that were designed to emulate the ingame lighting.  There's no need to be so complex for a game asset that is only viewed at 96dpi and then only at set zoom levels.  People play the game to simulate a growing city, not stare at a single building day after day.  The other developments Chris has been working on will, in my mind, be "the great leap forward" in the usage of Max for game content.  Add to the fact that very few of us have later versions of Max 

[bixel]

OMG SWEETNESS!!!!!

[Chrisadams3997]

replies

Toxicpiano:  Nothing I would call a collective effort, though since I have incorporated Simfox's previews, I guess in a way.

Autovino:  Yep, the code creating the preview render box is unchanged from what Simfox did with it.  In that respect, the only thing I've changed is improved error handling (it'll catch the error if you haven't set up a rotation yet instead of causing an exception for instance) and the day and night lighting.

As for TruNite, that would assume everyone wanted to use truNite .  I have looked at how to script a TruNite render, and have successfully removed the night alpha render and saved the day alpha as the night alpha for each render.  From there I've run into troubles changing out light rigs during the render process.  Maxscript is very buggy about replacing Xref'ed scenes, it will work perfectly in one spot of code, completely stable, then cause an exception every time in another spot, for no apparent reason.

It's possible that it would have to be split up to where you would do all the day renders first, then all the night renders, or I might be able to get it to work like the present system, but either way it would be an option.

And the rendering scripts, well, if you've ever tried to locate the reason for an error in them, nonetheless try to rewrite part, you know it's a mess .  But it's not a mess that I've tried to untangle as of yet.  Furthermore, since I'm running Max9, and almost always the scanline renderer, I have no idea where or what problems are occuring in newer versions.

SimFox:  Well, there's really not much of a 'proper' spot for this anywhere in the forums for this topic, so I figured I'd make myself a cozy spot right here.  Folks seem to be finding it just fine.

As I told AutoVino just now, I don't have a current version of Max to test out solutions and fixes on, or even have a place to start looking at the issues you're trying to solve.  My main concern is and likely will be making the process of producing game assets inside of Max as efficient and painless as possible.

As for being a waste of time, I'd strongly disagree.  I do think fixing errors arising in newer versions of Max is important, but most users will continue to have and use older versions that work just fine as of now.  As fixes and modernization of rendering code is devised by you, me, others, doesn't matter, It's a much smaller matter to adopt those changes into the structure of my work I'm presenting here.

Bixel:

OMG SWEETNESS!!!!!

Max/Gmax Integration and streamlining


Alright, as promised, I want to move on to some of the ways I've worked on improving the general work flow moving between Max and Gmax when exporting.  These are particularly well suited to those working on props and other situations where a number of small game assests have to be churned out without wasting a ton of time on each (outside the modeling of course ).

Export LOD



This does several things.  Obviously, it exports the LODs for you.  That wasn't so tough before.  But it also automatically exports it to the Gmax rootfolder (or any other folder you set it up to export to) under the current filename.  No hunting around for the folder you want it to export into, and no hunting for the exported LODs in Gmax, or fiddling with naming.  After that it writes the filename it's exported under to a text file(for Gmax to read--more on that shortly) and gives the option to open Gmax:



just a small touch.

Gmax4Bat4Max



Well now, you didn't think I'd only improve it on the Max side now did you?   Looking at the picture above, you'll see a "model name" text field above a new button called "Max Export".  The big difference between this and the normal export option in Gmax is what it uses as the name of the SC4model file name.  Since the common practice is to import the LODs and export them without saving, we typically don't have a name for the exported model file, which leads us on to having to go to the 'plugins' folder and name the model files.  This also leaves us with no 'name' property in the XML file, and therefore no name in a few programs (such as the x-tool ) that read that property. 

Instead, the Max Export button will insert the name entered in the text field for both the model name and in the XML file.  After exporting the LODs, pressing the "Get Dat Name" button will return the SC4Model's name in the bottom text field, from which it can be directly copied and pasted into Max for the final export.  Never have to open the plugins folder.

Additionally, I mentioned that text file that the "Export LOD" button in Max writes to?  Pressing the "get last exported LOD" button will automatically import the last LODs exported from Max (from my "export LOD" button of course) and fill the "model name" field with the name of the file, all ready to export.  And no worries about spaces in the name either, it'll automatically replace them with '_'s.

Max Export Rollout



I won't mention everything new here quite yet, just the most relevant items to our topic.  You'll notice it's had several changes.  The first added button will bring up an open file dialogue box directly in the 'plugins' folder showing all the model files in it.  Selecting one will enter it into the 'model name' field here.  And of course you can still copy and paste into it as well where that's most convenient.

Just in quick summary(I'll discuss it in more detail later), template files are scene files containing only a light rig and renderer settings.  It's basically a way of quickly setting these to standard values used for all models or a similar set of models at export time, overriding scene settings.

My export routine is slightly modified.  I'm sure most Max users have encountered the bug that occurs when re-exporting several times into the same SC4model file.  Something goes haywire in the way FSHtool appropriates the fsh files and we end up with nothing but an ugly checkerboard pattern in game.

The only approach (that I've found) that fixes this--other than making new model files every time we re-render--was to merge the whole scene into a new scene before rendering.  In fact, I'd found myself doing this before every render just for good measure, but it meant always having to reset the light rig, reset the renderer settings, in some cases reset the renderer environment settings.  You can see how this would waste a lot of time when working on a number of models.

The new rendering process is almost identical, except it automatically merges into a new scene (keeping all the present settings in your rendered scene--unless you set a template file) from which it renders, then returns you back to the original scene.  What does this mean:

     -We NEVER actually render INSIDE the actual scene, only in a temporary scene

Which effectively in testing removes any possibility of the dreaded checkerboard, no matter how many times you render to the same SC4Model file .

Alright, that's enough for now I'd think, next time I'll cover template files and the batch render process.

Till then,
Chris

[Shadow Assassin]

 

That sounds great. To be honest, that limitation effectively put me off modelling in 3dsmax (I refuse to use gmax, because it sucks)... all because of the involved process involving Gmax (which sucks), and the high probabilities of errors occuring.

So, this is one step away from removing that dependence on Gmax (which sucks ), am I right? Maybe before long we'll see a true BAT for 3dsmax that doesn't require Gmax...

[Diggis]

That sounds great. To be honest, that limitation effectively put me off modelling in 3dsmax (I refuse to use gmax, because it sucks)... all because of the involved process involving Gmax (which sucks), and the high probabilities of errors occuring.

So, this is one step away from removing that dependence on Gmax (which sucks ), am I right? Maybe before long we'll see a true BAT for 3dsmax that doesn't require Gmax...

Really the process part of GMAX (which does suck, you are right) isn't that much of a hassle, Open, import, save, render.  Takes 5 mins max.

[Shadow Assassin]

Really the process part of GMAX (which does suck, you are right) isn't that much of a hassle, Open, import, save, render.  Takes 5 mins max.

... however, that can blow out extremely quickly if Gmax doesn't do the job right.

[Diggis]

... however, that can blow out extremely quickly if Gmax doesn't do the job right.

I've never had an issue with GMAX.  Plenty of issues with me however. 

[Chrisadams3997]

Maybe before long we'll see a true BAT for 3dsmax that doesn't require Gmax...

That would be cool, but...  the job of creating the SC4Model file from the LODs is performed by a plugin included with Gmax BAT, not within a script.  That plugin doesn't work with Max, which leaves us stuck with Gmax still.  Fortunately, in my experience, most of Gmax's "issues" come up when trying to actually render a lot of geometry, not with rendering the LODs.  I've does a lot of pretty crazy LODs and simple ones as well, and it gets that right everyime, and pretty quickly too.

The way my script is set up between the two,  you're in and out of Gmax, and right back to Max without ever having to close it down.  It's like Gmax was just another utility you had to open within Max to create the SC4Model files before the final render.  That's the goal at any rate.

[Jasoncw]

Cool stuff.   

[Shadow Assassin]

That would be cool, but...  the job of creating the SC4Model file from the LODs is performed by a plugin included with Gmax BAT, not within a script.  That plugin doesn't work with Max, which leaves us stuck with Gmax still.

Can that plugin... dare I say, be reverse-engineered to work with 3dsmax? Or is that well, not allowed?


I have no issues with gmax rendering, but it's mainly the programs that are included in the old BAT4MAX that complicated things somewhat. At least this'd simplify things considerably.

[mightygoose]

would the new version also reautomate the fsh batch build and dat fsh insertion processes???

[Chrisadams3997]

SA: I don't think it's a question of whether it's allowed.  It's a question of how.  It's contained in a .dlx plugin, which I can't find any information on how to do anything other than install one that already exists, which makes me quite doubtful of figuring how to alter one any time soon.

Mightygoose:  yep, that was one of the first things I did.  I've actually removed all need for the deltree.exe.  Autoexecute can always be turned on or off, no external files needed.  The "Clear Outputfiles" button that used to use the deltree.exe function now uses the RD (remove directory) DosCommand instead and clears all the folders in the 'outputfiles' folder, as well as the .bat files that otherwise build up in the BAT root directory.

[Shadow Assassin]

The "Clear Outputfiles" button that used to use the deltree.exe function now uses the RD (remove directory) DosCommand instead and clears all the folders in the 'outputfiles' folder, as well as the .bat files that otherwise build up in the BAT root directory.

I always felt a little iffy about using deltree.exe, since there was always the risk of it blowing up in your face (ie. deleting the entire hard drive)... glad to see it's gone now.

[Chrisadams3997]

SA: That wasn't really much of a danger, as the way the commands for it were set up, it was pretty specific as to what directories it could delete.  But there were certainly other problems associated with it's original implementation that effected the BAT itself.

Spline Array Tool



I was just making a post on this elsewhere, so I thought it'd be a good time to bring it over.  This tool is something I'd thought several times when modeling would be awefully useful.  It's sort of a combination between an array and a loft, as it will array an object along the path of a spline (hence 'spline array'), and hopefully the controls will feel pretty familiar to anyone who has used lofts and arrays before in Max.

Creation Parameters

This looks a lot like the creation parameters for a loft object.  The pick object and path buttons should be self explanatory.  The main difference is that the order they are picked in doesn't matter, as the spline is always the basis of where the objects will be arrayed, regardless of the world position of the chosen object, or whether the object or spline is chosen first.

The "move, copy, instance" buttons detiremine the arrayed objects relationship to the original object, just like these options when creating a loft.  Moving will set the original object to be the first object in the spline, otherwise, the original object is left where it is.

Placement Parameters

Type--determines how the intervals between objects will be determined.

             -Objects: sets the distance in between objects such that the number given will be placed along the path of the spline
             -Interval: sets the given interval as the distance between objects

Position--By default, the first object is placed at the beginning of the spline.  Setting this parameter will place the first object at the point given as a percentage of the total length of the spline

MaxObjects--By default, objects will be arrayed from the starting position at the determined interval until the end of the spline is reached.  Setting this value to a value lower than the current number of arrayed objects will limit the array to that many objects.  If this number is higher than the total number of objects in the array, it will have no effect.

Note:  By using the Position and MaxObjects value, it's possible to set a single instance of the object at any given position of a spline by limiting to one object and setting the position

Additional Options

Adaptive Intervals--This applies only if setting distance by the 'interval' method.  It will round up the interval so that the final object sits at the very end of the spline.  Otherwise, there will usually be some empty space between the last object and the end of the spline.  The 'objects' method always places the final object at the end of the spline.

Align objects to path--When on, this will cause the objects to follow the direction of the spline at that point (see the screen shots above).  If off, all the objects will be oriented in the same direction as the original object.

Align in Z-axis--An optional argument to 'Align objects to path'.  When on, object's Z-axis will follow the slope of the spline.  When off, objects will still follow the spline's XY direction, but will be straight up in the Z-axis


Rotation Angle--Rotates all objects in their local Z by the given angle.  Useful when the objects aren't facing the correct direction.

Offset--Will displace the center of each object to one side or the other of the spline (according to the XY vector of the spline at that point).

Reset Defaults--The dialog saves changes to settings over the course of a session.  This will reset all the values back to their originals

Preview
If you've used the preview button in the standard Max array dialog, this works exactly the same.  Clicking it will turn on the Preview, and it will update as you adjust parameters to show what the final result will be.

OK
Once you are satisfied with the settings, the OK button will finalize them and close the dialog box

Cancel
Will close the dialog box without saving any changes to the scene.  Closing the dialog box with the 'X' in the dialog box's title will do the exact same thing.



This example shows a little of what can be accomplished with this tool, particularly in combination with lofts.  The object has been offset outwards from the center of the helix.  From here an Xform modifier on the original object was used to tilt all of the array objects down (notice they are instances here, so it carries through).  Also, by setting the position at 1%, the first object is offset a little from the beginning of the spline, while setting the interval to give me some space at the end accomplishes the same there.

Finally applying a loft to the original helix spline gives me a rack that the teapots are hanging from.


OK, so that was closer to a help file on it than an explanation of it, but that'll come in handy eventually

Chris