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

[Chrisadams3997]

Turns out to be not all that critical, I mispelled 'display' actually .  Last minute change before I zipped it, apparently I have too much faith in my typing skills.  The only reason it seems to disable the bat is because the camerarig is disabled in the script (just like in exports), but if the script is interrupted in the middle before it's re-enabled, you'd have to re-enable it yourself.  The fix is at the bottom of the post (and I actually tested before zipping this time .) 

I've also changed it over to the newer implementation I'm using for the export scripts that doesn't actually turn off the Xref.  Instead it builds a list of lights that:
   A.) exist inside the cameralight rig (or any group in it)
   B.) in-scene lights belonging to the group "Lighting Rig" if it exists
   C.) if there's no "Lighting Rig" group, it instead looks for lights attached to the camera handle (or in groups attached to it)

Then it operates directly on the lights, turning them on or off.  This means, it'll work for Xref or in-scene light rigs, unless someone's done something really screwy.  I also moved the switching lights back on to right after the render, so an error in the compositing section won't leave the light rig lights turned off.

As for the first problem, what kind of light was it, how much intensity did the light have, and were you using logarithmic exposure(with daylight settings)?  The likely cause of a result like that is the light source being way too dim.  I'm also turning on the display of the alpha used in the updated script, as that'll help see any problem areas.

Lastly, I'm including a version of my normal night preview script to compare it to.  But if you're using an MR sun, you'll have to change it out for an IES for it to work.  There's actually a special workaround I've included for that issue, but I'll get to that later.  I've also had to remove references to several external functions I've written to make it a stand alone script, so hopefully I got everything.  If not, I'm sure I'll hear about it .

[SimFox]

Yes I do use tone mapping (not a Logarithmic, but MR Photographic exposure control), it is absolutely essential with HDR lighting. Both MR Sun, which i use and IES SUN - which you suggest, but it isn't really an option as it isn't area light source, as well as their respective sky systems are such HDR light sources.
Nitelite had intensity of 1, for the purpose of this testing I didn't use any decay on it. THe "lightscale" was set to 1500 for non-photometric lights (like on I used in that test).
All-in-all I still believe that the best idea would be to separate day and night exports into to separate stages. It would be much more efficient and intuitive. It will cut down on a lot of procedures that have to be scripted with combined day/night scene and that often led to problems like that. Often it is possible resolve those, but only until someone uses something new or different way to do same old thing and then it starts again.
For the night view I'm still preferring the truNite since it deals away with those absurd shadows and overall can be quite successfully integrated into the game look and I have finished making the script that automates the whole procedure to 1-2 mouse clicks. It takes only 2 render passes and truNite night render is much faster then the day one, when lighting done in a proper way. For instance the project i was rendering yesterday day export takes 35 min and truNite night one only 12 min.
This said I think your night solution has all right to exist and should exist. I for one would love to have it as a alternative. Although As I understand it relies on a day render be done at the same export. But I think that could be handled with temp files for each view that could be stored temporary between day and night passes, because I strongly believe in separation of day and night into two scenes.
One thing that I would really like to see is how would soft fall-of and GI lighting gradients in your new alphas hold after the compression. As I've mentioned before in preview you deal with full color image but in game we have heavily compressed one and not even per pixel compressed.
the pictures you've shown (one of the dumb if I understand it correctly) do seem to show rather abrupt light border. It looks quite passable for the spot light but may be not very appropriate for the general defused lighting. And lighting with spots isn't a proper way now is it?

BTW why would MR Sun have to be changed to IES Sun? Because you can't set arbitrary color to it for the night lighting?

[Chrisadams3997]

Yep, I'm using an MR sun with IES sky myself with logarithmic exposure control.  The reason the MR sun won't work with the standard night previews is exactly as you said, you can't assign an arbitrary color value.  The work around I mentioned before is to build a light rig with both an MR and IES sun at the same position, with the IES sun turned off.  I've placed a function in that recognizes that both are present and turns off the MR sun and turns on the IES sun for night renders as required, them switches them back.

Now, I don't know how the MR Photographic control works.  In logarithmic, the physical scale needs to be set to 80000 (intensity of an IES sun, MR should be close) to properly scale standard lights.  That would basically mean that the light had a defacto multiplier of 1500/80000, or .01875, which would definitely be too low for Batting applications.  The only place it'd ever be at those levels would be the very fringes of a light, but like yourself, I'm also interested in how it holds up under more diffuse situations.  No matter what though, it's a far cry better than what we've been using (and I'll show an example later), so if it's not 100% perfect, I don't think much of anyone will notice(or at least care ).

edit: One more thing I thought to mention on the example you showed.  Given a light source dim enough to create the issue you show, it's in-game alpha would also be very low, so low, you'd hardly notice the difference.  This is what makes the alpha so important in standard night representation in game, the color image is only as good as the alpha used to mask it (since there are two in-game lighting levels it has to blend into), but a good alpha will remove imperfections in the color image.

It's funny you mention TruNite, as that was actually where I was going next with this discussion.  I just finished putting together the scripts to do TruNite renders, though obviously as a day/night render in this case, so I'd really like to see the procedure you're using.  From a scripting perspective there's only three primary differences between a TruNite and standard nite rendering.  The first is the way the alpha is created, which merely needs to copy the procedures used to make the day alpha.  That's pretty straight forward and I'm done with it.  The second is what files it's written to, that's also completed.  The third part is how the lighting is setup, and that's where the real options have to come in.

Having looked over some of yours and others posts on the subject, I came up with several basic options that I built into it to explore the idea.  Three in particular:
  1.) turning off the sun, therefore lighting the scene only with the sky light.  Obviously this only works with sun/sky combos.
  2.) the traditional route of adjusting the color of the light rig lights, which will work for anything but an MR sun.
  3.) turning off all shadows cast by light rig lights


In the same vein, I've incorporated these options into the preview renders, where when the render type is set to TruNite, the options selected will take effect in the preview. 

This one shows a preview of a simple scene with the sun turned off (as shown in the options above)

Like I said, I don't know how this compares to what you're doing in this area, but I've also been giving thought to using separate scenes for each.  I've been looking at ways to reorder the rendering so that all day renders are done first, then all night renders.  The only difficult part about that is making sure the batch file is properly written still, otherwise, I've got the framework setup to reorganize it.  With such a system in place, you could just define a day scene and a night scene and it would swap them out prior to beginning the night render.  However, for many peoples purposes, keeping it all in one scene as I've started here would likely be preferred.  So the keyword I think will be options, options, options.

I've got a few other things I'd like to mention, but I think I'll save it for the next post.

[SimFox]

well, my approach to the scripting had been a bit different.
I try to avoid making artistic choices (although I do have rather strong preferences myself) for the people who BAT and simply automate the menial repetitive tasks.
My truNite script works within the old BAT system and all the issues with setting up lighting are left for the creators, as different versions of Max may result if a very  different lighting setup. Trying to guess all possible contingencies is, IMHO, pointless. And when you understand that on top of that you would have to add the different FG and GI settings people may use, various Color Mapping possible it all become even more so. Also creating a lot of buttons and check boxes has a draw back of cluttering interface, often pointlessly, since they often end up duplicating existing features in Max default interface. It may be confusing and destruct from learning core functionality of the program and, as such, be limiting.
So, the whole truNite "procedure" is reduced to only 2 buttons, and I'm still thinking if it should be done with one button.
It works by using (and abusing) BAT naming structure. What makes the view to be the night one? Or, to be precise what makes the Game thing that given slab is one that should be displayed during the night? Just a naming convention, nothing more. So, my script just alters all the relevant names to fool the game that one of your "day" renders is a night one.
All the settings of lighting (universal like sun and sky) and local on the model itself are left for the creators. In fact, this system doesn't need, really, to be a truNight one, since it is up to anyone to use, or not, the Sun during the night. All it does just applies the full mask.
Of course, there are drawbacks. Or a drawback, as far as I see (the only one) - compatibility with dawn/dask sequence and, (for same reason - total mask) with Darker night type mods. But that is because it was originally designed for truNight that calls for total mask.
But at them moment I value separate day and night export approach even more, since convenience of WYSIWYG approach, great decrease in total export time and much greater stability - never had ANY problem with separate day/night exports - are totally sell it to me (at least).
Right now it is in a beta testing (the script) with few guys on Simtropolis. If you would like to take a look and, may be, give some advise on interface and particularly Fool-Proofing (like warning message etc - you are really good with this sort of things) I could send it to you...

Another point I would like to make is that it probably more prudent to use a bit different model for demonstration purposes.
One you have been using so far are a collection of small elements and as such are hiding all the effect of the things we are here to examine. Plus, it is better to have some neutral grey /"clay" material on top of it, again for same very reason - to see the precise effect of different masking algorithms. Colorful and contrasty "textures" you use now hide the thing.

We should come up with some test dummy. It has to have large surfaces (to show fall-off) both flat and curved, crevices and "holes" to show how algorithms are dealing with bounced light, may be something else, but those two are first things that come to my mind...

[Chrisadams3997]

All good points on it.  Working within a day/night setting as I was of course, you can't do any of those things in-between renders .  I'd love to see what you've done, my emails in my profile.  Maybe a quick overview of where you've added or changed things as well, unless it's well commented.  Ultimately, if we can combine and integrate what we've done between us, we'll be well on our way towards a full new 'version'.  Kind of an abstract term, but I don't think we're there yet .

I've already incorporated the fixes removing references to the plugcfg path, as well as simplified most of the other hoops folks have to go through to install the present version of Bat4Max.  Most of it's absolutely unnecessary .

Tonight, I've also been working on a fix for Lee's (and anybody else's using gamma correction) problem.  Simple function to apply the fileout gamma settings to the final form of each bitmap at export time, where gUseGamma pulls up the 3dsMax INI settings set from the 3dsMax preferences before each render (to make sure gamma correction is on)

Code Select Expand

Fn fnSetGammaCorrection inputbmp fileext:".bmp" savefile:false =
(
local lGamma
local ALN_Gamma
if gUseGamma then lGamma = fileoutgamma else lGamma = 1.0
ALN_Gamma = bitmap inputbmp.width inputbmp.height gamma:lGamma filename: ((getfilenamepath inputbmp.filename) + (getfilenamefile inputbmp.filename) + fileext)
copy inputbmp ALN_Gamma
if savefile do save ALN_Gamma
ALN_Gamma
)


Oddly enough, max (or at least Max9) doesn't seem to save png's with the gamma settings it gives it, but since the final form of all of the renderings is a bmp, there's no problem there anyway, I'd just tested it to see.  I'll be testing it with renders tomorrow hopefully.

Of course I'm also still poking around the issue to find the best way to do it.  In particular I've found that gamma correction tends to clamp off the falloff in the night alphas for reasons I won't go too deeply into.  So still more work to do.

As for test models, I've just been working with what I've got onhand, if you put together a good test model, send it along.  Just make sure everything is compatible with Max9

[SimFox]

Ultimately, if we can combine and integrate what we've done between us, we'll be well on our way towards a full new 'version'.  Kind of an abstract term, but I don't think we're there yet .

well, we aren't quite there yet... 10 times that! There are some starting blocks but a concept is still missing. And doing something without the concept means doing 10 time too much work and still getting no useful and reliable result.
So, I think we should finally start it - discussion on the concept - what we want to implement and WHY - this is very important point. Some of the wishes may be superfluous, or results of misperceptions and some such - so it is important to expose them to critique.

I've already incorporated the fixes removing references to the plugcfg path, as well as simplified most of the other hoops folks have to go through to install the present version of Bat4Max.  Most of it's absolutely unnecessary .

What fixes exactly do you mean? Cause my altered BAT script that does exactly that (removes any need for 3dsMax.ini editing and leaves PlugCFG as it is)  has been available for download for months already. Do you mean that, or have you done something new/different?

Tonight, I've also been working on a fix for Lee's (and anybody else's using gamma correction) problem.  Simple function to apply the fileout gamma settings to the final form of each bitmap at export time, where gUseGamma pulls up the 3dsMax INI settings set from the 3dsMax preferences before each render (to make sure gamma correction is on)

Code Select Expand

Fn fnSetGammaCorrection inputbmp fileext:".bmp" savefile:false =
(
local lGamma
local ALN_Gamma
if gUseGamma then lGamma = fileoutgamma else lGamma = 1.0
ALN_Gamma = bitmap inputbmp.width inputbmp.height gamma:lGamma filename: ((getfilenamepath inputbmp.filename) + (getfilenamefile inputbmp.filename) + fileext)
copy inputbmp ALN_Gamma
if savefile do save ALN_Gamma
ALN_Gamma
)


Oddly enough, max (or at least Max9) doesn't seem to save png's with the gamma settings it gives it, but since the final form of all of the renderings is a bmp, there's no problem there anyway, I'd just tested it to see.  I'll be testing it with renders tomorrow hopefully.

couple of points.
1. simplicity is, I guess, in an eye of beholder... Cause the same very function cam be performed with only one line with 2-3 words (depending on if you count "=" to be a word)
2. I don't see any need to pull anything from the 3dsMax.ini. What you're looking for is a GLOBAL variable. You can refer to it anytime anywhere.
3. I think you're misled by the name of it. fileGammaOut isn't the one to use. It refers to the bitmaps used inside of the material and not to the resulting rendered images. In most cases this mistake will go unnoticed since all the gamma variables tend to be of the same value. But in some cases it may cause a problem. The global you should use is a diplayGamma.
Remember that Lee had said – he likes what he SEES in preview or during the render. What he doesn't like is what is actually saved. So we need to save what we SEE. In other words it is again case of getting WYSIWYG approach into the Bat4Max.
I don't get the point of writing a special function to do that. I may be mistaken and am missing something. Would you care explain to me why do we need a Function to take care of this matter?

I, personally would suggest far simpler and shorter solution. We want to save what we see. We know that by default Max wouldn't apply gamma to saved bitmaps although it (3ds Max) applies it (gamma) to the image when it displays it within the program itself. So we want what we see to be saved. For display purposes gamma is applied on the fly, on top of the actual image – that what deceives the most. Once we know it  is very simple to make sure that the gamma is IN the picture.

So here is what I would suggest to use instead of your function:

Code Select Expand

myPic.gamma = displayGamma

or, in case of export script to add this:

Code Select Expand

outputBmpCP.gamma = displayGamma

before this:

Code Select Expand

save outputBmpCP

That's should be it. If you use gamma it will apply it and before saving the picture. After that, it will be save exactly as you see it. Key point here to understand is that it doesn't save gamma settings WITH or WITHIN the picture, but alter the pixels of the picture so it shall look the right way and then saves is without ANY gamma settings. If you don't use Max gamma correction, picture will still be saved exactly as you see it.

Since this is a max manipulation of the pixels of the image it is independent of the actual picture format. So it will work with ANY image format, including PNG.

It's preferable that user had familiarized him/herself with "gamma preferences" topic in Max help. But this simple line should work regardless of that. It will simply guarantee that what you see in Max will be saved. That's it.

As for test models, I've just been working with what I've got onhand, if you put together a good test model, send it along.  Just make sure everything is compatible with Max9

I'll try to cook something up.

[Chrisadams3997]

What fixes exactly do you mean? Cause my altered BAT script that does exactly that (removes any need for 3dsMax.ini editing and leaves PlugCFG as it is)  has been available for download for months already. Do you mean that, or have you done something new/different

No, exactly that, which is part of my point, I had to go through, find, and build the changes into what I already had on my scripts.  It will be necessary to begin putting together as we define the direction a common script that'll be updated as we build onto it.  But more on that later, I'm a bit sleep deprived right now, but wanted to get to the gamma issue.

I've just been looking at gamma since yesterday, so I certainly wouldn't say my methods on it are perfected yet .  Having read back over the gamma preferences section (which is a tad bit cryptic in places), I'd mistook what the fileout gamma represented (as I'd taken it to mean rendered bitmaps), and the display gamma is the proper one to deal with here.

The problem with just linking it no matter what to the display gamma however is the variable can be a value other than one even though gamma correction is turned off.  Therefore we have to check that it's turned on first, or else we'll be correcting for gamma that's not applied in the first place.  So the idea is to check it once at the beginning of the render and assign it's state to a global variable that tells us whether to gamma correct or not.

As of Max9, gamma cannot be set or changed for a bitmap except when it is created:

It is not possible to change the gamma or pixel aspect of a bitmap once created, though you can copy one bitmap into a newly created one that has a different gamma or pixel aspect to achieve this effect.

You can actually type in image.gamma = x, but it has no impact.  So at some point, it needs to be copied over to a new bitmap with the appropriate gamma set.  Since that bitmap needs to carry over the image size, etc., etc., from the original, and it has to be done with several images, it's a lot easier in the end, and tidy inside the script, to create a function that takes the image as it's argument and does the necessary copying.  In place of saving the final bitmaps produced, this function replaces save, with the savefile option set to true.

Finally, it actually has to apply the inverse (1/x) of the DisplayGamma.    Remember gamma values above 1.0 will darken an image.  Given a display gamma *correction* of 1.8 (as that's what "displaygamma" actually represents), we don't want to set the image gamma to 1.8 as it's already too dark.  The proper correction to match should be the inverse, 1/1.8 or .555, though we just script it as (1/displaygamma).  I took these pictures in testing it:


I was using the fileout gamma under the wrong assumption here (thinking it should affect the rendered bitmap), but the principle is the same, as I'd used it as the image gamma, set to the values I just discussed.

[SimFox]

I can see that you probably sleep deprived as you get few things backward...

Well, let me explain it.

First of all large gamma (value greater than 1) will lighten the image to which it will be applied.
If you don't believe me, although you should , open any image in Photoshop and apply Exposure control to it. It has a a gamma slider, play with it and see that effect changes have on the image. Reversed effect you see in your case is most probably the result of some wrong formula you have used.

Then again, in your pictures it is once more says FileOut. Not sure is that your OWN gammaOut or global gammaOut. Anyway it is full of confusing information. Or, at least, confusing for me.

about this quote:

It is not possible to change the gamma or pixel aspect of a bitmap once created, though you can copy one bitmap into a newly created one that has a different gamma or pixel aspect to achieve this effect.

where exactly does it come from. It looks vaguely familiar, but the matter of the fact is that it isn't true... Or, to be precise, not EXACTLY true. And the degree of this exactness is probably determined by the context of this quote.

Anyway the gist of my solution is as follows:
1. you can't change gamma of created bitmap if you have created it by declaration, like say

Code Select Expand

myPic = bitmap 250 250 color:gray
the gamma of this bitmap is set at the moment of creation. Well, reality is that there isn't any date... To test for this run this simple script:

Code Select Expand

myPic2 = bitmap 250 250 color:gray filename:("c:\\gray.png")

and go and try to find this file on C: You will not find anything, because it doesn't exist. Actual pixels will be created only when you save it. But that is already too late.

2. Render output, is a quite a different vegetable altogether!
if you 'll run this code:

Code Select Expand

myPic = render outputwidth:250 outputheight:250 outputfile:("c:\\testnewgamma.png")
the file with such name and the actual image will appear in said location right away, even prior to be saved. Because real data had been generated during render. So bitmap created this way can be affected by gamma setting change. There is, actually has another supporting "evidence". The process I describe has this GUI representation - Save Image dialog:



Here you have options of applying gamma to the data generated in render. The "problem" GUI defaults at applying "system Gamma" which is in fact "displayGamma". This is an extra step which isn't done when you save by command:

Code Select Expand

save myPic
in that case original gamma (which ALWAYS 1.0) of render output -it is , again, ALWAYS linear is used.
But the main point is that this option is there!
another interesting thing to notice that all those options in GUI become available only if and when the Gamma is activated in Preferences.
Would you disable it there this is a "Save Image" dialog you'll see:



All the gamma options are grayed out. This is an important clue! What it suggests is that when gammaCorrection is turned off in Preferences application of the gamma to the render output will have NO EFFECT! In MaxScrript you can't really "gray-out" commands, you can type in to your heart's content , but they simply shall have no effect.

So in the end, as I hope I've demonstrated it is all quite logical. Problem, of course, that the GUI and MaxSctipt definitions aren't precise enough and often confusing.

And just to answer possible/potential question - YES it works in practice. I haven't run the altered export script as of yet, but mini scripts that render to file, alters (!!important!!!) renderoutput's gamma (not the actual file or bitmap ones) and THEN (!!again important!!) saves it works like a charm!

To make difference between bitmap and render output even more obvious same procedure (assigning different gamma) to re-opned file has No practical effect. Becaus now it is just a bitmap and not live render output. So, once you SAVE it it's set forever. but before you did the render output is open to any gamma manipulation. And such a manipulation works ONLY when Gamma correction is enabled.

So, as a result we DON'T need any functions, of checks to be made. All that is needed is just this simple line of code:

Code Select Expand

myPic.gamma = displayGamma
placed before SAVE command is used.

[Chrisadams3997]

Well... I can assure you, the backwards items can be attributed more to slacking on the part of the guys making the help files in this area, and a little ambiguity in the code.  I got around to testing it with the render() and it does work it Max9, like a charm.  I've also been back over everyreference to gamma in the maxscript reference (which isn't many) and there's not a single mention of it (that's where the previous quote came from) and in fact they explicitly refer to the method I used later at another point:

displayGamma
fileInGamma
fileOutGamma

Lets you get and set Float values that define the gamma preference settings. They contain the corresponding values set in the Gamma tab of the Preferences dialog. You could use these global variables to establish gamma for a MAXScript-created bitmap,

For Example:

b = bitmap 320 240 gamma:displayGamma
render camera:c to:b

This would cause the rendered bitmap to display using the current displays gamma setting if used as a rollout bitmap or button image.

Makes ya wonder what else they forgot to mention

The global variables for this are a bit of an odd bird (or at least so far in my experience), as you can execute the value of it with gamma correction turned off and get the set value (e.i. 1.8 ).  Conventional logic would say it only contains a float value and that it'll execute that same value if run in script.  But it does indeed seem to execute as 1.0 when applied as a gamma, which is very cool, as it does save checking the INI, though it wouldn't have been a big deal otherwise.

Lastly, using the method you showed, it should be applied as 1.8, but you knew that.  Using the method I showed (applying the gamma as a creation parameter and copying to that bitmap), it works inversely as I mentioned and observed.  Looks like the guys who worked on the two different options didn't compare notes all that much.

[SimFox]

one more correction...
it shouldn't be applied as 1.8 (or 2.2 for that matter) but as "displayGamma". This would ensure that what you see in preview or during the render is what will be saved. Using said global is better because it will automatically pull the number one's actually using, so this will be universal.

[Chrisadams3997]

the 1.8 was just an example value of what the global could be set to, I've added it in and tested it within the new 2-pass rendering script and it all works fine so far.

[callagrafx]

A possible explanation as to why Max uses the gamma of 1.0 when it renders via script could be this little option here, on the materials bitmap open dialog box



I'd completely forgotten to check "use image's own gamma"  and it defaults to using the system default gamma

[Chrisadams3997]

Well Lee, I think that only applies to the material bitmaps, not renders though.


As I've been working on these scripts, I've been releasing betas in the BSC for testing.  As I gear up to release the next updated beta version, I'd like to expand it's release to any others interested.  But I'm still keeping it limited at present.  I'd like anyone interested to either post here or PM me.  The conditions of course are that I'd absolutely want to hear about any errors incurred along with error messages, etc., and I'd encourage feedback on the ease of use, the sheer usefulness of included items, etc.

This list is a fairly inclusive, though not exhaustive, list of the various fixes and additions that have been made up to this point:

ALN Bat4Max Addon Beta V3.0
*The version number shouldn't be confused the a Bat4Max version number, but rather indicates only the beta release version.  Version 1 and 2 were released only within the BSC.

Export
--fixed "checkerboard" bug when rendering to the same .SC4model file multiple times

--added template file option for rendering(see associated help files)

--added batch rendering(see help files)

--Added new "1-pass" night rendering.  This process provides similair and in some ways improved results to the original 2-pass system while greatly reducing rendering times.  For night scenes without night materials, it averages about 25-35% faster for a production rendering.

--optimized scripts for night materials so that only objects with night materials applied are affected.  In large scenes with lots of objects, this can potentially cut render times (in addition to the reduction from the new rendering system) by half.

--improved night alpha compositing

--no instanced light bug

--includes option to also use original 2-pass night rendering

--button to select SC4model file directly from plugins folder (instead of copy/pasting its name)

--experimental TruNite rendering(it works just fine, just the details of creating the night scene are un-cemented, as discussed earlier in this threat).  This is very likely to get replaced by and/or merged with SimFox's system as development continues.

Parameters
--optional removal of night windows items from menu

--easy change out of light rigs from a drop-down selection list

Preview
--Day/Night Previews

--option to view night previews at Maxis or gizmo levels (to help visualize how lighting will look in each), as well as dy/night to see what the 1-pass night rendering composite will produce.

--Quick view allows easy rendering of any viewport with size easily set form the rollout.  These will also render according to the night preview settings selected.  Very useful for checking nitelites on a small portion of a large project without needing a full preview, or for more 'artistic' preview renders.

Batch CMD
--auto execute enabled without needing deltree.

--deltree has been completely removed from the program.  The "Clear Output Files" button will remove all directories form the outputfiles folder using the RD (for 'remove directory') DOS command, as well as old batch files from the Bat4Max root folder.

--"Dat CMD" and "FSH Batch Build" buttons merged into one.  This was done for simplicity and to fix a rare bug.

Installation
--No longer requires any INI file editing

--temp and output directories are automatically set now

--if the plugin path is not defined, Bat4Max when opened will automatically ask you to select the Plugins folder from a 'select directory' window.

--no 3dsMax ini file editing of the plugcfg path required(idea and code courtesy of SimFox.)  If you already have a modified Plugcfg path (as required by Bat4Max V2.0), there's no need to change it back, though you may choose to do so.

--TB2startup.ms script placed so it unzips to the correct location automatically(no moving required)

--only thing needed is tho unzip the files to the right location

ALN Bat4Max Utilites
--optional set of tools (similar to Simtrop tools) that give more direct access and editing of several processes and files central to Batting, such as light rigs, template files(new), and LOD creation/export.

--the export option here is integrated to work with the included Gmax4Bat4Max scripts to make it quicker and easier to move form Max to Gmax and back

Gmax4Bat4Max
--An addition to the Gmax interface(nothing removed or changed, don't worry) that is made expressly for exporting LOD made in Max.

--Allows automatic loading(OK, you need to press one button) of the last exported Max LODs.

--Naming of the exported SC4model file without having to save the imported LODs.  When the last exported LODs (as mentioned in the last point) are loaded, the name of the imported LOD is used, though it can be changed before exporting.

--Returns the SC4model name in a text field to be copied and pasted straight into Max for rendering to.


I'll send it out to those interested as soon as I've got them ready.  I'm not adding script at this point (unless I find a bug) until after the release, so the timetable wholly depends on how much documentation I end up writing for it.

As another point, I've also put together a full version for those who haven't installed Bat4Max before, so if that's the case, let me know, otherwise I'll assume to send the patch version.

[Xyloxadoria]

I have a problem with the FSH Batch build hope this new version fixes it. The iamges will render perfectly but then when it goes to be built it completely falls apart and randomly puts the images together in a way tha makes no sense at all. Might be becuse im using MAX 2009. Who knows? Anyway great work here

[Chrisadams3997]

Were you using autoexecute by chance?  That sounds like one of two possibilities, both associated with autoexecute.  That 'rare bug' I mentioned with the Batch CMD is one.  Started happening to me all of a sudden after a windows XP update.  With autoexecute on, it would start running the 'batch cmd' before the FSH tool was finished, therefore only placing in part of the fsh files.

But the most likely cause is from the way the deltree function is implemented when using autoexecute.  I'm not sure why it does it, but it has a tendency to screw up the batch build as well similar to what you're describing.  The new scripts fix both of these issues.

If you'd like, I can send you the beta to see if it fixes it.  Otherwise, turning off autoexecute (if it's on) and running the batch CMD commands manually might fix the issue.

[callagrafx]

Batch build worked OK for me on Max 2008 (XP SP2....don't touch SP3  .  In fact, everything I've tested works like a charm.  I haven't tested the batch export yet, as I had to clear room for a mega animation I'm working on, which meant removing all extraneous models and files.

[Chrisadams3997]

don't touch SP3

too late , though I'd have thought better of it if I realized what it was before I started downloading.  Only problems or oddities I've seen since installing SP3 is that Safari takes a while to load when you first start it now, though it works fine once it is loaded.  Intentional, hmm  .

And I really don't know for sure if it had anything to do with the windows update on my end (it was actually not SP3, but some smaller one a few weeks before), it was just the only major change that had occurred in my computer when that issue showed up out of the blue.  Either way, the new way I'm handling that should be much less prone to any errors.

[jacqulina]

excellent work chris im wondering that pier you show as example any chance of uploading it please,its just what im looking for if you have time thankyou

[SimFox]

I didn't have an opportunity to take a deeper look at the new scripts yet, but here are my first thoughts.

1. New night mask generation method.
It certainly offers advantage of saving one extra render pass, but it also has a Flaw on the design level. I would say a fundamental one.
Problems, however, may arise from the very way new mask generation method decided what shall be masked and what shall NOT be masked.
To explain what my point I have to take you back to the original BAT4Max to show how it works and speculate the reason for such a solution and how it different with your method.
So, in original Bat4Max the Mask pass was done with same very material been applied to the entire scene. Disadvantage of such a solution are obvious – need for extra pass, changing all the mats etc. But why was it there in the first place. What advantages might there be? Well, looking at your solution one pops-up to my mind. With same material all over the mask represents true illumination levels. In your case with original materials in fact this doesn't hold true anymore. What we have here is a brightness mask. But brightness isn't quite same as illumination. And it may cause some problems down the road. Simplest example is when you have something light and something darker next to each other in the same illumination zone. Logically (and according to the original Bat4Max model) both areas will be masked the same. Your method will make mask of different strength or leave the darker part unmasked altogether.
That said you method has one significant, I would also label it as a crucial, advantages over the original one (beyond the time saving). Ironically it stems for the flaw I've described in the paragraph above. Not being pure illumination mask but brightness mask it allows to take reflections into account.
So we arrive to a conundrum. Same very feature that is a problem is at the same time an advantage. Or what shall we consider advantage and disadvantage, and to what degree...
So far it is a purely theoretical point. I would have to do some testing to see what and to what degree holds in  practice.

2. Template scenes.
I was opposed to the very idea from get go and still am. First of all it is wrong to impose this way. Second, the scenes as such are not downward compatible. Third, at least one of the included ones is crooked in a way that makes it less than useful, downright dangerous as people (those inexperienced enough to be sold on the very idea) would get odd results and wouldn't even know why.

3. Idea to disable the night window on first run.
A very good idea, but I think the realization is a may be more forceful, so to say, one. Here is my logic: we know that beyond Max7 Night windows will cause the failure of export,so what reason might there be to give it as an "option". Instead of the question script should perform check of the Max version and if a version 8+ found simply remove Night Windows no questions asked.

4.Extra tools and generally buttons.
I think interface had become way over-crowded. For most inexperienced users it would just breed the confusion and inevitable danger to press wrong button by accident (this is true for everyone, actually) so in interface less is always more.
Besides this I'm totally puzzled about the nature and practicality, or even safety of some of the new features introduced. I've voiced my view of spline array already, so I wouldn't go there. But what about all those LOD Utilities. What exactly are they suppose to accomplish? As I see it they are very dangerous! I see how many will start to export LODS comprised of tens of thousands of polygons ruining the game in the process!

5. DAT FSH Insert
where had this button gone? and why?

6. Support.
I don't know how about everyone else, but the version I've got lucked documentation of any kind. It had, to be fair, instructions how to install the thing, but that's about it. Nothing that would cover any of the new features, for instance, what they do, how they do it and when to use them. But I'm sure that is just a temporary issue.

All that said I fully realize that the beef of this development is a new night masking. I shall test it in more detail and report later.
But I'll still say couple of things now. I, personally see the development of Bat4Max going into a bit different direction. It has to address existing issues and limitations rather than make additions, particularly when they are not much more then duplication of Max features that are already there.
I also have my views on what would actually make it easier to use. But, naturally it is all IMHO. In my mind one major improvement would be making your process WYSIWYG. That means in first approximation, taking day and night export into separate stages.  This wouldn't mean it has to be truNite or any other particular type of night. Not at all. This new night Masking method could be used in a same separate export (provided day views are kept someplace safe). This would also have made the script FAR simpler and less prone to incompatibilities and failures.

One worthwhile improvements imho, that would make a lot of sense would be changing current situation when SC4Modle filename is saved with the scene.
Also that 256x256 perspective shot that is rendered after every view exceeding said size shouldn't have been dealt away. I'm pretty sure it isn't needed at the least no more.

[callagrafx]

Having been one of the main testers for this set of scripts, I'll answer some of those...

1. From observed results, the new nightlighting facility creates excellent nightlighting, especially using a combination of standard lighting and self illuminating textures.  Using MR, photometric lighting and FG/GI, the self illuminating textures reflect off the walls in a realistic fashion...I can't see any problem with the way nightlighting is created, especially when you take into account how people have done it in the past (gmax nightwindows, omg!)  Look here:



2. Don't like 'em, don't use 'em  .  They are optional and designed so that the user can create their own templates.  I don't use them yet but then again, I haven't come across a project yet that I would need to...all I can say is if I had this when I re-did SG's canals, it would have taken half the time.

3. That's a good idea, as long as Max can check itself.

4. The LOD export facility is a godsend IMO.  And the reason for the system creating LODs from selected polys is especially handy for skin-tight LODs, like sea/land based LOTs.

5. Why have two buttons when one will suffice?  I cannot recall a time when I ran FSHMan without immediately following on with the DATCmd function.  Actually, there have been times when I forgot to press either, exited Max accidentally and had to do the whole thing manually...very tedious.

6. Could you elaborate on which direction you think it should go?  Personally, I think Chris has done a bang-up job with this, especially with the previews.  You forgot to mention just how much of a benefit it is to have a preview that automatically drops the lighting, switches nightlibraries and omni's on without having to export...a function so long been asked for.

btw....I think you forgot to say "thank you"