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

[SimFox]

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):


here is what supposed to be a Maxis Night preview:


here is a gizmo one:


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:


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

Code Select Expand

.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

Code Select Expand

.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.

[callagrafx]

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.

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. 

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

Code Select Expand

.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

Code Select Expand

.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.

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.

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 

[Chrisadams3997]

wow, I've got some catching up to do .  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 method

The 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

Additional 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 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.

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:


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 Insert

Just 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.) Support

There 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.

One 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?

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

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.

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.

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.