BAT4Blender

[memo 1,473]

23 hours ago, kaimai said:

Blender 4.4+ requires Mac OS 13.3+ (otherwise BAT4Blender returns error "Symbol not found: _cblas_caxpy$NEWLAPACK" on render)

@kaimai That's purely an issue between Blender and the NumPy version bundled with it on macOS. None of the changes I've implemented in BAT4Blender are related to it. You can try do downgrade though. I'm on Blender 3.6 which works just fine.

[kaimai 1,067]

8 hours ago, memo said:

@kaimai That's purely an issue between Blender and the NumPy version bundled with it on macOS. None of the changes I've implemented in BAT4Blender are related to it. You can try do downgrade though. I'm on Blender 3.6 which works just fine.

I am downgraded at the moment (the NumPy error was occurring with 4.4 and 4.5 on rendering before super-sampling was introduced) but it still doesn't seem to be working—however you're right, it's not BAT4Blender related; as far as I can tell there's some kind of permissions error with ImageMagick.

If there are any Mac users on here does anyone have an idea of how to resolve this? (the ImageMagick directory is unquarantined and Blender has full disk access)

edit: Resolved this by reinstalling ImageMagick from source rather than through Macports. Feel free to disregard. Super-sampling is working now.

  Edited August 20, 2025 by kaimai  

[kaimai 1,067]

BAT4Blender question (@memo, @Fargo or anyone else): what's the current workaround for producing nightlights? i.e., once the night scene is created, how do you designate the FSH files as night scenes and merge the SC4model files?

[ACEfanatic02 270]

Hi, all!

I've been getting back into modeling buildings (outside of SC4), wondered if this community still existed, and stumbled in here.  Very cool to see a Blender workflow in active development!

Anyway, I took a stab at improving the lighting rig, based on Jasoncw's post post here: https://www.sc4devotion.com/forums/index.php?topic=17650.140 .

Unfortunately, the reference here has a lot going on, which makes deriving the exact lighting from what we see a lot harder.  Notably:  there's quite a bit of specular reflection here (almost all IRL dielectrics have a specular reflectance around 0.04, this is five times that!)  Second, both sky and sunlight are present, which makes isolating the effect of the sun a lot harder.

If anyone has BAT4Max and wants to help:  a few properly isolated reference shots (18% mid-grey cube, no specular, no sky light) would help a lot in matching the sun color.

Here's my best attempt so far (see attached comparison):

World graph has a background node with color set to (RGB)(0.6, 0.6, 1.0), strength 1.  Sun light has color temperature set to 6500 Kelvin, with tint (RGB)(1.0, 0.95, 0.65), strength 10.

Color management:  View Transform is Khronos PBR Neutral.  (My preference is usually AgX, but it has way more dynamic range than a BAT needs or wants.)  Look is Medium Low Contrast.  Exposure 0.5.

Material is a Principled BSDF with Base Color set to 0.18 (mid-grey), roughness at 0.8, and IOR at 2.618 for the really strong specular.

Note:  all colors listed here are linear sRGB as that's what Blender uses.  Important if you want to replicate the setup in another renderer.

As you can see, the balance of sun and sky is off.  Solving for the sky illuminance is relatively straightforward if we assume a purely diffuse surface.  (Lambertian result for a constant hemisphere light is `E = albedo * light/pi`, which is trivial to solve for.)  All of the sun lit surfaces, however, are also lit by the sky, and so reversing that to find the exact color is a lot harder.

 

[Jasoncw 11,987]

So this is where I had left off at with the lighting rig, but every time I work on it more I end up going around in circles. 

The brightness values, especially on the facade, are very similar. The shadows are darker and less cyan, which was an intentional change. The ground is warmer which is good but the facade is cooler which is bad. 

Attached is the blender file, and also the sky texture that I have for world output. I'm using a gradient because that's how skies are and more importantly, it's better for when there are clearly visible upward facing reflections (skylights, metal roof junk, etc.). Later it should be possible to make this with a gradient ramp within blender instead of a bitmap but blender is confusing so it's a bitmap for now lol. Originally I made this for the Arnold lighting rig for 3ds Max. 

Also, the goal is for textures people have previously made for BATing to be generally compatible with this rig. Needing to tweak the textures will be inevitable but they should be in the ballpark. Also, personally speaking, I usually don't have to change textures from online very much in order to fit into SC4. But like I said I don't have anything set up for blender so I didn't check that (hopefully the lighting rig doesn't just look awful once something other than a clay model is rendered). 

I wanted to have a photometric approach to the lighting, where the sun would have a generally realistic real world value, and the camera would have a generally realistic exposure value, but blender isn't set up for that and when I tried to do it anyway things looked weird. Also, I don't have any tonemapping turned on (Color Management is set to Standard). It should be set to Filmic, but it looks bad, but idk why (tone mapping on and without issue is standard across the other renderers I've dabbled with). I had also tried to redo the lighting rig using blackbody color temperature instead of rgb colors but that didn't really help and I guess it doesn't matter either. 

Also I don't have any denoiser stuff turned on. I feel like denoisers tend to garble details on low resolution images, and also I think having a little noise is ok, since on a building it's just going to look like grime/texture anyway. I also haven't taken any of the pixel filter or supersampling stuff into account. 

There's other settings that I've poked around with that I don't recall offhand. 

But if people could merge their BATs into this scene and see how this lighting rig looks, maybe it will be a good starting point for more adjustments. Blender remains immensely confusing to me so I only have this clay model and not any BATs with different textures and materials to see how things look. 

2025 Blender 03.blend

[kaimai 1,067]

Here's a textured model for comparison. "Default settings" are a world background of (0.56, 0.56, 1.0), sun (1.0, 1.0, 1.0) with no emission node, exposure set to 0.47, no changes to the shadows/distance/anything else

[ACEfanatic02 270]

Thanks for the test scene, Jason!  It's really helpful.

Using it to tweak my lighting rig, I think I've managed to get something pretty solid.  I now have what I think is a good match for the sun light.

I've also moved to using a gradient for the sky.  The horizon is actually set to a very desaturated orange, which helps keep the vertical faces on facades a bit warmer.  This does mean the shadowed sides are also warmer.  IMO this looks a little nicer, as it adds back some contrast, but I'm not sure how well it fits SC4 (I don't have the game right now to test.)

An important consideration with all of this is that, since Cycles is a pathtracer, the ground plane is very important here!  Without it, we lose almost all of the light on the shadowed side (because the bounce light is more important than the direct sky light.)  See the second comparison image for an example.  This is not an insurmountable problem, we can make objects/materials only show up for secondary rays, but it's worth keeping in mind.  (One possibility, of course, is to tint the reflector material to get more / less bounce and shift its color.)

At this point I could tweak endlessly (I think horizontal surfaces look a bit too red), but it's a pretty close fit as is.

[ACEfanatic02 270]

Layered the render over a screenshot for some in-game comparison (this is using the invisible ground for bounce light):
 

In-game it looks like the shadows just aren't dark enough.  There's a lot more contrast between the lit and shadowed side of all of the Maxis buildings.  Not sure what to do about that.  A darker, bluer sky might do it.  OTOH, this also implies that the 3ds stuff doesn't really match the game lighting ether, as it isn't that blue.

Textures probably hide the difference reasonably well, as long as they stick to a cooler color balance?

[Jasoncw 11,987]

BAT4Max uses the Sun/Sky system. The sun color is automatically based on the angle of the sun (so if you point the light at a low angle it will give a warm sunset color), and the sky is procedurally generated as well, and iirc also based on the sun angle. Normally the sun is positioned with time and location info, but in BAT4Max it has the position needed to have the right shadows in the lighting rig. And then the sun has some non-physical tuning parameters which were used to adjust it to fitting better for SC4. 

Below is just a render I made by making a new camera that points sideways to the south. The bright bright area is closer to the sun. Also this does get warmer closer to the horizon and so indeed that looks like the right direction for ours. 

And then there it is again pointed straight up. 

This sky color is responsible for the excessively cyan color that roofs and other things reflecting upwards get. So seeing this might be insightful for working on the new rig, but it's also something that needs to be changed in order fix a problem with the BAT4Max rig. Also, Blender has a Sun/Sky system which is similar and that might give better results than our manually made gradients. 

And then this is an 18% grey cube, with an Arch & Design material with the reflectivity and glossiness both set to 0, which should be roughly equivalent to a Roughness of 1. And then with the sun on and the sky off, and then with the sky on and sun off. 

And yes the ground plane is very important. I'm guessing a lot of people don't make a ground plane but it's always been how it's supposed to be done and there's even a button for making one in BAT4Max. I personally use screenshots from the game cut up into a mosaic (which also tends to give the walls of the BAT a subtle splash of color which helps it fit the game's color palette nicely). And then I model and texture the road and sidewalk around the building so that nearby reflections reflect the expected in-game environment as well as possible. 

[Jasoncw 11,987]

34 minutes ago, ACEfanatic02 said:

Layered the render over a screenshot for some in-game comparison (this is using the invisible ground for bounce light):
 

In-game it looks like the shadows just aren't dark enough.  There's a lot more contrast between the lit and shadowed side of all of the Maxis buildings.  Not sure what to do about that.  A darker, bluer sky might do it.  OTOH, this also implies that the 3ds stuff doesn't really match the game lighting ether, as it isn't that blue.

Textures probably hide the difference reasonably well, as long as they stick to a cooler color balance?

When the BAT4Max rig was made the goal was to fit within the general art direction of the game, but not to try to copy the gmax rig (which also isn't possible to match, because gmax doesn't use ray tracing and the shadow colors are the same regardless of the brightness of the materials). The gmax rig is awful, and also Maxis used several different lighting rigs across their buildings, which seem to be different rigs than what they provided to us in gmax. 

Also at this point the majority of BATs in people's games are BAT4Max BATs, so that should be the starting point for matching. But personally in my rig making I wanted to make the shadows a little darker and less purply, a bit closer to gmax shadows, which I also think would make the BATs look less "plasticky". 

@kaimaiIt definitely looks like it's in the ballpark to me (and nice for me to see after looking at this grey BAT so much!). How is it for you in terms of how the textures look compared to how you are expecting them to look and how they look in Photoshop? Like in terms of the workflow does it feel intuitive and artist friendly? I'm guessing ultimately right now what we're going to get is a starting point that we'll have to iterate on after actually using it in BATing for a while. 

[ACEfanatic02 270]

2 hours ago, Jasoncw said:

This sky color is responsible for the excessively cyan color that roofs and other things reflecting upwards get. So seeing this might be insightful for working on the new rig, but it's also something that needs to be changed in order fix a problem with the BAT4Max rig. Also, Blender has a Sun/Sky system which is similar and that might give better results than our manually made gradients. 

I did have the same thought about using the various procedural sky models, but there are a few issues:
1.  all three of the options produce a slight green tinge.  AFAICT this is accurate, but clashes with the color balance of the game.
2.  the Nishita model, which is the only one that handles sun/sky interaction, has correct ratios of sun and sky light.  This leads to very dark shadows.  There is a slider to reduce the intensity of the sun disc to rebalance things, but it makes the green shift that much worse.



I think this is kind of a non-starter.

One interesting option I'm playing with is extracting the sun disc from the Nishita sky, and adding it to my existing color gradient instead of using a sun light.  The result is a much warmer light and the contrast between lit and shadowed sides seems to match the game a bit better:



EDIT:  Okay, using the Nishita sun and then boosting the saturation on my sky gives a very good match to the in-game buildings.  (No ground-plane bounce here to prove the point, in practice this would only match on higher floors.)  I think we have a winner... except that the sky doesn't adjust correctly for the various rotations. 

[Jasoncw 11,987]

Can you attach the scene? 

For the sky rotation issue I'm guessing there are enough different nodes and whatever that the rotation of the camera can be fed into a parameter for the sky, but idk how to do that in practice. I also don't know how to create all of these objects and connections with each other with whatever code or script blender uses but I'm assuming it's possible. 

 

[ACEfanatic02 270]

9 minutes ago, Jasoncw said:

Can you attach the scene? 

For the sky rotation issue I'm guessing there are enough different nodes and whatever that the rotation of the camera can be fed into a parameter for the sky, but idk how to do that in practice. I also don't know how to create all of these objects and connections with each other with whatever code or script blender uses but I'm assuming it's possible. 

 

Attached.  (This is just the light rig, a test cube, and a ground plane configured to be invisible during render.  The version with the full mesh is too big to upload here.)

I worked out the driver needed to match the sun transform with the Nishita sky.  It's annoying, because the sky rotates in the opposite direction and is offset by 90 degrees.  But hey, I learned some Blender Deep Magic, so that's cool.

All the lighting stuff is in the World graph.  It's a bit messy, but it looks more intimidating than it is, I promise.

ace_light_rig_001.blend

[kaimai 1,067]

3 hours ago, Jasoncw said:

 

@kaimaiIt definitely looks like it's in the ballpark to me (and nice for me to see after looking at this grey BAT so much!). How is it for you in terms of how the textures look compared to how you are expecting them to look and how they look in Photoshop? Like in terms of the workflow does it feel intuitive and artist friendly? I'm guessing ultimately right now what we're going to get is a starting point that we'll have to iterate on after actually using it in BATing for a while. 

In this case, with all the textures being images blended together with HSV or Mix Color nodes, I could get comparable results to what I was expecting by just adjusting the values on those:

However it is worth noting from a workflow POV that, for whatever reason, a full preview render from your scene was significantly slower (1-2 minutes, compared to a few seconds).

With Ace's light rig the preview render is also 1-2 minutes, and textures would have to be color-corrected in the opposite direction (made darker/more saturated, etc).

I am still not very good at texturing, don't know how to use procedural textures and haven't really worked out how to use UV maps in blender, but I can upload the blend file with embedded textures if anyone wants to play with it (even if only because it would demonstrate how inexperienced batters are likely to proceed)

[matias93 7,535]

10 hours ago, ACEfanatic02 said:

I did have the same thought about using the various procedural sky models, but there are a few issues:
1.  all three of the options produce a slight green tinge.  AFAICT this is accurate, but clashes with the color balance of the game.
2.  the Nishita model, which is the only one that handles sun/sky interaction, has correct ratios of sun and sky light.  This leads to very dark shadows.  There is a slider to reduce the intensity of the sun disc to rebalance things, but it makes the green shift that much worse.



I think this is kind of a non-starter.

One interesting option I'm playing with is extracting the sun disc from the Nishita sky, and adding it to my existing color gradient instead of using a sun light.  The result is a much warmer light and the contrast between lit and shadowed sides seems to match the game a bit better:



EDIT:  Okay, using the Nishita sun and then boosting the saturation on my sky gives a very good match to the in-game buildings.  (No ground-plane bounce here to prove the point, in practice this would only match on higher floors.)  I think we have a winner... except that the sky doesn't adjust correctly for the various rotations. 

Keep in mind as well, that, as @rivit showed it some years ago, the buildings in game change tint depending on their wealth level as well. That purplish tone corresponds to the high-wealth buildings, but mid and low wealth have more orange-y tones.

[ACEfanatic02 270]

11 hours ago, matias93 said:

Keep in mind as well, that, as @rivit showed it some years ago, the buildings in game change tint depending on their wealth level as well. That purplish tone corresponds to the high-wealth buildings, but mid and low wealth have more orange-y tones.

Do you have a link to this?  AFAICT from what I've gotten to grow in my little test city, low/mid wealth stuff tends to have warmer textures, but they seem to have the same lighting.

[ACEfanatic02 270]

Quick attempt at modifying the rig for night:


Imperfect, but not terrible.  Still that subtle green tint, a lot more noticeable in the dark.  (This is once again without the ground plane, as the ground bounce will never match Maxis lighting.)

Not sure how to handle this from a workflow perspective.  All of the lighting comes from the World graph, and that's not something you can just swap out easily.  May just put both setups in the same graph and have a blend at the end to switch between them?  So the general workflow would be to have a collection of night lights that get turned on, and a property to drive the world lighting swap.  Having it be a property would also let you easily do night-specific material edits (i.e., turn on emission for neon lights, that sort of thing.)

@kaimai:  For better render times I strongly recommend setting the render to use GPU compute.  Pretty much any Nvidia card from the last decade will have CUDA, and more recent AMD (as of ~2019) cards have HIP.  Otherwise, go into the render properties and reduce the sample count (under Render; the BAT4Blender preview does not use the preview settings).  Something like 64 should be plenty for a preview, but you will likely want a higher sample count for the final render because all of the fancy indirect lighting stuff can be quite noisy.
 

Okay, enough playing tech artist for now, I want to actually make something.

[rivit 3,402]

On 9/8/2025 at 11:09 PM, matias93 said:

Keep in mind as well, that, as @rivit showed it some years ago, the buildings in game change tint depending on their wealth level as well. That purplish tone corresponds to the high-wealth buildings, but mid and low wealth have more orange-y tones.

Sorry matias - I didnt find that - everything gets rendered the same way depending on the program used. Its a fixed feature of the rigs.

The finding was related to Maxis rendering in gmax which is warmer than BAT4Max rendering which was colder. gmax is pretty much linear and saturates pretty early , BAT4Max has a much more dynamic curve, but truncates low values in the night renders. In-game Bat4max next to gmax for the same model will look a bit more clinical.

If people want to get into the nittygritty below are the results of rendering 16 value grey ramps that we got after I asked MattB to render them with default setups for an experiment. MattB explained to me that he made his BATs a little warmer by adapting his model textures to compensate before rendering them with BAT4Max. I have the detailed color curves and other rig data for anyone interested, just PM me, its a biggish file.

Ideally, to fit best in-game,  you want something like the gmax colortone with the BAT4Max dynamic range so details will not get washed out. As it also depends on the render engine parameters and rig setup, its an iterative process to get the result you want.

 

[ACEfanatic02 270]

Spent a few hours last night modeling and texturing a little pizza place (now closed) from my hometown.  This was very instructive.

All of the textures are procedural.  Most of the albedo colors were eyeballed, but I used the physical values for the metal vents.  Stainless steel is relatively dark, as metals go, but appears almost white in this render.  Similarly, the trim around the edge of the roof appears white, but is actually 50% (linear) grey.  This agrees with @kaimai's point about needing darker albedos to get a good result.

This is giving me some red flags here about the lighting balance.  Buckle up, folks, we're about to get technical.

Albedo:

A surface's albedo is (roughly) the ratio of incoming light it reflects.  When this ratio is wavelength-dependent, we perceive the surface as having a color.  Importantly, albedo is a physical property of materials, independent of the specific lighting conditions.

Proper albedos are critical to accurate rendering of indirect lighting.  This is easiest to show by example:

In both of these renders, the exposure and tonemapping are configured exactly the same.  The ground plane and cube have the same material.  All lighting comes from a Nishita sun/sky light (scaled down to avoid overexposure).

For the first render, the material has an albedo of 0.25 (linear sRGB).  In the second, we increase the albedo to 0.5, and reduce the lighting intensity by half.  If you tab between them, you'll notice that the ground plane looks the same, but the cube is brighter with the higher albedo.  This is due to the higher albedo bouncing more light off the ground and onto the cube.  So while the ratio between the sky/sun and albedo is the same, there is more light hitting the cube in the second case, and therefore it appears brighter.  Most of the ground plane sees no significant bounce light, and is therefore unaffected.  With colored surfaces this gets even more important, as bounce lighting affects the perceived saturation of colors.

Fortunately, the range of physically reasonable albedos is (mostly) known.  We call this Pointer's Gamut (for Michael Pointer, who conducted a survey of albedos in 1980 on behalf of Kodak.)  A good article on the subject:  https://chrisbrejon.com/articles/albedo-and-pointers-gamut/

Starting with grayscale values:  the lowest albedo among common materials is around 2% (charcoal or fresh asphalt), while the highest is around 81% (freshly fallen snow).  (Note that weird materials like Vantablack are not included.)  Here are a few samples along that range, rendered with my light rig and diffuse-only materials:

From left to right:  2% (charcoal), 10% (worn asphalt), 31% (white plaster), 52% (clean cement), 81% (fresh snow).

I have two problems with this:  first, the dark end of the scale is way too bright; while charcoal isn't pure black, it should be significantly darker than this.  On the other end, the 52% and 81% values look almost the same.  This implies the 81% value is actually overexposed, and the tonemapper is pulling it back down.

So what do we do?

Scene-referred Lighting:

There are two approaches to setting up lighting in a render.  The first is a photometric approach:  pick light intensities according to their real-world physical values.  For example, illuminance from midday sunlight on a clear day is approximately 100,000 lux (for surfaces pointed directly at the sun.)  You then pick an exposure value so that the important parts of the scene are well exposed.

This exposure value scales down the computed lighting to what we call the 'scene-referred' lighting.  For a well-exposed scene, the midtones sit at around 18% linear illuminance in scene-referred space.

The other approach is to skip the physics and set up all of our lighting in scene-referred space to begin with, leaving the exposure at 0.  It's trickier to get a physically accurate result this way, because the balance between sun, sky, and local lighting is so important.  Since we're trying to match a decidedly non-physical render (the existing renders in SC4), that's fine.

Adjusting my light rig so that the 18% ground plane is approximately 18% in the final lighting, we get this:

(Caveat:  I also switched to the Filmic tonemapper here, because the Khronos tonemapper seems to compress the darks too much.)

I think this is a much better base to build from.  

Applying this to my model from earlier:

Doesn't look great, which is to be expected.  Most of the albedos were set incorrectly to look good with the old lighting.  But, notably, the top of the vents, which use the physically correct albedo for stainless steel, actually look much more correct!

Phew!  That was a long one.  Give a graphics programmer the opportunity to infodump and she _definitely will_.  Hopefully some of that was of interest, or at least explained why I'm so thoroughly nerd-sniped here.

[ACEfanatic02 270]

After readjusting the albedo (and also the rest of the modeling), I think this fits in-game quite well.  Ignore the really dark brown in the gutters there; that's my procedural dirt shader being a little too enthusiastic.

One thing of interest is that the in-game shadows are much blurrier.  Part of that is this being zoom 6 (and the BAT being rendered at double resolution), but even taking that into consideration the shadows are too sharp.  I already have the sun disc at 2 degrees (~4x the real value of around 0.5).  Maybe that needs to be even higher?  I think the intensity gets normalized so I can try that without knocking things off-balance.

I think the two big blockers remaining to make this a usable pipeline are:
- we need a night lighting fit as well.  (At least for Maxis night.)  That'll be a similar iterative process (although with correct albedo and lighting range to start with, it should be a bit faster.)
- the workflow of "bake day and night and manually combine them in Reader" is... not fantastic.  Ideally we'd at least be able to point fshgen at a directory containing both the day and night bakes, and have it spit out a combined SC4Model for us.  (Personally I'm fine with that being a separate step, and not a specific button in the plugin.)  I'm not able to work on public code without getting it cleared first (game companies frown on moonlighting) so I think this is a thing for someone else to do.

I think from here I'm going to try making a few other buildings to try and get a better sense of how well this rig works in different conditions, then look at night lighting.

[Dono 222]

Hi, I'm new to Blender (says everyone, lol) and modding on that note. I've been making a heap of lots, mostly airport road fencing, but there are very limited diagonal fence props to my liking. I've used the PEG security fence props (they had a diagonal) in my industrial lots but they don't look the part for my airports, so thought I should learn to do it myself. I've set up Blender and added the BAT4Blender addon. I have Blender set so the suggested setups are now my default and am ready to go.
I have downloaded a few free 3dModels that I liked that have the creators consent to use and have imported them into Blender and played a bit to see what I was up against.
Is it ok use the unsupported SC4 3dModels in Blender to get them to look how I want, then to export them to what SC4 requires, or doesn't it work that way? 
Plus I just edited my post as I was asking about starting off with the correct sizing, but during my last mess around found that I think I should be fine if I keep my X and Y axis in 1meter tiles and design to the SC4 diagonal tile size of 22+ meters, and when done stretch my z axis to 133%?

Sorry, just realised my post probably should be in the BATing thread...Please move if required!!

Thanks.

[ACEfanatic02 270]

19 hours ago, Dono said:

Is it ok use the unsupported SC4 3dModels in Blender to get them to look how I want, then to export them to what SC4 requires, or doesn't it work that way? 

Are you asking if you can edit existing .SC4Models in Blender?  If so, the answer is no.  It's not a permissions thing.  The asset in game is basically a prerendered sprite projected onto a box model.  None of the original mesh remains.  If you have the actual source model that's a different story, so long as it is in a format Blender can understand.  (Blender can't import .gmax or .3ds files, for example, you need something like OBJ or FBX.)

Also, IMO the Blender pipeline isn't quite solid enough yet for making things quickly.  We don't have a solid night lighting setup yet, and combining day and night renders into a single .SC4Model for use in-game is... a very manual process at the moment.

[Dono 222]

On 12/09/2025 at 12:52 PM, ACEfanatic02 said:

If you have the actual source model that's a different story, so long as it is in a format Blender can understand.  (Blender can't import .gmax or .3ds files, for example, you need something like OBJ or FBX.)

Also, IMO the Blender pipeline isn't quite solid enough yet for making things quickly.  We don't have a solid night lighting setup yet, and combining day and night renders into a single .SC4Model for use in-game is... a very manual process at the moment.

OK thank you. Yes the 3d files I downloaded were FBX and a GLB as I had read a SC4Model couldn't be reverse engineered, so to speak. So at least from your reply my 3d design process is on track lol.
 I'm not lotting buildings, just fences and other objects at the moment so the night lighting isn't a concern. If the combining of day and night renders is different to the night lighting I may have a problem lol. I've tried to get a gist of what the actual process flow is from creating the 3d object to end useable .SC4Model. Something basic like - Create 3d item in Blender - add textures in Blender - export as ## in Blender - open in ### - etc, etc would be handy as at least then I could finish one thing and search up how to do the next part, there's so many different ways, opinions, and 20+ years of changes to contend with, I'm a bit lost but happy with my start.
Thanks again. 

[ACEfanatic02 270]

1 hour ago, Dono said:

OK thank you. Yes the 3d files I downloaded were FBX and a GLB as I had read a SC4Model couldn't be reverse engineered, so to speak. So at least from your reply my 3d design process is on track lol.
 I'm not lotting buildings, just fences and other objects at the moment so the night lighting isn't a concern. If the combining of day and night renders is different to the night lighting I may have a problem lol. I've tried to get a gist of what the actual process flow is from creating the 3d object to end useable .SC4Model. Something basic like - Create 3d item in Blender - add textures in Blender - export as ## in Blender - open in ### - etc, etc mould be handy as at least then I could finish one thing and search up how to do the next part, there's so many different ways, opinions, and 20+ years of changes to contend with, I'm a bit lost but happy with my start.
Thanks again. 

Lighting is still going to be a problem.  The issue isn't how to deal with building lights, it's that the environment lighting is different for night renders.  If you place a day render in a night scene, it's going to look very out of place.

The process for getting a BAT out of Blender is to render it using the plugin, set up the scene for night, and render again.  This gives you two .SC4Models, one containing day renders and one with night renders.  You can then use Reader to piece these together into a single .SC4Model with both.  It's an annoying manual process, especially for large buildings where the close-up zooms get broken into a bunch of separate images.

That should be a thing that can be automated, at which point it becomes practical to use.  For now, though, Here Be Dragons.

On a more positive note, here's an example of why I'm really excited about getting a working toolchain for Blender:


That roof is 100% procedural shading.  No image textures, it's not even UV mapped.  You could take this shader and plop it on another roof and it would work the same.  Imagine the community-wide quality bump we'd see if we could share stuff like this.

[memo 1,473]

Love to see all the activity and progress on the lighting rig. This is a huge step forward.

On 9/9/2025 at 4:10 AM, ACEfanatic02 said:

Not sure how to handle this from a workflow perspective.  All of the lighting comes from the World graph, and that's not something you can just swap out easily.  May just put both setups in the same graph and have a blend at the end to switch between them?  So the general workflow would be to have a collection of night lights that get turned on, and a property to drive the world lighting swap.  Having it be a property would also let you easily do night-specific material edits (i.e., turn on emission for neon lights, that sort of thing.)

I've long been wondering about a good workflow for this as well. I've learned about Drivers only very recently, but I agree this would be a natural way to implement it. It shouldn't be difficult for me to add such a property (nightmode: 0=Day, 1=MN, 2=DN) and ensure it is set accordingly during render.

I'm all for automating the entire pipeline. It's indispensable for batch processing. Manually stitching together dat files was never meant to be the actual workflow. It's mainly the lack of any night lighting rig settings that kept me from implementing it. A chicken-and-egg problem, perhaps.

10 hours ago, ACEfanatic02 said:

Lighting is still going to be a problem.  The issue isn't how to deal with building lights, it's that the environment lighting is different for night renders.  If you place a day render in a night scene, it's going to look very out of place.

Is this going to be a problem? As far as I know, props without night textures are the norm. I'm not sure if props with night lights have some special requirements (such as being connected to the power grid, or requiring special properties in the prop Exemplar).

Even if a BAT has night textures, the game doesn't switch to night textures for all BATs at the same time, which can lead to some of them looking out of place during twilight hours. I think a long-term goal would be to try to find a way to render night textures like Maxis did, i.e. the night renderings are masks that are blended together with the day renderings – if it's possible without a drop in quality.

For now though, the goal is to render night textures that are fully opaque, as BAT4Max does.

[ACEfanatic02 270]

11 hours ago, memo said:

I'm not sure if props with night lights have some special requirements (such as being connected to the power grid, or requiring special properties in the prop Exemplar).

Even if a BAT has night textures, the game doesn't switch to night textures for all BATs at the same time, which can lead to some of them looking out of place during twilight hours. I think a long-term goal would be to try to find a way to render night textures like Maxis did, i.e. the night renderings are masks that are blended together with the day renderings – if it's possible without a drop in quality.

For now though, the goal is to render night textures that are fully opaque, as BAT4Max does.

Interesting.  I think I may have misunderstood how night works in SC4.  I assumed they were always different sprites.  If night uses the same sprites, is it just multiplying a color on top?  If so (and if we know that color) it should in theory be really straightforward to add a night environment setup to the light rig.

[memo 1,473]

This post and the following by @rivit give a very good explanation on how the day and night renders are combined when displayed in the game:

On 1/11/2024 at 12:26 AM, rivit said:

In equation form:     Night Render =   DayModel * NightColour * (1-NightAlpha) + NightModel * NightAlpha

Here, DayModel and NightModel are the two renders exported from GMAX/3dsMax. Color space is non-linear. And importantly, NightColour is a variable that varies over the course of the day/night cycle. Its color follows a curve defined by the FSH file with IID 0x0917660e. This is what allows the game to switch on night lights at a different time per building, while the non-lit parts of the building gradually become darker as night falls.

For buildings created with BAT4Max, the NightModel is opaque, so it completely hides the DayModel. Hence, there's no variation with time. I assume the main reason for this approach is to simplify the BAT4Max scripts, or maybe it allows greater artistic freedom with the night lights.

 

[ACEfanatic02 270]

1 hour ago, memo said:

This post and the following by @rivit give a very good explanation on how the day and night renders are combined when displayed in the game:

Here, DayModel and NightModel are the two renders exported from GMAX/3dsMax. Color space is non-linear. And importantly, NightColour is a variable that varies over the course of the day/night cycle. Its color follows a curve defined by the FSH file with IID 0x0917660e. This is what allows the game to switch on night lights at a different time per building, while the non-lit parts of the building gradually become darker as night falls.

For buildings created with BAT4Max, the NightModel is opaque, so it completely hides the DayModel. Hence, there's no variation with time. I assume the main reason for this approach is to simplify the BAT4Max scripts, or maybe it allows greater artistic freedom with the night lights.

 

Ah, okay.

So the alpha channel of NightModel is a mask for the night lights then?  I _think_ we could pull this off using view layers:  it's possible to have Blender save the environment and direct lighting components as part of the rendering process.  The difference between them tells us the contribution of night lights.  This becomes our night texture, with the alpha channel set to a thresholded version of the night light luminance.

Where we're likely to run into trouble is that by the nature of Cycles being a pathtracer, we're going to get a bunch of indirect bounce off night lights.  So there will probably be pixels that have both a visible contribution from night lighting, but are still primarily lit by the environment.  To avoid an obvious seam, we still need to include the night color in our render.  That will make sunrise/sunset look weird, potentially, as well as prevent reuse between MN and DN.  Alternatively, we use an actual alpha channel instead of DXT1 binary alpha.  Since we know one input and the output, we can invert the blend (as long as none of the inputs are 0).  Linearity is nice.  Does SC4 support DXT5?  DXT3 has very low-precision alpha (only 16 steps); if we're going to spend the bytes it'd be nice to get decent quality, especially since we're going to get a lot of smooth gradients susceptible to banding.

Might prototype something later just to see how it works out.

[memo 1,473]

On 9/13/2025 at 12:03 PM, ACEfanatic02 said:

So the alpha channel of NightModel is a mask for the night lights then?

My terminology calling it a "mask" was inaccurate. The NightModel is simply overlayed on top of the DayModel multiplied by a color. So wherever the alpha channel of the NightModel isn't 1.0, you see part of the underlying DayModel.

On 9/13/2025 at 12:03 PM, ACEfanatic02 said:

To avoid an obvious seam, we still need to include the night color in our render.  That will make sunrise/sunset look weird, potentially,

Yes, I think this could still be a win, as it would allow for a gradual transition between day and night, but there are likely some cases with indirect lighting or semi-lit areas that just end up looking odd.

On 9/13/2025 at 12:03 PM, ACEfanatic02 said:

Alternatively, we use an actual alpha channel instead of DXT1 binary alpha.  Since we know one input and the output, we can invert the blend (as long as none of the inputs are 0).  Linearity is nice.  Does SC4 support DXT5?  DXT3 has very low-precision alpha (only 16 steps); if we're going to spend the bytes it'd be nice to get decent quality, especially since we're going to get a lot of smooth gradients susceptible to banding.

50% of the information in a DXT3 file is the alpha channel, which seems plenty. I haven't seen DXT5 being used anywhere. The Maxis files seem to use DXT1 for the DayModel and DXT3 for the NightModel. DXT compression shouldn't be the problem here, though. Blender exports 32-bit PNG files, so any computation could use those higher quality images. I'm just not sure if there aren't too many variables in the equation to be able to invert the blend. Mainly, the NightAlpha would need to be exported from Blender, ideally.

 

I've updated the BAT4Blender source code to include new UI elements for Day & Night.

There's no pre-configured rig yet, but you can customize the night renderings using Drivers:

• Right click on the "Day | MN | DN" panel and Copy as New Driver.
• Right click on any property that should depend on the day/night state (e.g. Strength of a light source, or Disable in Render button) and Paste Driver.
• Right click the property and Edit Driver.
• Set Type to Scripted Expression.
• Adjust the Expression. Examples:
  • 2.5 if night else 10.0 (for a Float value)
  • not night (for a Boolean value)
  • 1.5 if night == 2 else 2.5 if night == 1 else 10.0 (to distinguish between DN, MN and Day)
• Copy the driver to any other property that should use the same expression.

For example, this allows reducing the strength of the sun at night.

The properties Rotation and Zoom can now be used as Drivers, too – for example, to add additional light sources that depend on the rotation.

If you enable Post-Processing and render both night modes, BAT4Blender will create two SC4Model files (MN and DN), so assembling models with night textures is fully automated now.

Let me know if there are any issues.

[Jasoncw 11,987]

There's been so much stuff every time I sit down to respond there's too much to respond to (not a bad problem to have!) so I'll just focus on a few things. 

When updating BAT4Max for Mental Ray back in the day there were a few conscious changes from Gmax.

For Nitelites, this was introducing "TruNite", which has a variant for matching the default night (MaxisNite) and a variant for matching the popular dark night mods (DarkNite). TruNite in practice bypasses the normal nitelites system to make full building night renders, which have a few advantages (in no particular order): 

- Since it's a full building render, not as much alpha information is needed, so a different compression type can be used which has better image quality. There were major banding issues before switching. 

- With the Scanline renderer there's a very straightforward distinction between parts of the BAT affected by nitelites and the parts that are not, because it's not actually simulating any light. With Mental Ray (and now Cycles) the light is bouncing around all over and all surfaces are reflective and so any change you make in one part of the BAT is going to change the appearance elsewhere in the BAT. Trying to use the vanilla nitelites system with this gets weird. 

- The vanilla nitelites system produces weird results. If you have a spotlight shining on a facade, when you're in the game the spotlight will actually make the facade darker, not brighter. If it's a bright spotlight then the middle of the spotlight will be brighter in the game, but the fringes will be darker. If it's a dim spotlight, the entire spotlight will be darker in the game. This is made even worse by the previous point, because with indirect lighting much of the BAT would be areas of weak nitelites which would look darker in the game. 

- Because of the processing to get the nitelites alpha, nitelites are not WYSIWG. Your nitelites in the game will not look the same as your nitelites preview render. 

- The vanilla nitelites system does the same thing that movies often do, where they shoot the scene during the day and then add a blue filter on top. You can see the strong lighting and strong shadows from the sun that aren't supposed to be there at night. So TruNite allows for an independent and more realistic lighting rig for night time. 

- Since the night render effectively completely replaces the day render, you can make changes between the day and night versions of your BAT. This hasn't actually been done very often but there's a lot of potential for it. For example, during the day you can have a storefront that is open, and then at night you can have security shutters lowered over it. For a park you can have a gate open during the day and closed at night. You can have a shop where there's a table of goods out during the day but moved inside at night. As long as the alpha for the renders aren't changed you can do whatever you want. 

- The sacrifice for all this was dusk and dawn. But it was found that very few players actually used that feature of the game. And at this point we have over 15 years of BATs not supporting it. 

- I can't find the thread now but a process was made for taking TruNite BATs and creating BATs with the Maxis nitelites system out of them. The results were surprisingly good. 

For the exporting process it was decided to break the day and night exports into separate steps, for a few reasons: 

- It's more straightforward and more artist friendly. However the scene is when you press the night export button, that's how it will export. If there's an automated system which switches between day and night, then it means any changes you make between the day and night versions needs to comply with that system, which is extra work for the BATer. Manually switching a scene between day and night takes less than a minute, and you barely have to think about it. And while most of this switching is going to be more basic things like turning an emissive material or a light on or off, other things are common too. For example, sometimes I'll have transparent glass and modeled window blinds with a very basically modeled interior (the floor has a busy texture), which looks good during the day but would look bad at night. So for night I add a parallel plane behind the glass and blinds and I give that an emissive material with a night texture on it. 

- Doing the coding to get that properly set up for BAT4Blender would take work, and tutorials would need to be made explaining the system to BATers. 

- Some people might want to tweak the nitelites differently for MaxisNite and DarkNite. I personally do my nitelites for DarkNite and then just export the MaxisNite version without changes. But since MaxisNite is brighter, if you want to get a good looking amount of contrast between the lights and the building, you might need to make the lights brighter. 

- I always check the BAT in-game after exporting the day version. I do this to confirm that there isn't a glitch with the .SC4Model (probably less of a problem with BAT4Blender). I do it to confirm that the halo surrounding the BAT is minimized. This might be less of a problem with BAT4Blender, but any time there's trees or fences or transparent materials you're going to need to change the background color of the render to blend in with the BAT. For example if you have a tree the background color needs to be dark green to blend in with the leaves. I check to see if the building has really bad seams (idk what to call it. The splitting effect caused by the way the LOD is spliced and uv maps made), in which case I have to redo the LOD and reexport. And I check to see how the building looks in the game in general. Also, exporting all three versions at once would occupy my computer for an inconvenient amount of time. Also, while this isn't a problem so much nowadays, back in the day it would be more common for exports to fail (those of us traumatized by code 6) so isolating them was appealing. 

- The upside to exporting all three versions at once is that it's good for people exporting a ton of small props. Which is a legitimate use-case but imo a niche one. It's also good for people with slow computers or complex BATs where it makes more sense to let it run doing all three versions overnight (or during the day when they're out doing errands or something) than doing them one at a time during the day. 

 

So overall I would say that the ideal export process would be to have four buttons (or drop down options). One for creating blank .SC4Model files (making two for MN and DN would actually be a big quality of life improvement), a button for exporting and inserting day, a button for exporting and inserting MaxisNite, and a button for exporting and inserting DarkNite. Pressing these export buttons would not change the scene's lighting or rendering settings, which would each be done with separate buttons. If, in addition to this, there was a button for exporting all three versions and automatically setting the scene and turning things on or off for each version like how Gmax does it, I'm sure that would be appreciated as well, but I would think of that as a bonus feature.