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 ;D.
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 :D
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimg61.imageshack.us%2Fimg61%2F8348%2Fdoublevisionog9.jpg&hash=99c14e34559ec5273185e8ced5390f40b85ae9f4)
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 :).
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimg292.imageshack.us%2Fimg292%2F7821%2Fnl01jo4.jpg&hash=3cbd36d4eae5bca57752f4a20f3499a0770b6b6a)
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.
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimg180.imageshack.us%2Fimg180%2F5412%2Fpavilionsanstexturesfn6.jpg&hash=b66d656f5e2d2474ec7bc7ac0667de011e3a7527)
The day quickview will remove nitelites from the render, unlike a normal render in Max. Otherwise it's essentially the same thing.
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimg231.imageshack.us%2Fimg231%2F3425%2Fpavilion01sm7.jpg&hash=39bb7ae3ea07f4ea4daaa44d71b1a68d5c9e6fc1)
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
I say, well done that chap!
This is great &apls
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.
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.
Quote from: autoVino on August 23, 2008, 05:38:11 PM
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)...
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...
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 ::)
OMG SWEETNESS!!!!!
repliesToxicpiano: 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:
QuoteOMG SWEETNESS!!!!!
:D :thumbsup:
Max/Gmax Integration and streamlining(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimg145.imageshack.us%2Fimg145%2F9139%2Fbatutilsv2ld5.jpg&hash=5f1fd761ab6126b825411c36929e5d2d26c22c0a)
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(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimg144.imageshack.us%2Fimg144%2F2826%2Fimage1vi8.jpg&hash=15f5a0e1efe65c5de8be9eb10bff71ba38f2f68a)
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:
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimg144.imageshack.us%2Fimg144%2F3628%2Fimage2ed2.jpg&hash=0c72ae60c8aea278804cd75eafd962e0c1d0f92a)
just a small touch. :)
Gmax4Bat4Max(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimg134.imageshack.us%2Fimg134%2F9123%2Fgmaxintigrationun7.jpg&hash=c7ea7841cdd5a89143283b1a15e2485eb78c6a03)
Well now, you didn't think I'd only improve it on the Max side now did you? :D 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(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimg141.imageshack.us%2Fimg141%2F4756%2Frolloutexportag2.jpg&hash=ba1892c22a89b1b251e5b00938dda763e1a6966a)
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 :thumbsup:.
Alright, that's enough for now I'd think, next time I'll cover template files and the batch render process.
Till then,
Chris
:o
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 :P), am I right? Maybe before long we'll see a true BAT for 3dsmax that doesn't require Gmax...
Quote from: Shadow Assassin on August 27, 2008, 03:35:25 AM
:o
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 :P), 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.
Quote
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.
Quote from: Shadow Assassin on August 27, 2008, 04:17:40 AM
... 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. :D
QuoteMaybe 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.
Cool stuff. :)
QuoteThat 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.
would the new version also reautomate the fsh batch build and dat fsh insertion processes???
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.
QuoteThe "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. :P
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
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimg241.imageshack.us%2Fimg241%2F2751%2Fsplinearray2yh1.jpg&hash=7c65b96a99d8a5e4a10c5596a00999753829e902)
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
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimg153.imageshack.us%2Fimg153%2F9881%2Fsplinearrayzaligncy1.jpg&hash=cab23fd5e2201833f647c53d8877684bbe85183b)
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.
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimg241.imageshack.us%2Fimg241%2F8965%2Fsplinearrayzg1.jpg&hash=fd0d1bcef23b52e966e71a75ded08856eabfb5e7)
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
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.
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 :thumbsup:
It is a great tool you have written there...
but...
how is it differs from MAX own default SPACING TOOL:
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fs48.radikal.ru%2Fi120%2F0808%2F23%2F9aed32f162b5.jpg&hash=2c5c4779ad4f5480116ef2b5a2799cccf0e12a30)
?
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.
:D
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?
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...
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:
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fs57.radikal.ru%2Fi157%2F0808%2F85%2F85fd2fd1fbb5.gif&hash=d5073d871109d8de77871f2a4d0ea92590492b43)
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fs56.radikal.ru%2Fi151%2F0808%2Feb%2F1f9331c810dd.gif&hash=2fbc37786adc02c91a480916f729f11e5d2b6c1f)
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
Quotegetting 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.
Quote from: SimFox on August 31, 2008, 04:44:58 AM
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".
QuoteChris, 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 ::)
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
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.
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.
QuoteOne 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.
Quote from: Shadow Assassin on September 01, 2008, 12:57:51 AM
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" :P. 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.
Quote from: callagrafx on September 01, 2008, 01:09:43 AM
I believe the operative word I used was "inordinate" :P. 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. :P
But yeah, I agree, simplification of the process is sorely needed.
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'
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimg216.imageshack.us%2Fimg216%2F4315%2Ffirsttry01ez5.jpg&hash=8d8545669f5dbf8872b052ebd2027ddddecc039e)
'Gizmo Night'
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimg216.imageshack.us%2Fimg216%2F3305%2Ffirsttry02gl0.jpg&hash=68bf7128114c797e465bc72363afa975486d97e7)
'Max Preview'
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimg216.imageshack.us%2Fimg216%2F1695%2Ffirsttry03ns7.jpg&hash=be74e76019a46816b2b4c1e7fb0addbf69fb66ad)
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
very nice damn Chris &apls
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... &ops
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:
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi035.radikal.ru%2F0809%2F3a%2F3090ebf68c74.jpg&hash=cd9e69bd07a8af6f6ab5fce7a44ab1639b697daf)
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?
QuoteChris, 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.
Sorry for the double post, but this one's long enough to warrant it's own ;D. 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:
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimg143.imageshack.us%2Fimg143%2F6079%2Ffncpfr7.jpg&hash=0f0c6c1ecd65b01d738fd2c5fcf5519127114192)
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:
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimg225.imageshack.us%2Fimg225%2F518%2Fhalocb3.jpg&hash=7a68fab9c74a5e46baa372e3087185634a6ca533)
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:
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimg225.imageshack.us%2Fimg225%2F4995%2Ffnlinearwi2.jpg&hash=3bfa3157295bde8f9481718d76677c33cb4f704d)
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:
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):
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimg225.imageshack.us%2Fimg225%2F893%2Ffnnewdb3.jpg&hash=2dea350fae3f78c3e2603bfc30bea26b0a91291b)
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:
--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:
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:
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.
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimg225.imageshack.us%2Fimg225%2F192%2Fcomparisonqb2.jpg&hash=adfc8e9b1547bd757a209fe9fffc888d2c4b87a9)
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 :D), 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 :D.
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:
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimg57.imageshack.us%2Fimg57%2F3643%2Falphaqd4.jpg&hash=b15acafeab36b52e13f9c941460ef1511298cbbc)
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:
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimg71.imageshack.us%2Fimg71%2F1826%2Falphagameya3.jpg&hash=8990fd26f344cc73eb6793bbff850079a8e31b4c)
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 :thumbsup:.
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimg68.imageshack.us%2Fimg68%2F4962%2Ffinalrenderbd8.jpg&hash=51ae66a4c4b5c0a45aa567615164b67481fff157)
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:
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimg95.imageshack.us%2Fimg95%2F7485%2Frunscriptvr9.jpg&hash=5ed86ad364977d5db85bc4980b8f8c9b9b7ba94c)
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.
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:
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fs58.radikal.ru%2Fi161%2F0809%2Fe8%2F0312d8bcf470.jpg&hash=f5f7454f3851e7721e70dfe97147e96bc915287c)
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... :D
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.
Turns out to be not all that critical, I mispelled 'display' actually :D. 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 :D.)
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 ;).
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?
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
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimg75.imageshack.us%2Fimg75%2F9039%2Frenderingoptionsfc3.jpg&hash=237a8438cdc9c5ef3c31a6a8dec874b21b56b8d5)
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.
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimg78.imageshack.us%2Fimg78%2F9361%2Ftrunitepreviewlb1.jpg&hash=dc1c3fdfbcea43070c9f406c2e26b827757925da)
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.
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...
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 :P. 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)
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
Quote from: Chrisadams3997 on September 13, 2008, 07:55:51 PM
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.
Quote from: Chrisadams3997 on September 13, 2008, 07:55:51 PM
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?
Quote from: Chrisadams3997 on September 13, 2008, 07:55:51 PM
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)
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:
myPic.gamma = displayGammaor, in case of export script to add this:
outputBmpCP.gamma = displayGammabefore this:
save outputBmpCPThat'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.
Quote from: Chrisadams3997 on September 13, 2008, 07:55:51 PM
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.
QuoteWhat 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:
QuoteIt 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:
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimg222.imageshack.us%2Fimg222%2F4086%2Fgammacorrectionfr4.jpg&hash=b7462c6c1c665c213131d8fed8166ea538912381)
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.
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 "$Deal"$, 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:
QuoteIt 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
myPic = bitmap 250 250 color:graythe 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:
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:
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:
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fs56.radikal.ru%2Fi152%2F0809%2Fa2%2F19a3cb6eab2a.gif&hash=6a08c41b8a18e29c927471b537fdc6b97bd5c666)
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:
save myPicin 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:
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fs58.radikal.ru%2Fi159%2F0809%2Fc3%2F45e7c1177ada.gif&hash=bd1676085b3e88770ca5033af19b8428df75a9eb)
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:
myPic.gamma = displayGammaplaced before SAVE command is used.
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 &sly (that's where the previous quote came from) and in fact they explicitly refer to the method I used later at another point:
QuotedisplayGamma
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 :D
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.
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.
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.
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
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi95.photobucket.com%2Falbums%2Fl151%2Fcallagrafx%2Fgamma.jpg&hash=3840968237a9a8af87fbca5ae7470e26462b7456)
I'd completely forgotten to check "use image's own gamma" &ops and it defaults to using the system default gamma
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.
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
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.
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.
Quotedon't touch SP3
too late :D, 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.
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 &apls
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.
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:
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi95.photobucket.com%2Falbums%2Fl151%2Fcallagrafx%2Fadadhana_ign3.jpg&hash=9eed8c7d0afb816f70179be9a54757dc42b837ba)
2. Don't like 'em, don't use 'em :thumbsup:. 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" :thumbsup:
1. What is that new "nightlighting facility" that you're talking about?
Taking in acount how people were and still doing it in GMAX is a bit beside the point, since we are are not talking GMAX here.
As far as a MAX concerned nothing new has actually been done. Night Libraries were then from get go. And I have used them first time a LONG time ago, btw made a tutorial on that as well.
My point was about how is a mask derived from the image. As I have said theoretically it had advantages and disadvantages, which I've explained. Often not seeing something on a particular example doesn't mean that the problem doesn't exist.
Light bouncing around is a function of MR and nothing else. and will be there regardless. What is in question is how night view is mixed into the day one.
By now I had done some tests and here are results.
First of all the only working model is a day/night render. but later about that.
Let's do it step by step:
day preview (as a reference):
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fs43.radikal.ru%2Fi100%2F0809%2F9a%2Fbf6d474b9917.jpg&hash=897e26ffaf1846f71abf744c5a421e61a241585c)
here is what supposed to be a Maxis Night preview:
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fi011.radikal.ru%2F0809%2F34%2Fb35d545681e1.jpg&hash=3a4e358b84f6fb34eaac63bfda930ad01ab1cca2)
here is a gizmo one:
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fs54.radikal.ru%2Fi146%2F0809%2Ff8%2F744b6183c210.jpg&hash=549b7547a89863dc7b7e2c0eba4a825892d6ad99)
as clearly can be seen neither is working.
I've mentioned the reason for that earlier. The rig I use is made of MR Sun and IES sky. Settings used don't affect the latter.
and finally Day/Night preview:
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fs39.radikal.ru%2Fi084%2F0809%2F6c%2F9a448a882c0d.jpg&hash=5961ab9a8871322246a1cf79ed41339393cf139d)
Technically it works. But the issues named right in the start of the development process are still very much here with us. That's what you get when you do testing on the models that can not possibly be revealing - like small objects or something covered with high contrast textures, or has very limited surface.
Please don't tell me that this is "realistic". When you do development you suppose to get the system working right. So you need tester that would be most revealing and not concealing.
Additional problem with night preview is that script chocks when the Lighting Rig is merged into the scene..
2. Don't like them don't use them isn't good answer. They are there and there will be people not aware of backward incompatibility and what would you say about supplying one with crocked cameras? I wouldn't used them, for sure, because I can set the scene in no time at all, but at any rate those options aren't there for me, they are there to "help" those who can't do it themselves. As such they wouldn't be even able to understand what and why doesn't work.
As a result things are now MORE complicated and error prone then they were to start with.
3. Of course it can.
4. Well LOD export button is a good addition, hands down! Godsend is stretching it, quite a lot... cutting two mouse clicks out of process done once per export hardly justifies such a label. But it is a welcome addition.
But I spoke about LOD Utilties. Again accepting the need for skin tight lods in soime cases i still don't see the need for such a automation - again cutting off 2 mouse clicks, again once per export. But this time not for free as with LOD export. Here the potential "price" may be quite serious. Many unexperienced users who don't find in them to read Help (of 3dsMax) would be quick to create LODs this way. So we may face a tide of "skin tight" LODs of thousands or even more polygons and what even worse - elements! Who will be checking it? And how? so download couple of such models and when you game come to standstill...
Those who don't know how created skintight LODS manually - shouldn't do it at all. It is some sort of fool proofing. Like when you want to drive you need to get driving license (skill) not just car. Here you give cars to people having no idea of traffic rules and regulations.
5. Well there is certain logic in that, although I have for instance use of such separate buttons and they are used in my truNite script that is also in beta testing at the moment. but I see your logic although hen why to have any of those at all? Why not to limit everything to the export button? Still at any rate either button has to be renamed or some explanation had to be provided as to the new routine. Since neither has been done my question and bewilderment were fully justified.
Forgot to press it, you say? and then had to do manually exactly what? what tediousness are you talking about? all you need is to open new max window input the needed SC4Model name in then press the buttons you forgot to press in the first place. Wouldn't say it to be overly tedious...
6 Direction. Sure.
Night preview. Well as I have demonstrated 2 out of 3 don't work. May it be so that under certain circumstances, still they don't. Making script like this means understanding how things work and taking route - one of very many possible that doesn't have inerited limitations.
I would like to cite an example of the original building Mill.ms script, in particular how it treated the nitelites -
it had been operating with property
.enable
and so limiting users ONLY to max' standard lihgs, since only them had such a property. While would those making script make a use of
.on
property that does exactly same thing and is part of functionality of absolutelly EVERY light this limitation wouldn't be there in the first place.
On more general note I would say that it would be good to talk changes through prier to coding them. This way many of the problems could be avoided and new ways devised based on our collective knowledge.
Nobody knows everything, but together we do more then either of us alone. since we are trying to accomplish here something that would be a benefit to all, to community at large I think it would be a good strategy.
I see the development, As I have said alredy many times, towards more WYSIWYG.
Biggest step here would be divorcing one single export into day and night stages. This way you wouldn't need the special night preview (as you wouldn't need a day one for that matter, just a preview that would show you what you gonna get. Period.
You wouldn't need to remember what night materials go where etc what are the lights should they be on or off, instances or copies etc, etc etc. You would export what you have right there before your eyes.
Additionally it would cut big chunk of code away thus minimizing errors possibility and compatibility issues.
For truNite this process is already realized and it literally takes 2 mouse clicks. By truNite I mean here not use of night libraries/self Illumination etc, but the situation when night views use total mask (same as a day one). Incidentally the process relies on creations of FSHs and their insertion into SC4Modle to be two different stages as it manipulates just created FSHs and auxiliary files to make the night views.
I've created the process for myself so it is centered around truNite - no sun at night concept. But the technique used can be applied to any type of night view and so is the basic principle of WYSIWYG that comes along. With some adaptation it could be used with new night alpha of Chris.
Better still the basic idea behind it could be incorporated into GUI so that you simply tick the need render day or night one and that would be all effort needed.
Quote from: SimFox on September 27, 2008, 11:52:59 AM
2. Don't like them don't use them isn't good answer. They are there and there will be people not aware of backward incompatibility and what would you say about supplying one with crocked cameras? I wouldn't used them, for sure, because I can set the scene in no time at all, but at any rate those options aren't there for me, they are there to "help" those who can't do it themselves. As such they wouldn't be even able to understand what and why doesn't work.
As a result things are now MORE complicated and error prone then they were to start with.
But I spoke about LOD Utilties. Again accepting the need for skin tight lods in soime cases i still don't see the need for such a automation - again cutting off 2 mouse clicks, again once per export. But this time not for free as with LOD export. Here the potential "price" may be quite serious. Many unexperienced users who don't find in them to read Help (of 3dsMax) would be quick to create LODs this way. So we may face a tide of "skin tight" LODs of thousands or even more polygons and what even worse - elements! Who will be checking it? And how? so download couple of such models and when you game come to standstill...
Those who don't know how created skintight LODS manually - shouldn't do it at all. It is some sort of fool proofing. Like when you want to drive you need to get driving license (skill) not just car. Here you give cars to people having no idea of traffic rules and regulations.
You are working on the premise that most people here with the exception of yourself are a bunch on ignorant muppets who don't know how to use the software they have....bit of a bold assumption really, considering the diverse talent that abounds in this community.
Quote from: SimFox on September 27, 2008, 11:52:59 AM
Forgot to press it, you say? and then had to do manually exactly what? what tediousness are you talking about? all you need is to open new max window input the needed SC4Model name in then press the buttons you forgot to press in the first place. Wouldn't say it to be overly tedious...
Indeed...I'm not infallible. I then had to run the batch conversion and add in the FSH files manually in reader, which I found to be extremely tedious.
Quote from: SimFox on September 27, 2008, 11:52:59 AM
6 Direction. Sure.
Night preview. Well as I have demonstrated 2 out of 3 don't work. May it be so that under certain circumstances, still they don't. Making script like this means understanding how things work and taking route - one of very many possible that doesn't have inerited limitations.
I would like to cite an example of the original building Mill.ms script, in particular how it treated the nitelites -
it had been operating with property
.enable
and so limiting users ONLY to max' standard lihgs, since only them had such a property. While would those making script make a use of
.on
property that does exactly same thing and is part of functionality of absolutelly EVERY light this limitation wouldn't be there in the first place.
Dunno what you're using but my copy of the script, the night previews work fine...with all types of lighting, including as I said, self illuminating materials.
Quote from: SimFox on September 27, 2008, 11:52:59 AM
On more general note I would say that it would be good to talk changes through prier to coding them. This way many of the problems could be avoided and new ways devised based on our collective knowledge.
Nobody knows everything, but together we do more then either of us alone. since we are trying to accomplish here something that would be a benefit to all, to community at large I think it would be a good strategy.
Why? This is Chris' work, why should he have to run it past a committee before doing anything? And if I have learned anything from being a member of this community, people talk and talk and talk and talk and nothing gets done....remember the convo at ST about Simtropolis 1000 and Urbs Urbis? Q.E.D.
Quote from: SimFox on September 27, 2008, 11:52:59 AM
I see the development, As I have said alredy many times, towards more WYSIWYG.
Biggest step here would be divorcing one single export into day and night stages. This way you wouldn't need the special night preview (as you wouldn't need a day one for that matter, just a preview that would show you what you gonna get. Period.
You wouldn't need to remember what night materials go where etc what are the lights should they be on or off, instances or copies etc, etc etc. You would export what you have right there before your eyes.
Additionally it would cut big chunk of code away thus minimizing errors possibility and compatibility issues.
For truNite this process is already realized and it literally takes 2 mouse clicks. By truNite I mean here not use of night libraries/self Illumination etc, but the situation when night views use total mask (same as a day one). Incidentally the process relies on creations of FSHs and their insertion into SC4Modle to be two different stages as it manipulates just created FSHs and auxiliary files to make the night views.
I've created the process for myself so it is centered around truNite - no sun at night concept. But the technique used can be applied to any type of night view and so is the basic principle of WYSIWYG that comes along. With some adaptation it could be used with new night alpha of Chris.
Better still the basic idea behind it could be incorporated into GUI so that you simply tick the need render day or night one and that would be all effort needed.
So what's stopping you doing your own version? Indeed if you could implement even some of that to work alongside Chris' scripts, that would be marvellous. Oh, and I just ran a test and what I saw is what I got :thumbsup:
wow, I've got some catching up to do :D. I'll be posting or editing in to this one once I've looked over the posts guys.
Ok, so to start off, I'm still committed to seeing that the community has one script rather than two competing ones (though for time reasons am very likely to release an intermittent addon before we reach that point). That said, moving on into the issues raised:
1.)New night mask generation methodThe MR sun issue I've covered. It takes 30 seconds to open you're light rig, add an IES sun to it, turn it off, and save the light rig--Problem Solved. This is a far easier and more acceptable thing to expect people to know about the script and using it than most of the hoops folks have had to deal with just installing and setting up the original Bat4Max, so I'm not going to lose much sleep over it. I consider the advantages of this system at present to out-weight this one exception having to be made as well. Yes, maybe future lighting options will not be compatible, but we run this risk changing night mode with global tint as well. The system I've developed is very robust at dealing with all manner of light rigs, whether x-ref'd or in-scene, and only requires this one exception.
I also have an idea how to correct this without needing the extra IES sun in the light rig, but I'll get to that when I can.
Now then, the fact as you've noted that it doesn't use the white 'alpha library' textures, and therefore represents the 'brightness' instead of luminosty should, in theory, be an advantage rather than a crutch, as it draws a direct correlation between how much light is reflected from a material (which gives us our brightness) and how that material appears in game. It doesn't really matter how the lighting would act on a white surface when the surface is black, we actually
want the alpha to be representative of the material at that point I think.
Furthermore, many (read most) newer materials developed since Bat4Max was released aren't covered under the script producing the alpha materials. You should have noticed this with MR Arch/design materials. That gives (theoretically) different results depending on the types of materials used. You can have a scene where half of the materials turn white for it, and the other half aren't changed. In fact, I've rendered such scenes, and guess what.
You'd never know the difference if you weren't looking for it! Again, just not losing sleep over it.
Lastly, removing them saves a
ton of time, and allows the optimizations to night material library switching I've added, saving even more.
The pictures you showed SimFox illustrate that the very edges of diffuse light cones still need to drop off a little quicker, that's a mere question of mathematics. Could you send me that model (I know, it's not exactly complicated, but so I don't have to try to replicate the lighting). Furthermore, remember that the edges will have much lower alpha values in game, such that the images produced by that preview only represent some part of the actual falloff that will be seen. That's only the first half of the picture in other words, but I'd still like it to composite as close as possible anyway.
edit; just spotted this
QuoteAdditional problem with night preview is that script chocks when the Lighting Rig is merged into the scene..
You've got to give me more than that when reporting an error. How did you merge the scene and what happened for starters. Without information, I don't know what, if anything, needs fixing.
2.)Template ScenesQuoteI 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.
Impose how? I've been meaning to come back to this issue for a while, so for the sake of those watching, let me explain the concept. Here's what the current 'export' rollout looks like, noting the template button:
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimg141.imageshack.us%2Fimg141%2F4756%2Frolloutexportag2.jpg&hash=ba1892c22a89b1b251e5b00938dda763e1a6966a)
Here it shows a template as selected--by default, one is not and the button reads "Select Template (opt'l.)". If you never, ever, ever touch this button, or bother to learn about it, pressing export will work just like always, using the rendering, lighting, and environment present in the scene at export time.
What a template does is contain within a separate scene file with no geometry in it the three things I just mentioned:
--Rendering Settings (scanline vs. mentalray, antialiasing filter, etc, etc.)
--Environment Settings (bkgrd color, exposure controls, etc.)
--LightCamera Rig
These are used to store some common settings for these that you might use for all your scenes, or perhaps special settings for a series of models being created. I personally have one called something like "ALN_MR_IEScombo_Std" and a "ALN_MR_IEScombo_Draft" that I use most of the time, depending on whether it's a test or final rendering.
If you tend to only produce a few big stand-alone models (for you skyscraper folks out there) where you might use a little different settings for each, this has little merit. As Cal said, "Don't use it", no big deal.
Instead, it's geared towards projects with lots of small or interlocking pieces (to make an example, a series of canals), or for prop making. Situations where you don't need or
want to micromanage the rendering and lighting settings for all of them, and more so, they are
supposed to be the same across them all.
It's extremely easier in these cases to just set the template file before each render and not have to check over and make sure all these things are in place. With mental ray, I tend to play around with settings when I'm taking preview renders, but I want it back at the production settings before I export. No worries, I just set the template. THAT EASY.
It's even more appropriate for batch renders, as you don't need to go through and check that you have each scene at the right settings, the template file set before beginning the render will apply to all the batched scenes.
Now, it's also not, as you implicated SimFox, made "to "help" those who can't do it themselves". Instead, very much the opposite, as the idea is for people to make templates specific for their needs and projects, which assumes a level of understanding of the settings templates deal with. Those that I include are there mostly as examples, partly showing different lighting options, but if they meet some ones needs, then they are free to use them directly.
I apologize if one got cocked off center, but just shoot me a PM or a simple reply which one and it'll be nothing to fix it.
3.) Idea to disable the night window on first run.Good idea and easy enough to implement.
4.) Extra tools and generally buttons.In the main UI, I've been very conservative with buttons, most changes operate within or very close to the original methods. Those that I've added are not hard to very quickly learn, as any BSC beta tester would attest to. So I'm assuming we are talking about the new "ALN Bat4Max Utilities", so let me lay out my plans and philosophy there.
Essentially, this is a repository of 'extras' that will be uploaded separately for those that want them. The primary exception is the "export LODs" button that will be moved to either the export or parameters rollout since it's central to my system of working between Max and Gmax.
Each is developed based on some potential or current need or idea, and they are (generally) all things that
can be done without a script, but are quicker, easier, and in some cases, more reliable, to be scripted. Since it's NOT considered by me to be an integral part of Bat4Max and will be released as a separate entity, what is or isn't in it I'm really not including in the discussions here. Think of it kinda like SimTrop tools only without taking up (sorry anyone that developed them ;)) four rollouts, but just as optional.
5.) DAT FSH InsertJust explained this in passing in the last few posts, as well as mentioned it in the list of new features, but I'll explain in more detail. All that's been done is the very same DOS command that was run previously separately either by the second DAT CMD button or immediately after FSHTool with autoexecute on is now inserted into the end of the Batch file that the FSHTool processing is run from. Not only is this a basic simplification, but it also prevents this DOS command from trying to run before the FSH processing is completed, a problem that had suddenly popped up on my system (read the previous posts) and caused only partial insertion of FSH files.
I've had no error reports from others or problems myself with this new system and I'd propose keeping it for any collaborative builds of Bat4Max. But we certainly might want to rename the button something more logical, any suggestions anyone?
6.) SupportThere are NO plans for a general release without full supporting documentation, but I'm putting that off largely till I've settled on a final release script so I don't have to do too much re-writing.
QuoteOne worthwhile improvements imho, that would make a lot of sense would be changing current situation when SC4Modle filename is saved with the scene.
What did you think needs to be changed about it?
QuoteAlso 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
Not quite sure what you mean, but it's not 'dealt away'. Oh, it's still there, though only on the first rendered zoom (as it's merely kept in memory and reused after that, then discarded after the export is done) and I've turned off the virtual frame buffer for it (it still renders, you just can't see it.) I had tried another approach of just creating a grayscale image and using it instead, which worked at first, but ran into problems on some renders for reasons I haven't fully uncovered. The compromise I came to is satisfactory for me, but if you can remove it wholly without bugs be my guest and we'll build it in.
QuoteOn more general note I would say that it would be good to talk changes through prier to coding them. This way many of the problems could be avoided and new ways devised based on our collective knowledge.
Nobody knows everything, but together we do more then either of us alone. since we are trying to accomplish here something that would be a benefit to all, to community at large I think it would be a good strategy.
Yes, but caution has to be exercised with trying to handle all changes that way. You and I are only working on this in spare time and sometimes it can be a while before one or the other can look over something or reply in detail. Also, many scripting solutions are solved best by working through the solution 'hands-on' so to speak, as many problems are only realized once you've begun working in-depth with producing the script itself.
What I'd propose rather is that for any given major task one of us take the lead on it and find the initial solutions, then send it to the other to be reviewed for potential problems/improvements. Compatibility issues should probably be discussed ahead of time however, as it affects general design principles. It could also be a useful practice to post a general workflow for an idea before hand, but I think that it's most efficient to work on details after rather than generalities before, as what you think could be a good implementation may require a significant reworking once you actually begin hashing it out and testing it.
I'll add in the version check for night windows sometime this next week. That should be awfully straight forward by my recollection (basically identical to what c.p. does at each render checking if the version is above or below 5).
I'll also take up working with the compositing equations once you send me that model.
The next major step will be to look at integrating your WYSIWYG methods (what does that happen to stand for?). My initial thoughts here is that for many batters, taking the step to separate day/night scenes will seem (and indeed be) unnecessary, others would like to embrace it (particularly for TruNite). Standard NiteLiteing practices just generally don't require that. What I'm envisioning (off the top of my head here) is a system similar to the render switching mechanism I've already showed to allow the use of one or the other, but the specifics have to wait until I can look it over and then talk it over with you.