BAT4Blender

[Jasoncw 11,843]

The albedo is definitely an issue, but there are conflicts and idk if there's a perfect solution. If you use the correct albedo then the BAT will not fit with the game's bright art direction. If that gets compensate for with the exposure, then the textures aren't WYSIWYG. If instead the textures are just made brighter, then they have the wrong albedo, having a negative effect on lighting and also making BATing incompatible with 3d assets from outside of BATing. 

That's what the Mental Ray rig did. It's photometric with realistic values for brightness and exposure (this also works well when making the night rig and doing nitelites). Most textures look pretty good for the game most of the time but sometimes you have to make things brighter than they should be in order to fit in with the game. And I do think it's one of the reasons the Mental Ray BATs can look plasticky sometimes. 

When I was working on the Blender rig I tried to make it photometric but when I did that it looked really weird. For the sun and sky's brightness, I found a page online (https://blendergrid.com/learn/articles/cycles-physically-correct-brightness) where someone converted between some units and reference numbers to get a sun brightness of 441 and a sky brightness of 29, which I used as the starting point, and then adjusted the sky and the exposure to make it look how it should, and it did roughly, but it looked really messed up, like there was a lot of clipping, so idk what I did wrong. 

2 degrees for the sun matches the BAT4Max rig, which in my experience is good for BATs. On the BAT you just made it seems like the shadows are too sharp, but the BAT you made is small and has very small details. On a more typically sized BAT, small elements have sharp shadows, and medium sized elements (like an elevator penthouse on the top of a building) have fluffy shadows, and big scaled elements (like a skyscraper sitting on top of a wide podium or plaza) have very fluffy shadows. Basically that fluffiness matches the scale of the typical elements in a BAT, where the contrast from the sharpness works well for the shadows for details, while the fluffier shadows for bigger elements draws the eye much less, from a compositional point of view. Also, at this point most of the content people have in their cities are BAT4Max BATs, so I don't think we need to worry about matching the problematic shadow maps on the scanline rig. 

For the brightnesses of things in the game, the asphalt roads are the traditional reference point for something that is very dark. When BATing you'll sometimes want things to go even darker than that, like thin window frames that you need to pop a little more, but for the most part that is "black". For other materials it's harder to say. For the Maxis buildings there's plenty of times where there's upward facing stone that is literally 255,255,255. Maxis's Rockefeller center has limestone that on the walls ranges from 70-80% bright. What I recommend for BATers is to have a photoshop file with a bunch of in-game screenshots. And then a hue/saturation adjustment layer that desaturates the image (to help judge brightness value), another hue/saturation with the saturation increased (to make it easier to see how the colors fit). I think starting with photometric lighting and good albedos we can at least pin down most of the variables and then figure out just how far off the result is from the game's palette and then go from there. 

(sorry about the super scattered posts!) 

[ACEfanatic02 259]

This will be somewhat long and in arbitrary order; I logged myself out yesterday while the site was having issues and seemed to really upset the server so this is a collection of notes over several hours.

- To address a tiny bit of misinformation I've seen in a few different threads now:  the RGB compression between DXT1 and DXT3 (and DXT5) is, for all intents and purposes, identical.  (The only caveat is in cases where you do not care about the alpha channel at all, in which case DXT1 can use three-color mode for blocks to get a 'free' black value off it's interpolation axis.  That's not relevant to SC4.)  The actual difference is DXT3 adds a 4-bit alpha channel to all of the blocks, doubling its memory footprint but giving it 16 levels of alpha instead of 2.

If there are cases we want to use alpha for real (like in this compositing setup), I think it's worth at least _trying_ to see if SC4 will handle DXT5, because it reduces alpha banding in the same amount of memory by using the "endpoints + interpolation" trick that the RGB compression uses.  (It's very effective at this:  BC4/BC5, which are essentially the same compression scheme, can often reconstruct 10+ bits of precision in real cases.)

- Photometric approaches don't really work here, IMO, because the sky/sun ratio in-game is wrong.  The real ratio is about 1:16, in-game it's closer to 1:8.  I expect this was a conscious choice on Maxis's part to keep things more readable for gameplay reasons.  (Which, incidentally, is the same reason they use the 'daylight but blue' approach to nightlighting:  it's more readable.)

- Halos around building sprites _should_ be avoidable.  I actually have a prototype for addressing this in the blend file I shared earlier.  The basic idea is to take the rendered image, and composite over a blurred version of itself; the edge color should then be a close match.  Since we use DXT1, the rest of it depends on the remainder of the pipeline doing the right thing (texture compressor needs to premultiply, in-game shader needs to expect a premultiplied result.)  We don't have a whole lot of control over the second half of this.

- I've been playing with a few compositing features in Blender and have found what seems to be a pretty neat solution to at least _some_ of the nightlight problem.

Blender has the ability to add lights to a 'light group'.  The contribution of each light group (including bounce lighting) is stored in a separate image provided to the compositor.  So it is possible to put the environment light in a light group and subtract it from the final image to isolate night lights.  We can then tint the environment light appropriately (depending on MN or DN), and composite the night lights back on top.  Alternatively, we can use the separated night lights to produce the Maxis-style night layer.

I have to agree with Jason, though:  between the banding of 4-bit alpha, and the extra memory cost of DXT3 over DXT1, using the Maxis compositing kind of feels like a bad trade.  (If we can use DXT5 that shifts a bit more in favor, but IMO I'd err on the side of lower memory cost.  Sacrificing dawn/dusk for better stability in-game feels like a good idea.)

One caveat to this:  contribution from emissive materials cannot be isolated in this way.  So if we use the delta from environment lighting as the night layer, emissives will _always_ be night lights, and it is not possible to have emissives show up during day.  (Technical reason:  emission does not end the light path during pathtracing, so Blender can't accumulate it separately.)

[Null 45 3,048]

On 9/14/2025 at 8:21 AM, ACEfanatic02 said:

(The only caveat is in cases where you do not care about the alpha channel at all, in which case DXT1 can use three-color mode for blocks to get a 'free' black value off it's interpolation axis.  That's not relevant to SC4.)

Many of the Maxis automata use the DXT1 binary alpha.

On 9/14/2025 at 8:21 AM, ACEfanatic02 said:

I think it's worth at least _trying_ to see if SC4 will handle DXT5, because it reduces alpha banding in the same amount of memory by using the "endpoints + interpolation" trick that the RGB compression uses.

Memo posted on the SC4E Discord that the game supports DXT5. It makes logical sense that EA would have implemented DXT5 support alongside DXT1 and DXT3, DXT5 is FSH format 0x62, DXT3 and DXT1 are 0x61 and 0x60 respectively. It is unknown why EA/Maxis preferred DXT3 over DXT5.

[kaimai 1,045]

On 9/8/2025 at 10:10 PM, ACEfanatic02 said:

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

Ok I looked up what graphics card I have and, in retrospect, this explains a lot of my problems....

Anyway I think I'm following this convo. When I test exported MN/DN variants of the small building I shared earlier, all I did was turn the sun off and set the world background to the night color values that someone (maybe Jasoncw?) mentioned earlier, and then added light objects in the appropriate places. Obviously the actual final lighting rig will be more complex and realistic. But if I understand drivers correctly: you have to compose Type Expressions to turn all lights/emissions on or off? Or are those just for setting the day/night rig and then you turn on/off the various lights manually like in BAT4Max?

[memo 1,446]

Ok, a few things:

- I've updated the BAT4Blender code to include a MN only and a DN only option for rendering. This allows you to render Day and Night completely independently from each other. A small caveat is that this is incompatible with the Post-Processing option. This is mainly just a convenience function anyway. Instead, you can create the SC4Models using the commands from the Readme, which is more flexible, transparent and customizable by saving them in a .bat script file, for example.

I still think it's worthwhile to set up the driver expressions, as it allows to save all the relevant configurations for night mode and allows to switch between day and night easily with a single button press. The drivers can feel a bit clunky at times though. For example, it's difficult to drive the disable-in-render state of collections. I plan to add two collections "Day" and "Night" which BAT4Blender would automatically disable for the respective render. Then you could put all your night-specific objects in the "Night" collection.

- I've renamed the nightmode property to just night. This is more succinct when writing Driver expressions such as 2.5 if night else 10.0. Note that it is possible to distinguish between MN (1) and DN (2) as well, for example: 1.5 if night == 2 else 2.5 if night == 1 else 10.0

- There's an updated version of fshgen, adding support for DXT5 (and also improves the default compression settings). As Null 45 already mentioned, I've tested it in game on building models and network models without any issues. Here's an example of a pure red image with a smooth alpha gradient compressed as DXT5:

In comparison, the DXT3 compressed image has visible banding issues with such a smooth gradient:

I'm not sure why Maxis didn't use DXT5, even though it seems superior to DXT3.

- If the Maxis compositing approach for nightlights can be implemented with Blender in a way that amounts to solving for the variables in rivit's equation, then this means that day and night shots look identical to what the non-compositing approach would yield. So we wouldn't lose anything with the night rendering. The only difference is at sunrise/sunset, where the compositing approach allows for a smoother transition.

In theory, image quality for the night rendering could even be a bit better if you take DXT compression into account. For example, if you have a hard edge between a lit window and the un-lit facade, this color information can be better represented with the compositing approach. For each 4×4 pixels, you have 2 interpolated colors for the facade, plus additional 2 interpolated colors for the window with alpha. How much this has an effect in practice is not clear at this point though, as it depends a lot on how different the actual night render is from the tinted day render.

On 9/14/2025 at 4:21 PM, ACEfanatic02 said:

Halos around building sprites _should_ be avoidable.  I actually have a prototype for addressing this in the blend file I shared earlier.  The basic idea is to take the rendered image, and composite over a blurred version of itself; the edge color should then be a close match.  Since we use DXT1, the rest of it depends on the remainder of the pipeline doing the right thing (texture compressor needs to premultiply, in-game shader needs to expect a premultiplied result.)

That's what I thought as well. I haven't observed these issues myself, so I'm unsure if the current pipeline is even affected by it. Blender exports images with transparent background, so I didn't think it would even be possible for the Blender background to bleed through at the edges.

[ACEfanatic02 259]

4 hours ago, Null 45 said:

Many of the Maxis automata use the DXT1 binary alpha.

Memo posted on the SC4E Discord that the game supports DXT5. It makes logical sense that EA would have implemented DXT5 support alongside DXT1 and DXT3, DXT5 is FSH format 0x62, DXT3 and DXT1 are 0x61 and 0x60 respectively. It is unknown why EA/Maxis preferred DXT3 over DXT5.

Neat.  Yeah, I can only guess why they chose DXT3.  Maybe compression times?  Encoding DXT3 alpha is trivial, DXT5 not so much.  Not a problem on modern hardware, though, especially not when compressing a small number of textures at a time.

2 hours ago, memo said:

Ok, a few things:

- I've updated the BAT4Blender code to include a MN only and a DN only option for rendering. This allows you to render Day and Night completely independently from each other. A small caveat is that this is incompatible with the Post-Processing option. This is mainly just a convenience function anyway. Instead, you can create the SC4Models using the commands from the Readme, which is more flexible, transparent and customizable by saving them in a .bat script file, for example.

I still think it's worthwhile to set up the driver expressions, as it allows to save all the relevant configurations for night mode and allows to switch between day and night easily with a single button press. The drivers can feel a bit clunky at times though. For example, it's difficult to drive the disable-in-render state of collections. I plan to add two collections "Day" and "Night" which BAT4Blender would automatically disable for the respective render. Then you could put all your night-specific objects in the "Night" collection.

- I've renamed the nightmode property to just night. This is more succinct when writing Driver expressions such as 2.5 if night else 10.0. Note that it is possible to distinguish between MN (1) and DN (2) as well, for example: 1.5 if night == 2 else 2.5 if night == 1 else 10.0

- There's an updated version of fshgen, adding support for DXT5 (and also improves the default compression settings). As Null 45 already mentioned, I've tested it in game on building models and network models without any issues. Here's an example of a pure red image with a smooth alpha gradient compressed as DXT5:

In comparison, the DXT3 compressed image has visible banding issues with such a smooth gradient:

I'm not sure why Maxis didn't use DXT5, even though it seems superior to DXT3.

- If the Maxis compositing approach for nightlights can be implemented with Blender in a way that amounts to solving for the variables in rivit's equation, then this means that day and night shots look identical to what the non-compositing approach would yield. So we wouldn't lose anything with the night rendering. The only difference is at sunrise/sunset, where the compositing approach allows for a smoother transition.

In theory, image quality for the night rendering could even be a bit better if you take DXT compression into account. For example, if you have a hard edge between a lit window and the un-lit facade, this color information can be better represented with the compositing approach. For each 4×4 pixels, you have 2 interpolated colors for the facade, plus additional 2 interpolated colors for the window with alpha. How much this has an effect in practice is not clear at this point though, as it depends a lot on how different the actual night render is from the tinted day render.

That's what I thought as well. I haven't observed these issues myself, so I'm unsure if the current pipeline is even affected by it. Blender exports images with transparent background, so I didn't think it would even be possible for the Blender background to bleed through at the edges.

Thanks for confirming DXT5 works.  If we do go for night light layering, I think using that for the lights will solve a lot of issues.  One issue remaining is that if we go this route, any non-lighting detail that changes between day and night (e.g., Jason's idea of shuttered shop windows) would still look wrong during the transition, and would also still require separate MN and DN versions (because the runtime blend doesn't tint the night layer.)  Given most of the 3dsMax BATs do the "wrong" thing, maybe it's better to keep that consistency and take the memory reduction win.

I also think it's somewhat difficult to do this consistently entirely within Blender, due mostly to the inability to isolate emissive material bounce from night lighting.  We'd need to do a full render of day and night, and then compute a delta of those instead of relying on compositor layers.  (At that point, it becomes _critical_ that the renders are properly denoised, because any difference in noise pattern will introduce spurious deltas between the two.)  I dunno, it's messy.  I don't think there _is_ a correct solution here.

I haven't played around with the new scripts yet, but if they're using custom properties we can actually access those directly in the various node editors with Attribute Nodes: https://docs.blender.org/manual/en/latest/render/shader_nodes/input/attribute.html .  Useful since most of the finicky changes (not just turning things on and off) would be in various materials.  I like the idea of a Day and Night collection, as well.  That would require some explanation to folks, because collections aren't really a thing that gets covered in most "How to Blender" tutorials, but it is likely the best solution for auto enable/disable of objects.

Built out another test building while the site was down yesterday.  I'm really liking this night rig.  Will try to clean things up and get an updated rig posted this week.

[Dono 178]

I wasn't sure if this thread was for the development of BAT4Blender or for those like myself with probably stupid questions on using it. So please delete or move to the appropriate area. 

I'm just creating basic props, with a bit of a struggle have got my test prop in to SC4PIM but it's invisible when I go to add it to a lot (the yellow box shows its been added to the lot, and it can be moved around but has no textures at all). From my journey some questions arose which may be linked to my issue as follows.

1. From the original memo post, is the "Pull Request" link still relative? I haven't used it thinking it would have been done by now, I have updated everything else.
2. Probably related to Q1, where's the roadmap mentioned in the SC4Blender readme, I have noticed some of them in the BAT4Blender Scene Properties plain in Blender, but not all of them.
3. In a recent post it mentioned you had to render the day setup then do the same for the night, then merge the two. I assumed the Day/Night tab if I selected ''Day & MN'' it was doing that?
4. Once I complete my Object do I 'Render Image' from the top menu and save, then do the Render all zoom & rotations in the B4B addon. Or once I complete my Object can I just save it then do the Render all zoom & rotations.
5. and last, when I added my SC4Model file to SC4PIM to create the prop it gave me a message(as apart of the created file name) that the XML file wasn't present, but it completed the creation. I saw Tyberius06 post, he said it should be ok in SC4PIM but I wasn't sure if something has changed and that was involved.

Thanks.

[memo 1,446]

I've added support for collections named "Day" or "Night" that automatically toggle their visibility in renders when you switch between night and day. You can place them anywhere in the Outliner hierarchy, and you can create more than just one of each. Then you can place your night lights and window blinds in one of the "Night" collections to hide them during the day render, for example.

 

BAT4Blender will now also generate an XML file containing the model TGI and its dimensions. I've used the bounding box of LOD1 to compute the dimensions. I had kind of put that off, as the file didn't seem super important.

Fshgen cannot import the XML file into the SC4Model file (yet), as the program wasn't made for general purpose stuff like this. For now, use the Reader to insert the XML into the SC4Model file.

5 hours ago, Dono said:

I wasn't sure if this thread was for the development of BAT4Blender or for those like myself with probably stupid questions on using it.

It's fine here if it's related to the BAT4Blender workflow.

5 hours ago, Dono said:

got my test prop in to SC4PIM but it's invisible when I go to add it to a lot

I have no experience with SC4PIM nor with PIM-X, but I heard that PIM-X should be the program of choice, as it resolves many modding issues of the Maxis SC4PIM.

5 hours ago, Dono said:

From the original memo post, is the "Pull Request" link still relative?

The Pull Request is irrelevant. It's still pending, but doesn't contain the most up-to-date version of the code.

5 hours ago, Dono said:

Probably related to Q1, where's the roadmap mentioned in the SC4Blender readme, I have noticed some of them in the BAT4Blender Scene Properties plain in Blender, but not all of them.

Some things from the roadmap aren't implemented yet. Others are internal functions that aren't visible in the UI.

5 hours ago, Dono said:

3. In a recent post it mentioned you had to render the day setup then do the same for the night, then merge the two. I assumed the Day/Night tab if I selected ''Day & MN'' it was doing that?

Yes. The Render "Day & MN" option is only 3 days old. You can choose your preferred workflow.

5 hours ago, Dono said:

4. Once I complete my Object do I 'Render Image' from the top menu and save, then do the Render all zoom & rotations in the B4B addon. Or once I complete my Object can I just save it then do the Render all zoom & rotations.

Just "Render all zooms & rotations" is enough.

[Dono 178]

On 17/09/2025 at 4:04 AM, memo said:

I have no experience with SC4PIM nor with PIM-X, but I heard that PIM-X should be the program of choice, as it resolves many modding issues of the Maxis SC4PIM.

Thanks for the clarification on my questions, helped heaps. On the one related to PIM-X, I did have the latest non-Maxis PIM but my stupidity was the issue. Once I created the prop I then opened PIM to create the test lot from the .desc file but it was blank because I hadn't also added the Model file to PIM. Usually in a .dat file they'd be bundled together. Also if someone has a link or basic instructions on how to add the xml file to the .SC4Model that would be much appreciated, I searched but couldn't find any info on adding, just removing, and reverse engineering the remove process didn't work.

Two questions I forgot to ask was during the creation of my object and on rendering: 
-Do I need to remove the default Camera and Light from the Render process and add the Sun and Camera from BAT4Blender.
-And I understand lighting is what's being worked on ATM but as I'm only making Props, is there any specific angles/settings I need for the Sun and Camera or is addressing my first question all I need to worry about.

Thank you.

[memo 1,446]

2 hours ago, Dono said:

Also if someone has a link or basic instructions on how to add the xml file to the .SC4Model that would be much appreciated,

Open the .SC4Model in Reader, right click and insert file as Undefined. Then use the TGI editor to set the TGI of the newly added item based on the TGI of the XML file name.

2 hours ago, Dono said:

-Do I need to remove the default Camera and Light from the Render process and add the Sun and Camera from BAT4Blender.

Yes. The Camera is useless but doesn't do any harm, but the Light affects the lighting of your scene.

2 hours ago, Dono said:

-And I understand lighting is what's being worked on ATM but as I'm only making Props, is there any specific angles/settings I need for the Sun and Camera or is addressing my first question all I need to worry about.

The camera is positioned automatically by BAT4Blender. The Sun as well, but the current default settings don't match the game. This is subject to change. Check the recent posts for some better light settings.

[Dono 178]

1 hour ago, memo said:

The camera is positioned automatically by BAT4Blender. The Sun as well, but the current default settings don't match the game. This is subject to change. Check the recent posts for some better light settings.

Thanks heaps, sorry for all the questions. I've now a better understanding of where most things fit in so at least I wont be going down some unknown garden path to get things working, at least any other questions should be in the bating forum  

[Dono 178]

Ok, I may have jumped the gun saying no more questions.

I overlooked, or more so, assumed, the use of the  LOD buttons in the BAT4Blender addon. Is it that when I do the reneder all zooms it does what is required for ingame but if I want more control over each zooms quality, then I can use the LOD buttons. 

Plus my b4b camera is in the same orbit as the moon. If I drop it down on the Z axis will it be still on the required coordinates for the game. Since using the new camera and disabling the default one, when i do a render it gets to about 40% and freezes.

[ACEfanatic02 259]

58 minutes ago, Dono said:

Ok, I may have jumped the gun saying no more questions.

I overlooked, or more so, assumed, the use of the  LOD buttons in the BAT4Blender addon. Is it that when I do the reneder all zooms it does what is required for ingame but if I want more control over each zooms quality, then I can use the LOD buttons. 

Plus my b4b camera is in the same orbit as the moon. If I drop it down on the Z axis will it be still on the required coordinates for the game. Since using the new camera and disabling the default one, when i do a render it gets to about 40% and freezes.

Correctly fitted LODs are necessary to render the right thing, those buttons add basic box LODs.  If you haven't modified the LOD meshes, I recommend deleteing and re-adding the LODs before render, that will ensure they're aligned properly.  (Also, make sure your model is centered in the XY plane first!)

The camera is far away to keep it out of the way.  It's an orthographic projection, so it does not make any difference how far away it is.  If you move it down on Z, it will no longer be pointed at the model.  I'd recommend leaving it alone.

I've seen a few freezes after render in cases where LODs are incorrect (i.e., trying to render with empty LOD models.)  I _think_ this is just an edge case not covered in the script.  As long as the model is rendered in view this should not be an issue.

[Dono 178]

1 hour ago, ACEfanatic02 said:

Correctly fitted LODs are necessary to render the right thing, those buttons add basic box LODs.  If you haven't modified the LOD meshes, I recommend deleteing and re-adding the LODs before render, that will ensure they're aligned properly. 

Thanks, I kind of thought it was automatic as when I click on "Render all Zooms and Rotations" the LOD1 through LOD5 automatically populate the Scene collection window.
So on that note, when I hit the LODs button "Add" (Before Rendering) and it adds the 5 LODs to the Scene Plain, do I need to make any changes or are their defaults good enough (I'm just making diagonal fence props).
 And when I Add the Sun, have you any suggestions for its settings, I've been through the last 5 pages of posts and have ended up more confused, I understand all those involved are brainstorming to get a pre-set locked in but I couldn't see a posted temporary solution.

 

[ACEfanatic02 259]

22 hours ago, Dono said:

Thanks, I kind of thought it was automatic as when I click on "Render all Zooms and Rotations" the LOD1 through LOD5 automatically populate the Scene collection window.
So on that note, when I hit the LODs button "Add" (Before Rendering) and it adds the 5 LODs to the Scene Plain, do I need to make any changes or are their defaults good enough (I'm just making diagonal fence props).
 And when I Add the Sun, have you any suggestions for its settings, I've been through the last 5 pages of posts and have ended up more confused, I understand all those involved are brainstorming to get a pre-set locked in but I couldn't see a posted temporary solution.

 

For a diagonal fence, specifically, I think it may be worth creating custom LODs.  Just a box rotated to fit would be plenty.  Anything inside the LOD footprint will conflict with other objects in-game, so if you want to be able to place other props near your fence, having a tighter fit is probably useful.

The current solution for lighting I have is a bit more complex than just a sun light.  There's a version of it posted as a blend file on the previous page.  To use it, you'd save a copy of that blend file, and move your model over into it (rather than trying to replicate the entire lighting rig from scratch.)  I have a better version I'm working on (that has fewer issues with highlights getting blown out, support for night sky color, etc.), but I haven't gotten it cleaned up and posted yet.

[Dono 178]

49 minutes ago, ACEfanatic02 said:

To use it, you'd save a copy of that blend file, and move your model over into it (rather than trying to replicate the entire lighting rig from scratch.) 

I was actually looking at doing exactly that as I thought it would be easier adding my object to your lighting setup.
I haven't tried it yet as last night when I tried adding the LOD's from the B4B tool LOD "Add" option the render process took ages (at least it got past my previous 40% stall point when I used the blender default) but when complete and I added the created SC4Model to a lot, It was huge beyond what could fit on my screen lol. It didn't do that when I used the default LODs (when one would work), the model fit as a diagonal fence should have from corner to corner, but the render/textures were messed up. I'm going to go back and try my fence as an ortho using the B4B Tool and its LODs. Then if I get that to work, then revert to the diagonal and try as you have suggested in your post by creating a custom box.

Thank you for your help, much appreciated.

[ACEfanatic02 259]

53 minutes ago, Dono said:

I was actually looking at doing exactly that as I thought it would be easier adding my object to your lighting setup.
I haven't tried it yet as last night when I tried adding the LOD's from the B4B tool LOD "Add" option the render process took ages (at least it got past my previous 40% stall point when I used the blender default) but when complete and I added the created SC4Model to a lot, It was huge beyond what could fit on my screen lol. It didn't do that when I used the default LODs (when one would work), the model fit as a diagonal fence should have from corner to corner, but the render/textures were messed up. I'm going to go back and try my fence as an ortho using the B4B Tool and its LODs. Then if I get that to work, then revert to the diagonal and try as you have suggested in your post by creating a custom box.

Thank you for your help, much appreciated.

Ah, yeah.  If you use my setup, you must hide the ground plane before fitting the LODs, otherwise the LOD will be sized to fit that as well (which generates an enormous LOD, and will require rendering much more.)

[Dono 178]

On 21/09/2025 at 4:56 PM, ACEfanatic02 said:

Ah, yeah.  If you use my setup, you must hide the ground plane before fitting the LODs, otherwise the LOD will be sized to fit that as well (which generates an enormous LOD, and will require rendering much more.)

Instead of a new post I'm just updating this one:

I downloaded your lighting blend file and had a go at adding my object to it, I kind of got it to work but your setup is very alien to mine so me being new didn't help so I went down too many rabbit holes trying to figure out if I had things right. On the upside I did learn how to get the LOD boxes perfect. Going back to my blend file I was able to get my objects into PIM, their footprint was perfect and they looked to be in the right positions in my lots. Unfortunately I can't confirm if it's my textures or the lack of a light setup that's causing the Models in PIM to look like black mould on the front view and a light grey on the side/back views. I'm probably making too many fundamental basic mistakes to put a finger on what the issue is.

Ok, I went back to your .blend file and worked it all out so I had a better grasp of what I was doing in your environment, textures look 10x better. Only issue is the rendered preview just shows a white filled boundary box, the material view is perfect, the SC4Model file ends up the same white box....It doesn't do this in my blend setup but either the textures look wrong or it's the lack of proper lighting in mine.

[ACEfanatic02 259]

On 9/21/2025 at 5:30 AM, Dono said:

Instead of a new post I'm just updating this one:

I downloaded your lighting blend file and had a go at adding my object to it, I kind of got it to work but your setup is very alien to mine so me being new didn't help so I went down too many rabbit holes trying to figure out if I had things right. On the upside I did learn how to get the LOD boxes perfect. Going back to my blend file I was able to get my objects into PIM, their footprint was perfect and they looked to be in the right positions in my lots. Unfortunately I can't confirm if it's my textures or the lack of a light setup that's causing the Models in PIM to look like black mould on the front view and a light grey on the side/back views. I'm probably making too many fundamental basic mistakes to put a finger on what the issue is.

Ok, I went back to your .blend file and worked it all out so I had a better grasp of what I was doing in your environment, textures look 10x better. Only issue is the rendered preview just shows a white filled boundary box, the material view is perfect, the SC4Model file ends up the same white box....It doesn't do this in my blend setup but either the textures look wrong or it's the lack of proper lighting in mine.

The first part here sounds like an export issue; texture ID collision maybe?  I dunno.  Screenshots help when it's a visual bug!

For the second:  it sounds like you may be seeing the LOD box itself.  They need to be set to not render (and I generally turn the viewport display off as well, myself):

The camera icon here needs to be crossed out to prevent the LOD from showing in the render.  (Separately, you need to turn off the eye if you want disable viewport display, which will let you use the viewport rendered mode to preview things without the LOD getting in the way.)

[ACEfanatic02 259]

I still owe folks an updated version of light rig (with scene-referred lighting and night support).  It's coming, I'm just a bit swamped with work and a few unforeseen Life Things at the moment.

Anyway, I was looking through the output of rendering some of my test buildings and I have some thoughts.

When it comes to custom content in SC4, we're limited by the engine we're working with.  Most importantly, we're limited by memory; modern GPUs eat low-poly geometry for breakfast and it's not like there's horribly complex shading going on.  However, the game is still a 32-bit process, and even with patching it is limited to 4GB of memory.  Therefore, the limiting factor on how much custom content a player can use is the memory cost of that content.

This is my main concern about supporting the Maxis-style nightlighting:  DXT3/DXT5 are twice the memory cost of DXT1, representing an extra 50% of texture memory in a BAT to support the blending.

However, there is another aspect of texture waste I've noticed, and I think it's fixable.

As I understand it, the prerendered texture is projection-mapped onto the LOD mesh via UVs computed at bake time.  Additionally, the large renders are chopped up into 256x256 tiles (presumably the largest texture supported by the game?), with the LODs also sliced to fit the tiles (one mesh per texture).

The implementation is straightforward, but looking at the results there's a lot of inefficiency.  Many tiles have limited coverage:

Some tiles are _empty_:

(Both of these are looking at the alpha channel only.)

The result is we spend a bunch of memory on blocks that do not contribute to the actual image.  Some inefficiency is necessary unless we precisely match LOD to model, of course, but I think we can do better.  (My concern here is CPU RAM.  Ironically, 256x256 DXT1 is smaller than the smallest block of texture memory you can actually allocate in DX12 due to alignment rules, so there's some guaranteed VRAM waste no matter what, but GPUs are a different address space.)

So, proposal:  slice the texture into smaller tiles/strips (say 16x64), then after rendering trim the strips to fit the actual rendered pixels (aligned up to 4x4 blocks), and pack the trimmed strips to 256x256 texture atlases.  Finally, update the UVs on the mesh slices according to the final location in the atlas, and merge any LOD meshes with the same LOD level and atlas.  Remap any empty strips to a known-empty pixel.

I'm making some assumptions about how the game manages assets, namely that it allows multiple LODs, rotations, and / or zooms to share the same texture, but that _seems_ logical to me.  Especially since large buildings get sliced up anyway.

It'd take a bit of complex code to get this working (although I _assume_ Blender has rectangle packing exposed somewhere for UV reasons), but it would likely do a lot better job of actually using the texture space we allocate.  For most small-medium sized BATs you could probably fit all of LOD1 and LOD2 on a single atlas.  The extra UV seams likely hurt software rendering a bit, but GPUs would have no problems.  (And it's fair to assume players have a GPU; Windows itself has required one since Vista, IIRC.)  Likely the hardest thing would be fitting the UVs in a way that avoids bilinear filtering issues in Z6.

[memo 1,446]

@ACEfanatic02 A few thoughts on that:

- I have no indication that running out of RAM is really an issue that is a concern that needs to be solved. The 4GB patch is only needed for the huge NAM Controller. Starting with NAM 50, the NAM Controller will be vastly reduced in size so that the 4GB patch isn't even required anymore (and loading the first city tile will be much faster as well).

- Slicing the LODs into anything smaller than 256×256 pixels implies that the S3Ds will have a lot more vertices and polygons. I assume these would be less efficient to render in game. What's important though is that the game has a hard limit on how complex an S3D model can be. It's in the order of about 500 polygons. So the benefits of saving on memory for FSH files would need to be weighed carefully against these drawbacks.

- The slicing done by BAT4Blender is already much less wasteful than BAT4Max. The latter uses unnecessarily wide margins around the LOD, and always outputs 256×256 texture tiles, even when they could be much smaller.

- BAT4Blender already discards empty tiles, but only if there's no LOD mesh that's part of the tile. In your 2nd image for example, there's going to be part of the LOD mesh on that tile, even if it's invisible. This could be optimized away, but it also requires consideration of night lights – for example, same glow effect could be visible in the tile.

- There's some room for optimization in the way the renderings are sliced up, but I'm not sure it's worth the added complexity. I think the slicing shouldn't be done at the expense of more complex S3D models. It makes more sense to follow what Maxis has done in SimCity_{1,2,3,4,5}.dat. Namely, FSH files of multiple models for the same zoom level are packed densely into 256×256 textures. This mainly makes sense for models of the same zoom level because only those will have a chance of being in memory/being displayed at the same time.

Doing this kind of optimization doesn't have to be limited to BAT4Blender, as it can be implemented entirely with the FSH and S3D files as input. It could be implemented as a separate tool that repacks your plugins, for example. Doing this for just a single model in BAT4Blender in many cases doesn't provide a lot of wiggle room to achieve a better packing.

[ACEfanatic02 259]

3 hours ago, memo said:

- There's some room for optimization in the way the renderings are sliced up, but I'm not sure it's worth the added complexity. I think the slicing shouldn't be done at the expense of more complex S3D models. It makes more sense to follow what Maxis has done in SimCity_{1,2,3,4,5}.dat. Namely, FSH files of multiple models for the same zoom level are packed densely into 256×256 textures. This mainly makes sense for models of the same zoom level because only those will have a chance of being in memory/being displayed at the same time.

Doing this kind of optimization doesn't have to be limited to BAT4Blender, as it can be implemented entirely with the FSH and S3D files as input. It could be implemented as a separate tool that repacks your plugins, for example. Doing this for just a single model in BAT4Blender in many cases doesn't provide a lot of wiggle room to achieve a better packing.

_Does_ the game stream textures for different zooms, etc. dynamically?  I would have assumed that they're loaded up front and always resident in memory.  Back of envelope math says a 256x256 tile at 1.5 bytes/pixel (DXT1 day, DXT3/5 night) is 96KB.  Assuming 4GB patch, and saying we want to reserve about 512MB for simulation, sound, etc., we have about 3.5GB to play with, or 3,670,016KB.  Dividing by 96KB gives a little more than 38299 tiles.  That seems like a lot, but a medium-sized building can need 20-30 images with an HD render, so we can afford roughly 1000-2000 BATs.  (Give or take; this is a Fermi estimate, it's approximate to the order of magnitude.)

Obviously, if we're streaming in only the things needed at any one time, we can afford considerably more.  I also agree that optimizing this across an entire plugins folder makes more sense than locally per-building.  At the very least, seems like a useful thing to do for stuff like prop packs that have tons of tiny sprites.

Did not know about the limits on S3D files, that's useful to know.  I wonder if they're using an 8-bit index buffer or something?  Definitely makes the idea of slicing things up further a bit less appealing.

[Null 45 3,048]

45 minutes ago, ACEfanatic02 said:

_Does_ the game stream textures for different zooms, etc. dynamically?  I would have assumed that they're loaded up front and always resident in memory. 

AFAIK it does. You can usually see the streaming in effect by loading a close zoom and quickly scrolling across the map, it takes a few seconds for the building rendering to catch up. I would expect that it only keeps models/textures loaded that are within a certain radius of whatever is currently in view.

IIRC SC4 had to run on machines with 128 MB of RAM, so using some form of streaming would be necessary to make the game work.

[Dono 178]

On 25/09/2025 at 3:01 PM, ACEfanatic02 said:

The camera icon here needs to be crossed out to prevent the LOD from showing in the render.  (Separately, you need to turn off the eye if you want disable viewport display, which will let you use the viewport rendered mode to preview things without the LOD getting in the way.)

Sorry for the questions. I had my setup as you suggested above. After a lot of trying to get things to work the only variable I can see causing the white boxes on my model is there's something in your settings or something I'm not accounting for. I started from scratch with your rig and as well as a new project. I did the exact steps in recreating my Object in yours and in the new one. Both projects set-up the same, apart from your lighting. With yours I keep getting the white box, the other works but without correct lighting is a bit dodgy.

I don't mind if you suggest me to go and use gmax or bat4max, etc, I'd take no offence, I totally understand a group of you are working hard to get this 100% and me starting my Bating journey here could be more of a nuisance. Any suggestions would be nice but if none come to mind, at least I've learnt a lot about Blender 😊.

[gutterclub 2,729]

Enjoying watching the progress of this thead, even as a stuck in my ways, always user Max 2015 and BAT4MAX BATer! If you can ever figure out a way to stop Z5 being blurry on HD BATs even better lol

[AP 3,588]

Hi Guys, just found this topic and became super excited! 

After having used GMAX for years to model, I have started using blender for other projects. Does BAT4belder work well? Is there a guide how to install and use it somewhere? 

[Dono 178]

3 hours ago, AP said:

Hi Guys, just found this topic and became super excited! 

After having used GMAX for years to model, I have started using blender for other projects. Does BAT4belder work well? Is there a guide how to install and use it somewhere? 

Hey mate, BAT4Blender will be awesome when fully completed. It works but at the moment they are working on the lighting. Once you have created your object or imported one into Blender it literally takes minutes to have it ingame. If you are competent in Blender you might be able to manufacture lighting that works but that's above my pay grade so I'm eagerly waiting.  

To install just follow the readme from the download on the first post (disregard the 'Pull Request' file, it's no longer relevant), it was easy enough to follow. I don't believe there are actual instructions to use it...unless I've overlooked them somehow. Any other questions you may want to look at my recent posts, I've probably asked all the dumb'ass questions here and those involved have been nice enough to enlighten me. 

[ACEfanatic02 259]

On 9/26/2025 at 3:06 PM, AP said:

Hi Guys, just found this topic and became super excited! 

After having used GMAX for years to model, I have started using blender for other projects. Does BAT4belder work well? Is there a guide how to install and use it somewhere? 

It still has a number of sharp edges.  If you need something to Just Work... for now it's probably best to use Gmax (assuming Gmax works on your machine; it does not for me).  However, I think we're pretty close to something usable?  The more people who use it, the more community support there will be for debugging issues.

Speaking of which:  I finally went in and cleaned up my light rig, tying it into memo's updated script so it will render MN and DN as appropriate.  See attached.  Note that for this to work correctly, any night lights must be placed in a collection named "Night", otherwise they will show up in the day render as well.  All emissive materials will show in both day and night; if you want night-only emissive, you can create multiple copies of the object with different materials in in "Day" and "Night" collections, or add a driver within the material itself.  This is the best compromise I could find to allow lights and emissive materials to be used during the day (for neon, etc.) and still have everything react correctly to night lighting.

Note that the light rig (both the World and Compositor graphs) is heavily dependent on drivers, which do not survive copy-and-paste.  So if you want to add this rig to an existing model, it's better to import that model into the light rig scene instead of trying to copy the node graphs.  (Now that I think about it, it might work better to make these Assets.  Will have to try that next.)

ace_light_rig_004.blend

EDIT:  WARNING:  this light rig was created in Blender 4.5.3 LTS, and has been shown to cause broken renders (solid grey output) in earlier versions.  Please use 4.5.3 or later with this.

  Edited September 29, 2025 by ACEfanatic02  
Add warning about version incompatibility with the light rig.

[Dono 178]

1 hour ago, ACEfanatic02 said:

ace_light_rig_004.blend

Ok, so I start in the right direction....
The Pic is my Collection Scene the instant I open your file and go to "Layout".
Do I leave all the "visible" and "render" Icons as they are .... or do I for example, remove them on the "cube" and add them on the "b4b_sun"?
Once my Object is in the scene and ready to go do I delete your LOD1 thru 5 and add them again in B4B so the bounding box fits them, or just leave them alone?
and lastly, do I leave your camera alone or do I adjust its window to fit my Object through the render process.

As before, I can render my Object with B4B without a problem but again is pretty crap visually without the lighting. But when I add the same Object (Security Fence) to the light_rig I get a white box at whatever size the bounding box is. I did look into all the available Blender info regarding the causes of the white boxes but couldn't find anything relatable in my Object.

If anyone has a simple 3dprop file I could test on that would help, I'd at least know if it was my file or the way I'm executing B4B.

Thanks.

[ACEfanatic02 259]

1 minute ago, Dono said:

Ok, so I start in the right direction....
The Pic is my Collection Scene the instant I open your file and go to "Layout".
Do I leave all the "visible" and "render" Icons as they are .... or do I for example, remove them on the "cube" and add them on the "b4b_sun"?
Once my Object is in the scene and ready to go do I delete your LOD1 thru 5 and add them again in B4B so the bounding box fits them, or just leave them alone?
and lastly, do I leave your camera alone or do I adjust its window to fit my Object through the render process.

As before, I can render my Object with B4B without a problem but again is pretty crap visually without the lighting. But when I add the same Object (Security Fence) to the light_rig I get a white box at whatever size the bounding box is. I did look into all the available Blender info regarding the causes of the white boxes but couldn't find anything relatable in my Object.

If anyone has a simple 3dprop file I could test on that would help, I'd at least know if it was my file or the way I'm executing B4B.

Thanks.

You can leave everything in the BAT4Blender collection alone.  The sun light is not used for rendering, I only use it to drive the rotation of the sun disc in the World lighting.  The only thing in here you may need to adjust is the visibility flags on LOD1-5, to show or hide them in the viewport for the sake of editing.  They should never be toggled on to show in render, as that will obscure your actual model.  The position and size of the camera are driven by the BAT4Blender script, so you should not touch them.

Everything under the other collections is the stuff you're rendering.  If you mark it as not visible, it won't render; that can be useful sometimes but in general you want everything set to visible.

Make sure when you're rendering you use the actual B4B tools instead of the Blender render command:


Use "Preview" to confirm you have a good fit for your LODs  (you can use the "Add" and "Delete" buttons on this pane to refit the default LODs) and to check if you have any issues with your render.  It renders the same way that the final render will, so it should be WYSIWYG.

If you're still seeing issues, I think we need more information to be able to help.  Specifically:  show us an example output of the render, and show what your setup is in the outliner.