Gone FSHin'

[Flann 1,709]

3 hours ago, junspud said:

Was going to do texture overrides for a few textures (BSC_TexturePack_Cycledogg_V 01) and came across this, 4 textures/alphas with the same ID but with C1/A1 C2/A2 ect. Haven't seen it before and was wondering what it meant? I tried the PDF but guide but wasn't able to find anything about it or maybe missed it.

 

Thanks.

I'm guessing that's a multi FSH and the game picks one randomly?

----

Well, I was doing some work on our embedded mipmap RHW textures.  After very carefully recreating properly color corrected versions of the base textures, I put them through GoFSH and checked the 'mips' option.  I was very dismayed to see that the colors did not match.  I was perplexed, I double checked my work and everything looked good, but in game they were wrong.

On the left is a normal network texture and the right is a model based piece.  I overlay the original GoFSH darkened texture on the left and the re-extracted texture on the right.  You can see that it encoded the color of the shoulder slightly different.

Eventually I overcame this by choosing A8R8G8B8 instead of auto DXT.  Question is - is this what you would have expected to happen with those original settings?

[rsc204 21,808]

8 hours ago, junspud said:

Was going to do texture overrides for a few textures (BSC_TexturePack_Cycledogg_V 01) and came across this, 4 textures/alphas with the same ID but with C1/A1 C2/A2 ect. Haven't seen it before and was wondering what it meant?

Indeed this is a Multi-FSH, it's like a texture family, for each tile the texture appears on, one of the variants will appear at random. Maxis used this for a number of the Grass textures, so large areas look less repetitive but you need to be careful to use textures that all tile together.

[rivit 3,391]

You've found a set of related textures that are all saved in the same FSH - so called multifsh. SimCity has a mechanism where it can save multiple images in one FSH and it chooses at random which one to display. This is used in Lot textures (mostly) to give variety and to combat texture repeats that might distract the eye - In this case for variety. The technique also used to make framed animations (the surf at waters edge is an example of that).

GoFSH automatically splits the FSH and numbers them from C0 to Cn as you see. It can handle up to n=99.  And it also knows how to make them again if correctly numbered. Quite easy to make for yourself - just put some similar textures and number them TGI-C0 to TGI-Cn and off you go.

Mentioned in the Glossary, and on p11 of the manual - how to load. In GUI batch figures it out for itself.

[rivit 3,391]

@Flann

It is a feature of DXT processing that there will be color changes - its a lossy process - and they show up most on roundtrips bmp->dxt->bmp. The problem is caused by the fact that DXT is 16 bit color and is reconstituted on decompression from 2 16-bit colors. The more original colors in a 4x4 pixel block the worse it is. The A8R8G8B8 drops nothing.  

So on compression the best 2 colors to reconstruct the 16 pixels in a block are deduced and stored as 16 bit values (5R,6G,5B). This is repeated for all 4x4 blocks. In effect all 32 bit values become truncated (the low bits go in each channel). On reconstruction those missing bits are still missing, so this round trip can result in minor color differences (we are talking about 0-4 bits of color pixel channel). Some values are more affected than others - by default white FF,FF,FF usually comes back as F8,FC,F8 which is very slightly green. If you're calibrated and sensitive you will see it - even in-game.

In GoFSH I try to improve the result on decompression by adding a logical guess at what may have been lost (on average) back to the decompressed result.  But its nearly impossible to get some colors back the way they were on a round trip. 

[junspud 1,066]

Thanks for letting me know. Always finding new stuff out, I managed to completely miss the entire concept/existence of multifsh.

[Flann 1,709]

2 hours ago, rivit said:

@Flann

It is a feature of DXT processing that there will be color changes - its a lossy process - and they show up most on roundtrips bmp->dxt->bmp. The problem is caused by the fact that DXT is 16 bit color and is reconstituted on decompression from 2 16-bit colors. The more original colors in a 4x4 pixel block the worse it is. The A8R8G8B8 drops nothing.  

So on compression the best 2 colors to reconstruct the 16 pixels in a block are deduced and stored as 16 bit values (5R,6G,5B). This is repeated for all 4x4 blocks. In effect all 32 bit values become truncated (the low bits go in each channel). On reconstruction those missing bits are still missing, so this round trip can result in minor color differences (we are talking about 0-4 bits of color pixel channel). Some values are more affected than others - by default white FF,FF,FF usually comes back as F8,FC,F8 which is very slightly green. If you're calibrated and sensitive you will see it - even in-game.

In GoFSH I try to improve the result on decompression by adding a logical guess at what may have been lost (on average) back to the decompressed result.  But its nearly impossible to get some colors back the way they were on a round trip. 

Am I understanding correctly that it may actually be impossible to store the precise RGB value in a DXT compressed FSH?  Because on the shoulder of the RHW tile, there is only one color. In this case, it should be 64 63 57, but it is rendered as 66 65 57.  In the image I posted earlier, I showed that the BMP resulting from decompression matched the game's render exactly.

[rivit 3,391]

Yes, a majority of colours will be impossible to get exactly the same - DXT was cutting edge anno 2000 tech when many gfx cards were 16bit and hard drives were measured in GB. SC4 will dither output colors if put into 16bit mode. Today we would just be able to do everything in 32 or more bits, and/or use more sophisticated compression.

According to the DXT spec, color channels that are multiples of 8 for R,B and 4 for G are most likely to stay correct (because the truncated bits are empty). But SC4 does something to them as well. Quite apart from the truncation (which applies to all pixels) we dont know exactly what SC4 does when it displays the result - different textures are displayed differently - so Native Network and Network Model textures for instance appear to be rendered by different routines (hence the need for darkening or brightening textures - which is a can of worms too). Lots and BATs are slightly different again, Terrain yet another routine.

SC4 does seem to do some compensation after decompressing the DXT  (I can't tell if its SC4 or DirectX) and I try to match that in GoFSH. I do that so that roundtripping game textures for which we only have fsh will not drift too much. They won't always match 1-1 with the original (if you've got one), but like your numbers above they'll be close enough to be undetectable for most people although unlucky RGB values exist. It takes a really practised eye or direct image compares to spot that difference. If a monitor is off calibration or of a low reproduction quality other problems will swamp this. (quite a few LCD screens come to mind, not the modern IPS or OLED screens).

For those making things its a bane, but its a necessary tradeoff because we can't store all 32 pixel bits in DXT for color consistency, and get high compression ratios. Choosing colors that are less susceptible is possible but you'll need to experiment/test/adjust to get control of it.

[Flann 1,709]

Thanks for the explanations.  I've done a bit more reading on DXT compression and I think I understand the limitations now.  If I want to be extremely picky about the textures matching between a normal network and a model-based network, I either have to use strictly A8R8B8G8 FSH or I'd have to find a color for the shoulder that maps from RGB888 to RGB565 and also for which the N to Z adjustment maps to RGB565, which I'm guessing might be mathematically impossible.

[rivit 3,391]

Thats it in a nutshell - if we can reliably get to within 4 on G and 8 on R and B then thats better than the resolution of default DXT, and you havent made it worse than before. The ARGB8 solution for the RHW models is fair compromise because they will get used literally 1000s of times - thus justifying the quality/size need.

Given that even the Colour correction is a best means fit to the data I could get out of the game that would be about it. In the end its about "where do you want to accept the compromise". The darker the color the less it shows, but the more it distorts when its lightened up again. The problem is most noticeable when 'original' and 'corrected to match original' end up right next to each other in-game,  which does happen for instance when a network hits a lot or transitions to a model, but as long as its a reasonably close match its probably not jarring enough to warrant complaint. SC4 isnt perfect in any case.

The formulas for N to Z (integer math) as applied in GoFSH are on page 19 of the manual. There are probably some values that would match as you would like - but I'm figuring there are few in that dark end of the colorspace.

[Flann 1,709]

If I did the conversion correctly, I think the best color has already been chosen.

[rivit 3,391]

Yes, I think you're right esp. for the network texture. The Darkened column should be truncated (floor) rather than rounded - that will have a small effect on the right hand diff columns.

While we don't know exactly what the correction does in game - its a best compromise - some near values have really quite large differences (what I meant by unlucky values) so the 1s and 2s are really not a bad fit all.

[Flann 1,709]

I think I've discovered a bug.  I'm trying to do some wealthing via script and GoFSH appears to be flipping the definition alpha for the wealth zero texture:

 

Here's the files for testing.  I'm using GoFSH v4.8.4.6D8C

TEXTURES.7z

 

[rivit 3,391]

Hi Flann,

Its definitely repeatable - goes wrong on mine too. It's got to be related to that flipping change I made (pun intentional), but what isnt obvious yet is - why just the Wealth 0. Will get back

~~~~

First debug shows that if I backout the gmax flipping change its all OK.

There was one execution path I had missed (ugh) - however its used in all generation routines, uses different elements where you can't tell if its right way up or not. It didn't flip the Alphas as they were made at all so it only showed on W0 because the other alphas were all white.

I'm of a mind to revert the flipping change altogether (and finding/making a different fix for that issue - I could put something in PNG<>BMP) as it's disruptive in effect. Currently all GEN Wnn commands will be faulty - I missed noticing these when checking the results of my test suite and hence outsmarted myself by being too hasty. Fixing the whole flipping thing will make GoFSH slower and potentially unstable, so I'm in the undo camp. What do you think?

The 3.8.3 version (still on my archive) is the last one before those changes. To be able to work forward until I fix this I suggest you install that again.

Ron 

[Flann 1,709]

Thanks for checking it out.  My thoughts are that the gmax issue can be pretty easily defeated with other easy (if tedious) workarounds so it is probably not worth making a change that will destabilize GoFSH as a whole.  If you are still interested in working on a solution for that after reverting this one, I'll leave it to you to decide how best to implement it.  If there's no easy fix, don't worry about it.

[rivit 3,391]

@Flann

I've persisted (by changing where the flipping takes place) and made sure the bottom-up saving of bitmaps is now OK. This maintains the compatibility for old windows programs and fixes the problem reported above.

I'm quite embarrassed by that glitch - totally self inflicted. Therefore, versions 4.8.4 and 4.8.5 should be upgraded to this new version 4.8.6 (on my onedrive) immediately - please be wary on production work until its proven correct - i.e. check your outputs thoroughly, and let me know if you see weirdness. Versions up to and including 3.8.3 were fine.

~~~~

Also as I had to change the code anyway I've implemented a change to Slice'n'Dice for Lots that @redfox85 requested so that if a Tile is Black it will be skipped and only non-black tiles will be numbered and cut.  This allows one to be selective about which Lot Layout Tiles will get generated if you aren't intending a whole lot to have new tiles.

[junspud 1,066]

Maybe dumb question but what circumstances would you use the 'recode mode'? I was thinking you could use it to rename the largest zoom levels identity and it would propogate to the rest of the zoom levels with recode, or otherwise change the TGI for the 4x zoom and recode it and it would generate the the rest of the zoom levels from that single fsh file with the new TGI, but I think I'm misunderstanding as it hasn't been doing that.

 

Also not sure if it's a bug or revision and I missed it in changelogs, but 4 of the checkboxes under 'encode settings to' just say 'as' on my machine. Hovering over them still brings up the description though.

 

Thanks..

[rivit 3,391]

On 1) The recode option goes back a long way to the early days of GoFSH before it had any scripting or the ability to make a .dat. It was intended to make it easy in Batch mode to add a new tile to a set already there that you had made say with mips and then just redo all previous fsh from before without having to fiddle all of the settings again. It unpacks, then repacks fsh as they are.  In many ways its obsolete now as there are far better ways to control what you want to make.  The index option is similar - it just makes an index list for use with reader or FSH to DAT from a folder of FSH.

on 2) it appears your default font is quite a bit larger than the one the exe was made with. It was designed using Arial 8pt as back then there were still XP machines about. The font being substituted look likes its 10pt or 11pt or so (still Arial I think) and as consequence the texts are now just too long to fit in their textboxes and get truncated/pushed out of view. Haven't seen this before - it suggests you can't display/don't have Arial 8 on that machine and it gets substituted with a nearest match by .net.  It should look like this:

Have you made your default OS fontsize larger or changed the default screen Font by chance in Settings/Personalisation?

Otherwise, not sure how to proceed from here - anyone have any ideas for how to pin this down/ fix it?

 

[matias93 7,535]

1080p and bigger screens tend to be used with some degree of screen scaling, which isn't very consistent across different programs. The solution, albeit a bit inconvenient, is to change the scaling configuration for the whole OS on the screen settings; that seems to be Windows 7, so is the one that can be found with a right click on any empty space on the desktop (I'm now on Windows 10 so I cannot show how it's done).

[Propfam 2,288]

On 8/27/2023 at 2:39 PM, matias93 said:

1080p and bigger screens tend to be used with some degree of screen scaling, which isn't very consistent across different programs. The solution, albeit a bit inconvenient, is to change the scaling configuration for the whole OS on the screen settings; that seems to be Windows 7, so is the one that can be found with a right click on any empty space on the desktop (I'm now on Windows 10 so I cannot show how it's done).

There are options called Application, System, and System (Enhanced) in the HiDPI setting of a shortcut. It turns out, it's the Application scale that messes things up. Using other than that or simply deactivate HiDPI override, it's back to Rivit's intended design.

[junspud 1,066]

Originally I had posted 3.8.3 was displaying the text correctly compared to newer releases, not sure if I was imagining things or what, but that wasn't the case when I launched it today. It was the DPI settings (increased to 109%) which was causing the issue. The text has a hover overlay anyway so it's not a big deal.

 

[junspud 1,066]

I was wondering, is there a sleep/ballast/rail texture set for the RRW reskin repo that produces the original Hybrid Rail textures? Also was wondering, in the RRW reskin repo, about the RRW-Reskin to RRW network transition and the  RRW to Hyrid Rail transition textures, and the hybrid rail texture folders, are these obsolete in-game?

Thanks.

[rivit 3,391]

Not an easy a question to answer as it evolved quite few times before reverting to RRW colors. I dont actually have any original NAMs of that era floating about. From looking in an old source archive I had from Eggman121 at some point, these look to be the best guess:

A Rail.bmp,  B Rail.bmp, Sleeper.bmp, Ballast.bmp   'not sure which rail won.

However these could have been intermediate ones too.

If these are not the ones then in the RRW reskin pack, under zresources/example texsets/Eggman there are other textures I know he used and these may have been where he started HRW from. 

~~~

AFAIK the transition RRW-HRW piece no longer exists in NAM, the hybrid rail folders all get rendered to RRW colors and exist (for elevated pieces) in the NAM HRW/Textures folder. The others parts of HRW are RRW reused for ground networks. If you retexture the HRW pieces only the elevated ones will change, or rather those before NAM 44-45. If anythings been added since it may not be in the NAM45 Reskin archive.

There isn't an RRW Reskin to RRW network piece as such - as the reskin was assumed to change everything. We did make an exception for Simmer2 lots, for which he made transition pieces to avoid having to make new tiles for all of his lots.  Having the textures wont do harm however as I dont think theres code referring to them anymore.

[rivit 3,391]

These holidays Ive been doing a little work with GoFSH and conversions between the different Night Textures like  Darknite or MaxisNite.

Manipulating BAT day and Night Textures with GoFSH 

In Simcity4 nights are rendered by using a darker daylight, namely  RGB 128,128,192, and then alpha blending the so shaded BAT Day Model (FSH yyyy0xxx) with the Night Model Texture (FSH yyyy8xxx). 

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

The gmax BAT scripts (the original SC4 modelling tool) make the Day and Night model textures in their rendering processes. The Night texture is relative to the Day texture. Now this scheme is quite clever because the NightColour can be varied, and the entire render will be always correctly shaded – this is what happens at sunset/sunrise in the game.

Later in BATting history,  BAT4MAX (3dsMax) scripts were devised to enable BATting with that program. This gave better lighting and rendering, and a more powerful program to use. It was quite a breakthrough. Now because not all of the processes that the Gmax scripts used were available in the 3ds Max environment (eventually) two new standard renderings came into being – the 3ds MN (MaxisNite 115,113,176) – a near equivalent to the Maxis lighting but slightly darker, and 3ds DN (Darknite RGB 50,50,75) a much darker coloured night.

For demonstration I’ve used gshmails Bondell Bandshell from 2005 (on Simtropolis), an old favourite of mine, because it has a one tile texture and features that help explain what follows.

Here are various Night Renderings of the Bondell BandShell:

See how the shading of the shell itself varies and the lighting stays pretty much the same.

These 3ds shading models have become standardised (over time) but have two main disadvantages relative to the gmax standard that the game was designed with:
1.    The colour curves are blacker, and in DN very dark. The newer 3ds colour models are more northern and colder, have a larger colour span and are quite non-linear. SimCity was designed the Southern Californian climate – it’s warm and relatively desaturated. Master Batters have compensated in their textures and render techniques to keep compatibility with the older style – but Bat4max models frequently look more clinical.
 
2.    The 3ds night renders are Fixed – they have an Alpha=1 and so override the day part of the equation above. This means they can’t adapt to sunset/sunrise, and you will see these models keep their night colour in-game until its daytime, and so stick out as different if used in a standard SC4 lighting. However, this isn’t true the other way round – gmax models will automatically adjust to Dark Night.

Sometimes a BATter will only render a DarkNite model – what do we do now? We can use it as is in SC4 without any penalty except graphical differences. Nothing breaks.

Some time ago I analysed the BAT4Max colour models and produced a means of converting from MN to DN, and from both back to a variable MAXIS night model. This has been built into GoFSH. Also, my most recent additions to GoFSH (see 4.8.7 on my Onedrive) have been to enable the production of the 3ds fixed renderings from Maxis Models, so that complete round tripping, with unavoidable quality loss of course, is possible. 

However, this is not the only thing that can be done with these processes. The key step is creating working Night Model Lights from a fixed Rendering. These Night Model Lights are more extended than the gmax ones and can be manipulated independently. 

In the case of our Bandshell here are two example manipulations:

So here we have, top left the two components normally blended in a night render and top right, the GoFSH derived Night Model Lights from that Render.

Note how the yellow of the lighting is all over the light model (it doesn’t all show in the render because of the alpha blending). If we assume that the walls of the Bandshell are solid and actually join the foundation then the yellow at the base outside shouldn’t be there, and at the back the yellow should not have leaked through the shell. These were presumably rendering limitations of gmax.

We can take those errors and desaturate the lights in those places. I've followed the logic that light travels in straight lines from the source. This will remove (correct) the yellow leakage. Furthermore, if we so wish we could change the yellow lighting to another colour – I’ve picked a magenta for the purposes of demonstration.

In all of this we have not touched the original Day Model (which could also be edited in its own right), but we have extracted the lighting component for our purposes.

Now here is the result of our manipulations rendered in a standard SC4 nighttime:

Far right is shown the result of packing up the FSH into an override .dat of the original mod and then used in-game at night. It hasn’t changed during the day. Please note it’s not a perfect process – but quality losses can be contained.

All of this is done with GoFSH, and an image editor (I just happen to use an ancient Photoshop 6) 
Standard Process is this:
1.    Using GoFSH FSH<>DAT extract the FSH (all of them) from the Model File.
2.    Using GoFSH decode the fsh (use 32bit  to avoid loose A0 bitmaps.)
3.    If you have gmax textures (variable alphas) using GoFSH ColourAdjust, create a fixed Maxis render. If you have DarkNite or MN Textures only (Fixed alpha) then this step isn’t necessary.
4.    Using GOFSH ColourAdjust using the appropriate option, derive Lights from that render.
5.    Optionally, with your image editor do what you want with those Lights.
6.    Encode the Day and Light (Night) images with GoFSH.
7.    With FSH<>DAT package the same in a new DAT.

Step 5 is the hardest step. Each texture in the model needs to be touched (at least 20). You need to have the skills with your editing tools, and it becomes tedious with large models requiring hand editing, but sometimes it’s just what you want. Colour changes can often be automated in Photoshop.

 

[junspud 1,066]

On 1/10/2024 at 5:26 PM, rivit said:

Colour changes can often be automated in Photoshop.

Always really liked these S-Bahn under-rail lots, except for the red/brightly colored textures used in them. Maybe it would be feasible to change them to something darker using some variety of these methods.

Recently I was able to use Photoshop and GoFSH/Bender to quickly and easily change an existing draggable MMP texture into a different colored texture to match a dirt texture I had started using.

I have no batting experience at all (and wouldn't really want to entirely re-bat something just to slightly change the coloring of some of the model anyway) so being able to use GoFSH to accomplish these things is pretty awesome.

[rsc204 21,808]

If you have already recoloured an existing BAT, then the process is the same as before. The problem being that your changes need to be consistent across each of the 20 (min) textures that make up a BAT. If you are skilled enough with Photoshop you can speed the process up a lot. You can create a mask from the RGB channels and apply a colour mask to that, which will give you control over any changes allowing for a consistent change for all images. But this doesn’t require the new tool in GoFSH, which honestly if I’ve understood everything it really intended for the lighting/note renders. 

[rivit 3,391]

TLDR: I may have discovered a general method for night-lighting props made manually outside of BATting and that enables props to be lit at night when used as T21s. The process isn’t difficult but requires knowledge of Reader, Prop Exemplars, S3D models and FSH and how they work together.

 

Night Lighting for Handmade Models, and Pre-lit Props to be used as T21 props.

What follows is fairly technical, but not crazy complicated. People who know how to edit S3Ds and/or Props in Reader will have no problems.

While meandering around night lighting, I found new method (for me anyway) for making lights show up on S3DModels to be used as Props. It’s related to techniques used for doing headlights and taillights on Automata and light cones in Night Lighting Mods like LRM.

First a little background. Props are usually made by referring to a model which may or may not have been BATted to have night lighting. If it does it has 8xxx textures which the game then automatically applies at night to show lights. I described this in my previous post.

What isn’t as well known is that if those pre-lit props are used as Network Props (Props to be placed on/alongside networks) then the lighting doesn’t work – it just won’t be applied. Also, if an S3D model is made by hand, there isn’t a ready way to make it lit, although an approximation of night lights in the texture can be made easily. However, it probably won’t be rendered as intended.

So to demonstrate this I started from The Tardis - 3ds Models - Simtropolis, a model by ILTonsko created in 2005, that I knew I had somewhere. Its not night lit, so I wanted to show how easy this was to do by using it as a sample. When I looked up the model though,  I was a bit disappointed by it, so inevitably I thought I could improve on the textures, and in the process show a ‘cheats method’ for quickly making a prop model.

The TARDIS looks the same from all sides, bar the front sign, so One billboard model will do if we accept that the front door will always face us i.e. it will rotate with the view.

Taking the 0430 bat view I therefore went into Photoshop, armed with an internet picture of the TARDIS, and copy-pasted-transformed it onto two faces, and drew a new roof and top-light, staying inside the alpha bounds of the original drawing.

Then I cloned that final layer and made the windows and top-light as if they were lit, and an alpha mask for just that portion of the texture. I saved the new textures as 32bit C0 textures, then turned them into fsh and into a .dat.

Now we have a day and light texture, and the question is just how do we turn these into a night-lit model?

Taking to Reader, we use the 0430 model from the original, put it into our new .dat, renumbering it, and we make it point at our new day texture. We then clone it with an new IID, and make it point to the Light Texture. We know it has the right UV coordinates because all we did was cover the original render with our new images.

Its here that the find shows itself: The secret to making the night textures show is that we want the night lights to only replace the windows and top-light and leave the rest of the model as it was. This is like a primitive technique used way back for adding lights to a BAT in gmax.

The blending operation we need is remarkably similar to that used when making headlights/taillights work on automata or show light cones, except that we do not need to do this at the last minute in the framebuffer (the fully rendered scene), where they are alpha-blended.

For the day model (left), see the blend parameters in blue, and in the light model (right) the parameters in Yellow. This parameter change says that wherever the alpha of the source (the texture we are adding) is greater than 0.49999 (0x7FFF) show the source, otherwise show the destination (what’s already there). Our alphas are 1 or 0.

Now we are in a position to create the prop so that this will actually show in-game. Remember everything in the final scene is pasted onto a flat render surface. We want to render the day model, then the night model lights over the top at night when State=1, and just the day model during the day in State=0.

The Property Resource Key 4 is the magic step – it instructs the render in the correct sequence, and the Nighttime State Change makes it happen at the right time.

 

Here is the result in-game at ‘sizeof 5’ – it’s quite lo-res, but its recognisable.

Now this Prop is a cheat in that we use one view model for all four views and zooms. It will always face towards the viewer. It won’t be perspective-correct at zooms 1 and 2 but it’s so small you can’t tell. I’ve used this method to make tall thin, small items like light poles, boxes etc..

Note too, that it uses the state mechanism to do the work, so this prop cannot be made time conditional as that uses the same mechanism. If you don’t mind you can make the model lit at all times, and conditional.

Prop F5E800F8 is Day and night, F5E800F9 shows up lit from 20h to 21h every day.

 

Of course, once I’d done this I wanted a better one. I created full 3D Model from scratch in Reader, went through the steps above and here is the result:

It’s a bit more HD, though still an approximation and notice it doesn’t get a shadow, like the other one. (I don’t know why). See how the day model is modulated by the lightcolour, then the lights are pasted onto that. On rotating the view, we get to see all sides, and it’s always perspective-true.

There is a crucial difference in the Prop. Because the model is true 3D we need to make sure the render engine gets to see all four sides of the model. The Building Model Rotatable property is key to this. [the snappily named kSC4BuildingModelRotationProperty in Reader].

For this full 3D model  Prop F5E800FA is the day and night prop, F5E800FB the night-rendered, conditional one to show between 21h and 22h every day.

Here are the TARDIS props – they are usable in-game, but mostly intended as educational material.

RVT Tardis.dat

That was the find. Hope it’s as useful for you as it is for me.

This method will work for Lot Props and Network Props (used in T21s) and hence a general method to make T21 props show up lit at night.

Below the Marrast Ave FLUP in the NAM. Left is the default NAM look, right after fixing the night lighting. I used the original Marrast Props with the techniques of the last post to change the lights to Sodium from Mercury, then the techniques described above and below to make them show at night. I’ve also done all of the other Marrast FLUPS to prove the method works.

These are the considerations for T21s:

1.       Assuming the original model was pre-lit, the 8xxx textures need to have corresponding 8xxx models as they won’t have them from the BATting process. 

2.       These 8xxx models must use the dest(Src) blending mechanism.

3.       The 8xxx textures need to be (re)rendered with a fixed night render so that they replace the day textures in-game at night. They won’t work with the variable 8xxx textures because that uses a blend whereas here we are using a paste-over approach. GoFSH can do this.

4.       The T21 Prop should not have the Light Property and be named to show ‘for T21 usage’. The ResourceKey4 method is applied as above on the first example.

They cannot adapt at sunrise/sunset, but there is an opportunity to make them match with MN, DN or a custom Nite.

The Lot Prop and the corresponding T21 Prop, if so prepared, will work fine together in the same plugin set.

[rsc204 21,808]

Awesome, I was exploring this last year using RKT 4 / NiteState properties, but couldn’t work it out. If I ever find time (so much going on both in RL and the community right now), I definitely want to try this. Specifically to get my Phoneboxes lit up on T21s. But I can already think of other uses. 

[memo 1,444]

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

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

The information in this post on night lights is immensely useful. Thanks.

To test if my understanding was correct, I decided to run a quick experiment in GIMP to replicate the night view of a Maxis building using its day and night textures only. I've tested this with Simfox's Day and Nite Modd installed, which sets the night color to RGB=49,50,72, according to the FSH map 0x0917660e. (This differs slightly from the 3DSMax DN value 50,50,75 mentioned above – presumably a result of DXT compression.)

Using building texture 0x01F90230 as an example, I added a layer colored 49,50,72, set to Mode=Multiply, and added another layer for the night textures, but the result looked quite a bit off. Notice how the top floors of the Stage 8 building appear way too dark and the middle floors too bright.

To match the appearance of the game, the solution is to pay close attention to the gamma correction. Make sure the image was created with non-linear RGB space (advanced settings), change the Blend Space of the multiplication layer to non-linear/perceptual (instead of linear) and change the night layer to non-linear/perceptual Composite Space (instead of linear). I've also set the Composite Mode to "Clip to Backdrop" to eliminate the grey background from the night layer. This appears to match the in-game colors precisely now.

[rivit 3,391]

@memo  Yes - its well to note the (implicit) colour standards used - in all of my Photoshop and GoFSH color manipulations its sRGB nonlinear, and perceptual renders.

I presume these can be guaranteed by your newly revised BAT4Blender output settings. gmax and 3ds certainly didnt use linear RGB on output. My ancient Photoshop (2006) cant operate in linear sRGB for anything without first gamma correcting all of the textures. Newer ones do it under the covers for properly accurate blending. 

[Null 45 3,041]

Reposting the game's  network texture mapping table here at @Ulisse Wolf's request, all values other than None/None are the texture IIDs.

Spoiler

 

None[0]:
  0x00                      wealthNone  
  0x08100000                wealthLow
  0x08200000                wealthMedium
  0x08300000                wealthHigh
ResidentialLowDensity[1]:
  0x08200000                wealthNone
  0x08100000                wealthLow
  0x08200000                wealthMedium
  0x08300000                wealthHigh
ResidentialMediumDensity[2]
  0x08200000                wealthNone
  0x08100000                wealthLow
  0x08200000                wealthMedium
  0x08300000                wealthHigh
ResidentialHighDensity[3]:
  0x08200000                wealthNone
  0x08100000                wealthLow
  0x08200000                wealthMedium
  0x08300000                wealthHigh
CommercialLowDensity[4]:
  0x08200000                wealthNone
  0x08100000                wealthLow
  0x08200000                wealthMedium
  0x08300000                wealthHigh
CommercialMediumDensity[5]:
  0x08200000                wealthNone
  0x08100000                wealthLow
  0x08200000                wealthMedium
  0x08300000                wealthHigh  
CommercialHighDensity[6]:
  0x08200000                wealthNone
  0x08100000                wealthLow
  0x08200000                wealthMedium
  0x08300000                wealthHigh
Agriculture[7]:
  0x08400000                wealthNone
  0x08400000                wealthLow
  0x08400000                wealthMedium
  0x08400000                wealthHigh
IndustrialMediumDensity[8]:
  0x08200000                wealthNone
  0x08100000                wealthLow
  0x08200000                wealthMedium
  0x08200000                wealthHigh
IndustrialHighDensity[9]:
  0x08200000                wealthNone
  0x08100000                wealthLow
  0x08200000                wealthMedium
  0x08200000                wealthHigh
Military[10]:
  0x08200000                wealthNone
  0x08100000                wealthLow
  0x08200000                wealthMedium
  0x08300000                wealthHigh
Airport[11]:
  0x08200000                wealthNone
  0x08100000                wealthLow
  0x08200000                wealthMedium
  0x08300000                wealthHigh
Seaport[12]:
  0x08200000                wealthNone
  0x08100000                wealthLow
  0x08200000                wealthMedium
  0x08300000                wealthHigh
Spaceport[13]:
  0x08200000                wealthNone
  0x08100000                wealthLow
  0x08200000                wealthMedium
  0x08300000                wealthHigh
Landfill[14]:
  0x08400000                wealthNone
  0x08400000                wealthLow
  0x08400000                wealthMedium
  0x08400000                wealthHigh
PloppedBuilding[15]:
  0x08200000                wealthNone
  0x08100000                wealthLow
  0x08200000                wealthMedium
  0x08300000                wealthHigh

This table is hard-coded, but it can be overwritten by a DLL. The main restriction is that the game expects the texture IIDs to follow the 0x0xx0000z format, only zoom 0 (the furthest zoom) is listed in the table.