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

[threestooges]

Help file or explanation, that is still one nifty tool you've put together there. That function would have served me well on a few projects (and may make a few others feasible with the time it will save). If that'll be compatible with Gmax, then I'm certiainly going to put it to use. Excellent work.

[Chrisadams3997]

I was a bit skeptical Matt, I figured I'd at least have to change a few things.  But sure enough, I was able to copy the code verbatim from the Max script and use it in Gmax with no problems

[SimFox]

It is a great tool you have written there...

but...

how is it differs from MAX own default SPACING TOOL:


?

I mean of course it's your time... but do you really want spending it duplicating things that are there already?
This is basically something against what I sort of tried to warn right from the start. But certain someone jumped in again that makes me a bit wary about having serious discussion.

I really wish you would manage your considerable experience, talent and enthusiasm a bit better. There are tons of things that should be done and very rarely people of your abilities come along that could do it.

[Chrisadams3997]

 
I figured it was odd that such a thing wasn't included, and sure enough it is, though fairly well hidden in Max's UI .  At any rate, it was a good experience putting it together.  You'd be surprised how much you can learn building something like that.

As for it being my 'time', it doesn't earn me a dang thing doing this other than the satisfaction of making something work or work better.  If a mistake or two is made along the way, I only hope to come out better for it.  This of course was a side project that I did because it was something I saw as potentially useful, nothing more, and I've presented it as such.  The real meat of my project still revolves around increased ease of use, particularly with integration with Gmax.

Now I know you want to work on the rendering script, but as I've said before, I've no way of even testing for compatibility with what you're trying to fix it for.  As I said already too though, I do know how to change out the night alphas with the day ones, and I'm also considering looking at improving the way night libraries are changed out that could improve render times when they are used (no guarantees, but I do have an idea there).  I've also implemented fixes for the 'checkerboard' issue that's always plagued Max4Bat.  So what was it you wanted to talk about?

[SimFox]

That's true practice makes perfect! And with MaxScript it is especially true!

I also think that scripting GMAX and MAX integration in export process is a really handy and practical thing to do!

On the max side though I don't think all of the ideas are really gonna make life easier. I sort of see the idea behind template scenes, but I don't really see the need to script anything there. You just create then and use as needed. Scripting here may be cause of more trouble then benefit.

Another thing is a night previews. Going the way it is done now is a wrong one. There are serious limitations to what and how could be used in such a night export that chop away great chunk of Max functionality. Stating that this is "fine" is odd at least. This is suppose to be development that imply some improvement and movement forward. Making not knowing to be a criteria isn't the way forward.

Current approach to make a NIGHT by manipulating Global Lighting Tint doesn't affect IES sky under Mental ray and doesn't affect and GI in say V-ray. Of V-ray is a 3rd party plugin and quite a pricey one. Not sure if they have any educational licenses like 3ds max.
Saying that "who cares if IES sky isn't affected under Mental Ray" (as I expect certain someone to say) is a defeatist and limiting point of view. Why to bother at all? why not to stick to GMAX. Would people who originally devised Bat4Max share that sort of attitude the very thing would have never come to life! Talking that "we don't all have latest versions" is from the same opera. When original Bat4max was created the current version of Max ws4.2 or 5 and look what we have nowadays.

But I just want to illustrate those two point I just mentioned. First the IES sky. As many know I have been from day one looking to make things different. And been criticized for it quite a bit. Some times very correctly sometimes not... One way is to make difference (the biggest perhaps) is with differnet lighting. Default Rig is so dated and isn't sutable for anything but simple box shapes. Doing anything else in it doesn't go for "compatibility" as anything done with it sticks out VERY bad from normal Maxis line-up of the boxes. So solution that would allow for complex shape and keep the "feel" of the game needed. Going through different solutions I (at the moment) thing that combo of MentalRay Sun adn IES sky works the best. here are reasons why:
1. Mental Ray sun is a "sun" type light that means that its provides limitless parallel lighting. You can place it 1 m above ground or 1000 km as long as angle is right (-474,-352, 575 for south view) it will work. You can even put it inside your building! So it is much easier and less error prone then using direct light where you have to take into account that it covers your model. As Suns go Mental Ray one is preferable to the IES one as it is a area light source (meaning has areal shadows) that look much more natural then a razor sharp shadows of the IES sun or Direct light. Area shadow is very sharp close to the source and gets progressively softer as it moves away from it - just as a real thing does. In reality EVERY light is an area light. MR suns color is dependent on it's position in the sky. And when placed in above mentioned coordinates it has just right hue for the Simcity (it can still be altered somewhat)
2. IES sky. Sky light is a way to go to provide global illumination. It hasn't been used in the days of the SimCity creation as calculations involved were just too much the days computers. But we are in a very different place now. No point to hide from that fact. As Skys go there is a choce of few at the moment - namely Max Skylight, IES Sky and Mental Ray Sky.  The first  -Max Skylight has a significant problem with is as it is basically gives a totally uniformed ligh from all over. It is a problem since it isn't realistic (real sky isn't uniformly bright all around the dome) and secondly it is EXACTLY all around - meaning that it gives light nor from hemisphere but from the sphere! Of course this could be fixed with "ground plane" to block light coming from "under the ground". But still what left is absolutely flat. I can see how some would rush to type "who cares it's just a game" Well anyone doing it (as opposed of "just playing" should) Such a flat light doesn't give you highlight and leaves everything that in the shadow totally shapeless. Of course it is possible to use gradient or HDRI in a map slot, but it also have severe limitations. Gradient couldn't be positioned properly (it will only be top-down) and HDRI... well finding one that fits the game and scripting it rotation... well... Of course when only choice is Max Skylight or none  I would go for skylight, but given other options...
IES and MR skys are directional and are gradients by default. Meaning that spot where the light itself is brightest. Thee "severity of the gradient could be adjusted in both cases (only 3 settings for IES Sky - clear, partially cloudy and cloudy) and in a very wide range for MR Sky. In most normal application Mr Sky is more suitable and easy but in case of the SimCity it's strong (and un-fixable, at least as it seems) turquoise cast makes it problematic to use. IES sky on teh other hand can be of arbitrary color (or to be precise an gradient of arbitrary hue sector). As a result MR sun+IES Sky combo can make an incredibly close (and still superior) lighting solution for the BAT.

This is a rational for looking for solutions that would be working with just such a combo. That said that solution would also work with ANY other as well. Details later.

Next point about "who really needs/have latest versions of MAX" well I know quite a few people who have limited time educational licenses. They are incredible value for money as they cost a pittance and expire as your software becomes obsolete.

Chris, I hope you understand that above paragraphs were not really targeted at you! I have utmost respect to your project!

Just as you've said it is difficult to evaluate if one solution is a working one with only one version of Max at the disposal. And since we are all (well at least most of us9 in a same boat, so tosay we should pull our resources (different versions of max) to see what is working and what is not. Same goes for our different experience fields. Some are better at scripting others at lighting, yet others at modeling techniques etc...
This is the whole reason for such a thread. Not so much as a demonstration window (although I see absolutely nothing wrong with that - credit's due is where credit's due!) But a place where interested people could bounce ideas. Just like with this spline array tool. Again nothing wrong with little exercise) but if you were really needing such a tool and not an exercise drooping a line about developing it may have provided answer where such a ready tool exists in a huge and not always logical Max interface.

Well, that was a loong text... Anyway, I will put together some ideas and publish them here for your and anyone else interested (autovino?) consideration later on.

We clearly have a different vision of the process - that is in fact an asset and not an obstacle, at least it we cat get to work together...

[SimFox]

Bump...
here is my idea about night lighing:

Renderer independent NIGHT VIEW.
As I've mentioned before the current approach of making night view through Global Lighting Tint doesn't always work. But there is another way to get same result that is renderer independent as it is a POST effect.
As other effects it could be found in Effects tab of Environment and Effects dialog:





I'm pretty sure that application of this tool can be easily scripted.
Chris could you check if it exists in your version of max (same actually goes to all interested).
This as I've said will produce EXACTLY same effect as the application of Global Lighting Tint but will work with ANY rendering solution at least as far as I could test. If someone find a flaw here I'll be happy to hear it out.
Again, this is exact duplication of the original effect, meaning it pulls sort of colored glass over the scene that affect everything including lights, night textures, the works. It is how it was done originally.
I think that different approach would be better. Something along the lines that Callagrafx mentioned in his earlier post – getting night view not with such overlay effects but with lights themselves. Advantage of such a solution is tha there is NO need to do anything about nitelites- there will be what they are as none of tehm be affected. Same goes to Night textures – even more problematic spot for traditional Night View.
But for now this is a working solution for IES Sky and Mental Ray

[Chrisadams3997]

getting night view not with such overlay effects but with lights themselves. Advantage of such a solution is tha there is NO need to do anything about nitelites- there will be what they are as none of tehm be affected.

This is actually exactly what I had thought to do when I first considered making night previews, though at the time I didn't know enough about Xref's to do it.  I can access the properties in Xref'd lights from the script to do just that now though.  It solves the issue of readjusting nite lites as you mentioned, it just means that we have to use properties that are universal to all possible lights used, or at least account for any exceptions.

Furthermore, it'll have to be able to work on light rigs merged into a scene as well, which means it's got to be able to tell what lights are in that merged light rig.  As it strikes me, the best way to do that is consider any lights that are children of the TB2CameraHandle as part of the light rig.  This should make sense as the light rig will have to be attached to it in order to rotate, and I'd be highly unorthodox to attach anything else (nonetheless another light) to the camera handle.

From there, we basically have an array that saves the settings of the individual lights before being adjusted.  When the night render occurs we adjust the light rig lights, then set their settings back to those saved beforehand for the next day render.

[callagrafx]

Saying that "who cares if IES sky isn't affected under Mental Ray" (as I expect certain someone to say) is a defeatist and limiting point of view. Why to bother at all? why not to stick to GMAX. Would people who originally devised Bat4Max share that sort of attitude the very thing would have never come to life! Talking that "we don't all have latest versions" is from the same opera. When original Bat4max was created the current version of Max ws4.2 or 5 and look what we have nowadays.

Ok, that one was aimed at me so I shall respond to it...I use MR and photometrics in every aspect of my commercial modelling, so I'm certainly not defeatist nor averse to the principles, in fact I am a big fan of Max's lighting systems...BUT people use Max NOT just for the render engine but because it's modelling and texturing tools are infinitely better.  If it weren't for the team who ported the GMAX scripts to work with Max v4 then we'd ALL still be using GMAX, so I think a little appreciation for what Chris is trying to do is in order.  We DO NOT under any circumstances stifle creativity on this site and certainly do not tolerate unwarranted criticism.  One other thing to bear in mind is that very very few people play in Night Mode so why waste an inordinate amount of time and effort with nightlighting?

As for having the latest version of Max, I think that if you did a poll, the majority of people would be on either v7 or v9, with only a smattering of people (me included) on 2008.  In the words of Captain Spock, "the needs of the many outweigh the needs of the few, or the one".

Chris, I hope you understand that above paragraphs were not really targeted at you! I have utmost respect to your project!

Then who were they aimed at?  I certainly hope it wasn't at me...sucking eggs spring to mind 

[Chrisadams3997]

On the subject of nite lighting, I believe Cal is right in saying that most people who are using Max don't use the most sophisticated lighting techniques available.  But it's worth making any nite lighting solution as compatible as possible so that those who do use and know those systems have the option without undue limitation.

That said, I think it's important for all parties involved in this discussion to stick to the technical issues and leave any personal ones at the door.  Leave anything that's been said as having been said and move on.  Cooperation will get any project much farther along than bickering and fighting.

Now speaking of projects, this thread was started in order to introduce the ideas I've been exploring and developing mostly on my own, though with the help and feedback of a number of BSC members.  I'm still planning on releasing a bulk of it as an addon to the present scripts sometime within the not so distant future, as most of what I'm showing here is finished barring further beta testing.  But now I think we may be building the framework for a collaborative effort towards a whole new version, and as such we should begin discussion at some point of how that will be managed (if it's to be done), what needs fixing (many of these are already established, but some consensus will be in order), and what can be improved.  Given interest, the best spot for that would I think be in the Projects Board, I can talk to David or Jeroni about opening a new child board there, but I'm of course open to other ideas.

But that should only be done given that there is the interest and will to see it done.  In the mean time, I'm perfectly willing to host such discussions in this thread, but when it's time, let's move it.

Chris

[mightygoose]

as much as i would love to see a smoother v3 of BAT4MAX my total lack of expertise in maxscript kindof makes my opinion abit hollow. i would be more than happy to test etc however if said things were ever needed.

[Chrisadams3997]

Well, I think that a big part of such a project is actually the feedback from different users, as you don't need to know anything about MaxScript to know what you think would make Max4Bat better.  In fact I think that it'd be not only important, but necessary, that input come from more than just those working on the code itself.  While there are only a handful of us who have experience with working on the scripts themselves, it's probably advantageous, as it makes keeping track of changes between those working on it easier.

Another big part would be the testers, as anytime new scripts are being written, there a host of things that the writer can overlook, or that may not be compatible with older/newer versions of Max.  The more eyes there are looking at it, the better the chances of catching problems.

[Shadow Assassin]

One other thing to bear in mind is that very very few people play in Night Mode so why waste an inordinate amount of time and effort with nightlighting?

On the other hand, you don't want something that looks sub-standard compared to other buildings that surround the building in question. Really, night-lighting should be given some weighting, albeit not as much as day-time modelling... but it's still important nonetheless... and it gives the BATter more sense of pride, and he/she can say "Well, I've done the best I can do, I'm happy with the building and I'm happy with my night-lighting efforts".

You can't exactly remove one thing and expect everything else to come together in one package - no matter how small the thing is, it's important, too, and more importantly, it encourages creativity. I mean, some NDEX BATs have excellent night-lighting: if the night-lighting part of the BAT wasn't included, can you imagine what it'd be like... it'd be nowhere as good without that night-lighting.

[callagrafx]

On the other hand, you don't want something that looks sub-standard compared to other buildings that surround the building in question. Really, night-lighting should be given some weighting, albeit not as much as day-time modelling... but it's still important nonetheless... and it gives the BATter more sense of pride, and he/she can say "Well, I've done the best I can do, I'm happy with the building and I'm happy with my night-lighting efforts".

You can't exactly remove one thing and expect everything else to come together in one package - no matter how small the thing is, it's important, too, and more importantly, it encourages creativity. I mean, some NDEX BATs have excellent night-lighting: if the night-lighting part of the BAT wasn't included, can you imagine what it'd be like... it'd be nowhere as good without that night-lighting.

I believe the operative word I used was "inordinate"  .  I'm one of those who prides himself on decent nightlighting (have a lookie at my Hospital at night) rather than just light up a couple of windows and say "that'll do". I didn't say only give nightlighting a cursory nod, but there's no need to focus on it at the expense of something else, especially where the render engine comes into play. 

What Chris is trying to do is simplify and to a degree automate the process of exporting a model from Max into the game, as historically it's always been a bit of a mare.

[Shadow Assassin]

I believe the operative word I used was "inordinate"  .  I'm one of those who prides himself on decent nightlighting (have a lookie at my Hospital at night) rather than just light up a couple of windows and say "that'll do". I didn't say only give nightlighting a cursory nod, but there's no need to focus on it at the expense of something else, especially where the render engine comes into play. 

What Chris is trying to do is simplify and to a degree automate the process of exporting a model from Max into the game, as historically it's always been a bit of a mare.

Ah, crap, I missed that.

But yeah, I agree, simplification of the process is sorely needed.

[Chrisadams3997]

So, while I've played around with some different lighting possibilities for previews as discussed above, and have working examples of both ideas SimFox proposed, I'm going to go off on a different tangent today.

I'm working on removing the second rendering pass, instead using just the third one (the one with only nitelite's visible) like what's done in Gmax BAT.  In the Bat4Max scripts, the second pass is used to provide the color night image, then the third pass is used to make the alpha.  In game, the color image acts as a mask over the day render based on the alpha's luminosity of course, only showing through where there are nitelites, night windows, or self-illuminating materials/night materials (unless you're making a truNite building of course.)

What I've done is use the day render and the third pass to build a composite image to use as that color night image in place of doing the separate render.  If anyone's interested in just how I've put that together, I can explain it further, but for now it'll suffice to say it works.  Yesterday I did my first full render using it to test in game.

'Maxis Night'


'Gizmo Night'


'Max Preview'


I've still got a little more experimenting to do with the formula producing the alpha's values from the render.  In this example it's condensed too much of the light's falloff (most noticeably in the large light cone on the right) towards the edges, but I've got a new function that should alleviate that issue.  But I expect it will take some trial and error to find what's optimal.

One result of this is that preview renders will not be as 'exact' of a replica of what will be seen in-game potentially since they'd be based on a one-pass color render, precisely the render that won't be in the export.  That would either have to be conceded, or a day/night preview would have to be used like with Gmax BAT to show the exact expected export (the composited day/night image).  Personally, I'd rather have a separate night preview that's not dependent on doing a day render as well, but I'll follow the general opinion on this one.

Chris

[art128]

very nice damn Chris 

[SimFox]

It is very interesting how I was thinking in the same direction... Have even started to write about it, but I just can't keep it short. So I have several drafts each 5-7 pages long...

Anyway. This is definitely one way to develop Bat4Max. In this case going back to origins. I believe there should be options, particularly when such options are justified. In this case by reduced render times while keeping compatibility with night mods.

how do you generate the alpha? With the use of Lighting render element? I assume that this is what has been done in original GMAX BAT. Or by post processing actual image? First one is faster but may leave to much out (even with inclusion of all other render elements I could think of). Second will surely take everything into account but could be somewhat slow (or course this is relative slow).

Bigger, more challenging issue would be the managing compression. The truth is that GMAX previews aren't what you'll see in game. First of all GMAX preview is antialiased, and actual export is not, also in preview neither the day/night image no the Mask are compressed, so you have beautiful 32(24) bit gradients. in the game you'll have they 8bit renditions. and those would be done no on per pixel basis but rather on per 4 pixels basis.

On top of that you would have to add the issue of blending. The truth is that the method used in GMAX Bat has a fundamental flaw. It's not too often noticed but it is there. here is an illustration from the horse's mouth, so to say eg GMAX:



You can clearly see blending "errors". this how it goes. since the alpha is compressed you don't really have a smooth gradient. In stead of that there is just couple of shades, I believe 4 maximum (I might be wrong about it, but not by much).
So what we have here? The outer ring is the place where tinted day picture is a major part of the blend with small influence of the nitelite. But then comes the stage (and all so suddenly and brutally) where the alpha reaches value where it cuts off the day image altogether, or to be precise, where night image becomes too, or completely opaque. This is where second "ring" starts. But the irony is that this outer reaches of light cone (fall-off area is dimer (since it was captured in total darkness) than the game "night". So you have a bizarre situation when illuminated area is DARKER than non-illuminated.


PS.
Callagrafx, Mr. Spock spoke (no pan intended) about mutually exclusive needs, I, on the other hand, meant all inclusive solution, so quote is irrelevant.
On the other note, one man's too much is another's not enough, so i see no much point in building any argument on such a subjective assertion (inordinate).
Uncalled for personal remark edited out by BarbyW. Please remember this is a discussion thread not for personal comments.
PPS.
Chris, were you involved in a creation of the original Bat4Max?

[Chrisadams3997]

Chris, were you involved in a creation of the original Bat4Max?

Not hardly, I don't think I even owned a copy of SC4 in 2004, as I don't think I got a computer that could run it properly until at least a year after that.  Bryan(c.p., cycledogg, etc.) as I've read on it (and seen in script comments) did the initial leg work of getting it up and running, after which he and raphael ninja improved it over several months, adding in the dat command items and such.

I'm writing up a somewhat detailed discussion on how I'm compositing the images/working with the alpha, but I won't have it done till tomorrow probably.

[Chrisadams3997]

Sorry for the double post, but this one's long enough to warrant it's own .  Those less interested in the mechanics and technical details can jump down to the end.  I'm looking for feedback on the progress so far, so feel free to give opinions .

Compositing

What I'm doing is essentially an extension of how Brian set up the alpha (with the exception of the night window compositing, which is much more complicated) as a post processing of the "third pass" render, which I'll call the "nitelite" render from now on.

He of course used this render solely to produce the working basis for the night alpha image, taking it and modifying the pixels with the mathematical function f(x) = x^.3, where x is the luminosity value of each pixel.  This gives this graph:



For those less math inclined the green line represents the original value of a given pixel before processing, where the difference between that line and the red line (looking straight up) is the amount that the value would be changed by, so that at small values (dim lights, edge of light cone), there's a large increase in value, with the difference decreasing as we approach a value of 256(pure white).

Since the color component came solely from the "second pass" (or night) render, there were no compositing issues, we only have to worry about the alpha.  But that sudden increase at the edge of light cones presented a problem with some lights, particularly when displayed using the gizmo night mode, giving a halo as I've mentioned before, and as seen in this older pic:



Since the color image revealed by the alpha mask is rendered lighter than the gizmo night mod's lighting, anywhere that the alpha mask doesn't reasonably follow the actual falloff of a light cone, we'll get this kind of issue.  Alternatively, if we happened to render the scene with gizmo night mod lighting, we'd get a dark halo around the edges in Maxis night in-game where the darker rendering comes across too strongly.

Now, what I've done is to take the color "nitelite" render and created one  image with it then copied it and set it to grayscale to produce a second "alpha" version of it.  Both identicle exept the alpha is grayscale.  That alpha will be used to both produce the mask to place the color nitelite rendering onto the day render and to produce the final alpha.

But that grayscale image does not initially have enough contrast to function properly in either of these capacities.  That's why c.p. applied the function I mentioned before in the first place.  To fix the flaws in it, I initially used the linear function f(x) = x * 3, which was used for the render shown in my last post:



The obvious flaw, looking at the graph is that it plateaus at an output of 256 where the initial pixel's value is about 84 (or 256/3), with the shortcomings I mentioned in the previous post.  BUT, the slope at the low values works very well to create a smooth falloff at the edges, it just fails closer to the hotspot.

So I worked up a new function, seen in the code as:

Code Select Expand

v = NgtAlpha[iw].v/256
a = 1.00; b = 1.6; c = .0
MaskAlpha = ((3.1 * (v^a)) - (2.1 * (v^(b - c*v)))) * 256

Giving the Graph (compared against the previous functions):



Not worrying too much about how the math is setup for it, it gives me a lot of control over the shape of the curve across the whole function from 0 to 1 (which is then multiplied by 256 to get a pixel value.)  I've been tweaking the variables as I've been testing, and given as seen here, it approximates the linear function's slope at low lighting levels, then levels off as it approaches 1 (like the c.p. function), giving a good approximation of a light falloff cone to build a mask from.

From here, I've found it necessary to boost the luminescence value of the color "nitelite" component, as well as normalize the color cast, which can tend to be more extreme than in renders (meaning, it's usually more 'off white').  I've accounted for these issues here:

Code Select Expand

--boost the luminescence value
Ngt[iw].v = ((Ngt[iw].v/256)^.48) * 256
--color correction
PctDiff = (((Ngt[iw].r+Ngt[iw].g+Ngt[iw].b)/3)-Ngt[iw].b)/256
if PctDiff >= 0 then
Ngt[iw].b += (PctDiff*1.2)^2 * 256
else
Ngt[iw].b -= (PctDiff*1.2)^2 * 256

These have been based on experimentation and observation to optimize them thus far and may change as I do more testing.

We also need to multiply the day render (just a temporary copy of it) by the night color to produce an image to place the "nitelites' onto.  That's easily accomplished:

Code Select Expand

Day[iw] *= (color 128 128 192)

Finally, using the mask alpha (which is just the alpha value essentially, though I've included a line to let me scale it up or down at this point if necessary).  I apply the color from the altered day image * (1 - maskalpha) plus the altered nitelite image * maskalpha to put them together, or:

Code Select Expand

New[iw] = (Day[iw] * (1 - MaskAlpha)) + (Ngt[iw] * MaskAlpha)

Where the variable (New) holds the pixel information that will be written to the new composited night image.



Can you tell which is composited and which is rendered?  The main thing giving the composite away(if you know what you're looking for) is the stronger color cast of the light in it (the one on the left of course here).  I'm still working as neccessary to improve this proccess and find potential errors and problems, but right now it seems to provide a good representation across the various situations, light intensities, and color casts that I've experimented with.

You also mentioned compression.  All of the compositing above occurs without compression (on 24 bit images), except the alpha image which is in 8 bit.  This results in an average of about 30 possible 'shades', as there's an average value difference between each of 8-9 (256/8.5 = apprx. 30).  The bleeding error you show though, I'm guessing through experience (which makes me in no way neccessarily right ), has to do less with compression (though it's likely a factor) and more to do with the curves used to define the mask.  Where these don't follow the natural folloff of the light cone, these types of errors occur, and I'm pretty confident I've done a better job than that .

Alpha Values

Finally, as we see with the halo effect in the gizmo night mod (shown before), the color image is only part of what we see in game.  the final night alpha is also important.  My proccess here uses the same basic curve to produce both the mask alpha (for compositing) and the game alpha.

However, the final values for the two shouldn't necessarily be the same, only the curve used to create them.  The first render I did with the new alpha curve function, I used the same alpha values for both (having not thought about it), but realized after looking at the final game alpha that in most cases it never approaches close enough to full alpha values.  So I did a second render where I doubled the alpha values (from the mask alpha) that are passed on to the final alpha image, so that for the same composited image I got the two following alphas:



Testing them in game side by side, I'm rather convinced that the stronger alpha gives a better representation in game, but I very well might settle on a final value between these two.  Opinions are very welcome here , here's the in-game comparison:



And with the stronger alpha image, I've rendered the dam and control building and lotted them together.  I'm pretty satisfied so far, but there's always room for impovement.  I'm particularly proud that there's no sign of a 'halo' in either night mode, which was a big goal going into this.  Not only can we cut out rendering time, but also improve the render at the same time .




Preview Script

I'm attaching a Day/Night preview script here that uses the same export compositing script I've used for these renders.  It's just the script (no UI) so you'll have to run the script itself from max.  It should also hold people down for a night preview until I've got a full public beta ready .  Just unzip it into your scripts folder (maxroot folder\gamepacks\BAT\scripts) so you can find it.

For those not familiar with how to run a script directly, select 'run script...' from 'MaxScript' in the main menu and navigate to the script you want to run:


You can also select 'open script...' which will open the script code in a window.  If you select that window and press 'ctrl-e' it'll run the script.  Useful when you anticipate running it more than once.

[SimFox]

I think you have done a great job and the direction you're taking is definatelly worth while!

I have test run the script you've posted and have to reports two errors, unfortunately, very serious, you may say critical. Here is an illustration:



1. the composite issue I've talked in the previous message is still with us. As you can see the light area looks more like a cat being naughty on the carpet...
2. the script once run completely hangs up all the bat functionality. Well all related to rendering anything. It can't be run second time, it also prevents from working my preview script as well as all the view controls in preview roll-out. Resetting Camera and Lights doesn't help. Although it pops-up a message box saying that the function had been performed successfully, in fact nothing really happened. Your preview script is, apparently blocks it as well.