High Definition Props and Textures - Discussion thread

[Orange_o_]

Simfox:

You very well understood the explained principle , I have to inform you that I use Gmax and not 3dsmax.
The result which I obtains with this technique is visible on the corn field, previous page.
It is probably a waste of time for you, but for me it allows me to obtain a superior quality on someone props.
I did not post this technique so that everybody says " amen "  but because we asked me how I proceeded.


I regrettably have no your long experiment but I learning little by little


Orange

[Fabian93]

I know, I do have nothing to say, but can somebody compare the file size, please?
What will be the size of "HD"-props?
As long as I don't know this, I suppose they will be pretty big (in comparison with normal, classic props).
I can say for sure, that most of the old props won't get "revisited". A mix of HD props and classic props would look pretty unreal to me.
And if the file size is too big, some people's computers could not handle it anymore.
It's a great discovery yes, but we also have to think about the detriments.
(I hope, I was not totally off-topic.)

Fabian

[SimFox]

Orange:
please, don't get me wrong... I just want to understand what do you mean by superior quality. I mean in words... just saying that something is superiopr doesn't really make it so. I was looking at these:


... and to be just can't figure it out... May be I'm missing something

Using GMAX doesn't preclude you from getting Alpha... it is right there!! and always is:



My problem was because I couldn't read the texts and had only to guess what is going on... but then I had to use some logic as to the directions and steps... and that was eluding me...

Fabian:
depending on how it is implemented.
at worse it would increase the file size by about 4 times, but if done sensibly filesize would increase only about 2 times.

[buddybud]

Orange_o_ thanks for sharing. Please do keep up the encouraging experimentation, i am also going to try some things out. Please keep reporting back!! .

Fabian... in the latest road sign i tried to make the image size increased from 16x32 to 32x64. from 1562 to 1823 bits. All that extra black area accounts for little.


still looks crappy but thats like a 20 min attempt. (middle sign default size) also note i replaced only the one rotation. Again note i did this by not altering the original file but adding an overriding texture dat that is independent.

As for SimFox.....i would just say that with talent you can effectively blend anything with anything and make it look good. Also with ingenuity you can build larger buildings out of smaller parts. If this is all not easy enough for the masses, please don't think that some of will still not explore this and apply it however we can. You critique and we try, thats the only problem here
As for orange_0_'s reasons for increasing the size it's quite simple. First it gives you the exact positioning of the mat at an increased zoom. Now doing that just gives you a bigger file size and nothing in way of detail. You could work here but as orange_0_'s does it's even better to increase the size again. At this point you would edit and add detail. When reduced to wanted size afterwards it will blend and look much smoother and believable. It's a old photoshop trick for blending photos....

Bud.


Highly Pixelated Bud 

[SimFox]

Here I've tried to sum my thoughts about application of larger textures/FSHs to props:

Hi-Res Props
What works what doesn't...

I. What works.
1. Zoom6
this is a blowup of Zoom5. s3d models are scaled 2x (or any amount) and so are FSH textures. This is done in a crude method leaving us with badly pixilated result. Of course what should be mentioned here is that original Z5  is often not of stellar quality to begin with. Enlarging it only magnifies the problem. Leaving "workmanship" aside GMAX doesn't apply any AA during the export, unlike the preview which AA-sed. This has probably me done in order to ensure that rendered images are not Anti-Aliased against background in order to prevent black fringing. Whatever the reason may be result is bad distortion of small objects and texture elements.
New method is effectively switching Zoom 5 FSHs with Zoom6 ones. this eliminates need to scale up textures when  model is scaled 200%. But this wonder isn't applicable to all FSHs:
2. Small Stuff
Only small stuff, whatever it may be – props, flora, buildings - doesn't really matter, will benefit from this approach. The passing condition being that the larges FSH (one of any Zoom5 ones) doesn't exceed 128 pixels on any side.

II What doesn't
1.  Any other zoom than 6. In fact we'll get some deterioration for any "scaled down" zooms, albeit not as drustic as in case of scale up.
This is on its own a reason strong enough on it's own why any devised procedure should ONLY alter Zoom5 FSHs.
All zooms 1-5 show you exactly what is there to show. If you want to better them you should do it in BAT. Naturally I leave at this stage compression occurring during the conversion of BMPs to FSH out of this discussion. However it would be interesting to research if game could handle something better...
2.  Anything large enough to have any side of any FSHs at Zoom5 exceeding 128 pixels. Reason for this isn't really that some new FSH/Slab cutting may ensue – this process could be controlled and game fooled. Real problem is that in that case next step in size is 256 pixels. All textures in game are sized on the power of 2. 128 = 2^5, next would be 2^6 and that is 256. And Zoom6 is, incidentally, but unrelatedly, is 2x the Zoom5. So we would need 512 pix FSH. This as I've mentioned earlier roles out not only skyscrapers, but even some props like T-Ram shelters. I really hope that the way to get though this 512 barrier be found.

III How it could be done.
As I have stated already there are a lot of misguided opinions floating around. Most typical mistake is that we could take what ever we have in Zoom 5 FSH to Photshop and somehow enhance (read enlarge) it. This wouldn't really work, or let's say it is a least preferable way. You just can't enhance-in something that isn't there in the first place. Also you should remember that when you taking something from FSH you are working with data that has been through very rough and lossy compression.

On the other hand idea in 2W proposal (Wouanagaine and Warrior) is very solid. Despite different procedures the core – generation of new higher resolution image applied to the same sized 3d shell is a right one. When at zoom6 shell/LOD is scaled up 200% the texture is shown at 100% and then it's scaled down to 50 % for zoom5. This scale-down reduces quality somewhat. Magnitude, or noticeablity of this reduction depends on nature of texture and its original quality. Well, nothing in this world is free.
So, with this approach we get the core benefit – more data in the FSH. The exact procedure, though, should be considered.

Idea of rendering the whole thing at twice the size and then reducing value of all vertecies coordinates is apart from tediousity (that could, naturally be helped by programming the task) has other problem spots. First one be the method how that doubling of the render size is achieved.

One way would be to scale model 200%. This may appear easy and quick solution. But it isn't. Scaling should really be used only on sub-object level, and even then there are problems with some modifiers.

Another way is to model everything twice the size. Apart of oddity it, as a previous method as well, will double the size of all 5 renders not only zoom5. This will result at lowering quality of all 5 zooms and 4 times the file size.

Another drawback is that would model exceed 256 pix slab size it would be cut, and we don't want that. On the other hand we can't afford it (see the 512 pix problem) anyway, so such a render is faulty to begin with.

Better methods would be to work with purely rendering setting. This way we can target selective zoom/view renders and also automate the whole process.
I've already tested first altered script that takes us few steps in the right direction, and I believe special prop exported with failsafe check for 512 limit could be created.

All-ln-all this is a very exciting development!

Please feel free to add you comments and opinions and suggestions. And please speak your mind, no need for niceties, if you think that some or all that I suggest is a load of bullock just say it, but please provide some explanation.

[buddybud]

the only thing misguided is your attempt to direct things from the back seat....lets see what we can do before you dictate the rules shall we!.

Let me put it this way so i don't come across as to harsh. Sometimes a good technique is good in very few instances. That is it may be invalid, or crap, across the board but still work really, really well in one certain instance. That does not make it unworthy or wrong. Just limited.

For instance my highway walls have painted on shadows. The reason for this is because the game engine won't throw shadows on overhanging props, Both overhanging props and painted on shadows make them all but useless outside of my highway wall bat. But should i have ignored using these features. Get it. We may not be able to upgrade the whole game.....obviously...but we may be able to vastly improve many little bits. Remember there are already 256x256 textures in game that are in use already. It's a matter of taste, innovation, and the will to accomplish. oh and some possible heavy tweaking. But it doesn't mean it shouldn't be as thoroughly researched as possible.


Bud.

[SimFox]

As for orange_0_'s reasons for increasing the size it's quite simple. First it gives you the exact positioning of the mat at an increased zoom.

Sorry, I still don't get it... What "the exact positioning of the mat at an increased zoom" means?? why would you need that position?

Now doing that just gives you a bigger file size and nothing in way of detail.

I agree with that and actually see it as problem...

You could work here but as orange_0_'s does it's even better to increase the size again.

and why is that better? didn't you just said that all it does increase file size without any increase in detail?

At this point you would edit and add detail. When reduced to wanted size afterwards it will blend and look much smoother and believable. It's a old photoshop trick for blending photos....

how exactly you add that that detail? You have to remember that you are not working with photographs here, even then such a procedure is a bit dubious one something along the lines of "digital zoom" on pocket cameras.

important point that I 'm still not clear, does Orange reduces the size(dimensions) of the (I assume) original screen grab of the 500% scaled preview to 20% right after bringing it to Photoshop?

Buddybud:
I'm not directing from back or any other seat.
All I did is presented my views with explanations. I did it specifically that someone who disagree or knows something different or more could present information to all to see and take it farther. If you have something that you disagree, or feel I stated wrong just name it.

[Jonathan]

I don't really understand your post Simfox, it's confusing to me.

Problem with 512pix textures rules out the "hi-def" buildings at least those that are bigger than 1 128x128 slab at zoom5 and that means most buildings not only skyscrapers. So, unless this problem is solved this method would be limited to props only, small ones at that  even some t-ram/GLD stations would be too big.

I'm pretty sure it was discussed the limit was 256x256px, not 512. Over 256 and the people who use the game in software rendering have problems.
Also a simple way to do this would be to make the BAT slice up bigger buildings more and into smaller sections.

New method is effectively switching Zoom 5 FSHs with Zoom6 ones

You said just above this quote in your post, that the zoom 6 models/textures are just blow ups of Zoom 5 done by the game it self, there are no zoom 6 textures/models. So how can you switch the Zoom 5 with Zoom 6 (which don't exist)

And if we start making HD props after this discovery has been fully made, then eventually all the props will be HD, and by that time the technology would have advanced enough so the computers can handle a probably small increase in file size.

What my method is is,
Make a model,
Export
Make the model twice as big (200%)
Export
Apply the bigger textures to the smaller model (this can be done for all zooms)

Jonathan

[buddybud]

Simfox...

ok first understand that what Orange_o_ is doing is distinctly different process then what the others are doing. He is essentially making hand crafted highres fsh textures. Where as Cogeo and wou are using bat to produce their textures. In doing so Orange_o_ has to make sure his larger textures have the exact mat as the original but double the size. The way Orange_o_  enlarges the original gives him the mat. Now you would cut out the object and fill it in with your own or simply edit the existing picture to add details....it's called "PIXEL ART". Now why he would increase it beyond that is again something someone very familiar photoshop would know. That in order to get believable lines that fade and have highlights and look real you can't just draw them....however a trick is to do a good job at a higher resolution first......then Shrink the file down and let the computer blend things a bit....The resulting detail is something you couldn't have drawn yourself. It's a photoshop trick for producing realism.....trust me it works. There is nothing he is doing here also that will increase the filesize beyond what the others are doing with bat. Infact he has more control because he can manipulate the pallet.

etc.

[SimFox]

Not to be driving from back seat here are examples to illustrate my points. I chosen narrow subway entrance (as those used of RTMT stops) as I believe it is a prime candidate to benefit from such an update.

some basic info.
model is exactly same. Exports are different in the way they handle zoom5.  New one double the render size and create FSHs accordingly. At the moment this is half manual procedure. But there is no need to do anything to the model.


"hi_Def" subway entrance on the left

Zoom 5 South	Zoom 6 South

the small deterioration I've been mentioning could be seen on the farther top rail. It about 1/3 to 1/2 width as compared to the regular export.
Floating effect is more obvious in the "Hi_def" model. Not because it is bigger, just because all the lines are cleaner. I believe it comes from the routine similar to one used in Max that offsets shadow-map type shadows a bit in order to prevent possibility of the showing before model. I bet ther is a property in some exemplar that controls this number. It would be great to find it so this could be fine tuned.
Apart form that at zoom5 both models appear pretty much the same. At zoom 6 difference is obvious.

"hi_Def" subway entrance is a lower one.

Zoom 5 East	Zoom 6 East

these pictures don't really show the problem (although small one) that manifested itself on previous ones - thinking of the at the top ... rail. Small problem here is a higher contrast in the internal (to model) shadows. it is visible at both zoom5 and 6 on the "hi_def" model.

All-in-all, problems do seem insignificant and benefit is obvious.
PS
comparative file sizes:
18kb for standard model
29kb for "hi_def" one.
in this case it is well under 2x ration. Since the FSHs are small and they relative part of the overall File size is smaller too. With large FSH the difference will grow. But should never exceed 2x if only Zoom5 is affected.

[RippleJet]

2.  Anything large enough to have any side of any FSHs at Zoom5 exceeding 128 pixels. Reason for this isn't really that some new FSH/Slab cutting may ensue – this process could be controlled and game fooled. Real problem is that in that case next step in size is 256 pixels. All textures in game are sized on the power of 2. 128 = 2^5, next would be 2^6 and that is 256. And Zoom6 is, incidentally, but unrelatedly, is 2x the Zoom5. So we would need 512 pix FSH. This as I've mentioned earlier roles out not only skyscrapers, but even some props like T-Ram shelters. I really hope that the way to get though this 512 barrier be found.

Correct me if I'm wrong, but the maximum size of the FSH textures mapped onto S3D models is 256×256 for all zooms (1, 2, 3, 4 and 5). It is if the size of the texture to be mapped on the S3D model exceeds 256 pixels either direction (x or z), that it is cut into slabs sized no more than 256×256 pixels. This might happen already on zoom 1 for really tall skyscrapers, and certainly happens on zoom 2 for most skyscrapers.

Another drawback is that would model exceed 256 pix slab size it would be cut, and we don't want that.

Why not? This normally occurs on zoom 5 for anything larger than a tree or a garage.
I'm sure there are lots of props out there that already are big enough to be cut into more than one slab at zoom 5.

On the other hand we can't afford it (see the 512 pix problem) anyway, so such a render is faulty to begin with.

I wouldn't say a S3D model consisting of more than one FSH texture, sized 256×256 pixels, is faulty...

[SimFox]

I don't really understand your post Simfox, it's confusing to me.

I'm pretty sure it was discussed the limit was 256x256px, not 512. Over 256 and the people who use the game in software rendering have problems.
Also a simple way to do this would be to make the BAT slice up bigger buildings more and into smaller sections.

Well sorry if some of my wording was confusing, but I'll happy to clarify.
what I meant by 512pix limit is that such a texture/FSH couldn't be used, hence 256x256 is a maximum size possible.

As for suggestion to slice buildings more often, this wouldn't work overall. Even if game would accept unit smaller then 256 - the size of maximum slab this approach would reduce maximum size of building by 2. This is a same reason why you can't render huge building. It isn't memory issue as people think. It all linked to the maximum number of slabs allowed. Actually,originally this number was half of what it is today - 16 slabs (by the virtue of Hex numbering system) then a work-around had been introduced by a team responsible for then creation of the original content. What should probably be investigated is if it would be possible to make the same once more. I may be mistaken about actual numbers but the principle is solid. I have run into this when I was writing preview script and though of re-writing when whole export script for Bat4Max simplifying it. I'll be getting back to this task after the easter when my work load will get lighter and new version of Max will arrive.

You said just above this quote in your post, that the zoom 6 models/textures are just blow ups of Zoom 5 done by the game it self, there are no zoom 6 textures/models. So how can you switch the Zoom 5 with Zoom 6 (which don't exist)

I'm not quite sure what part you're referring to but I'll try just to explain as I see it, if something remain unclear feel free to ask.
So, I said taht Zoom6 doesn't exist. That's true Zooms are the fixed camera/texture resolution levels existing in game. There 5 of these. At the appropriate Zoom level you are presented with per pixel accurate rendition of FSHs -same as ones you see during export/preview. The relationships between different zoom levels isn't equal. Even Zoom 5 is almost 2x the zoom4, other than that they are same, but other zooms differ from each other by various magnification factor and also different point of view/position of the camera.
Zoom 6, or what we refer to as zoom6 is different as it has no special export is done for it. It appears to be simple 2x magnification of the zoom5. point of view remaining the same. So as you see itis there in game, but not there in BAT. Game is built out of LOD shells textured onto which FSHs ate mapped or projected along camera Z axis. When we move into zoom 6 all 3d geometry is getting losslessly (as it just numbers) bigger by a factor of 2.  This however alters the pixel (of FSH) to pixel on screen ratio (it is 1:1 at "native" zoom level). Now same amount of FSH pixels are stretched to comer more screen pixels. So they are simply doubled. Given that this isn't a pro graphics application and that it is 6+ years old this is done by rather crude method. But even the best methods can't create out of thin air missing pixels. At zoom6 only every 4th of the pixel you see is actually caring authentic and meaningful information. this is very much same issue as watching regular standard definition broadcast on HiDef TV. picture isn't better then on standard def TV, it is worse.

But back to the game. What we can do is to created double-sized texture for Zoom5 then (at zoom5 display we will see only quarter of the actual pixels in the FSH in question. this is a reason for some degradation, because this effective resize down is also done in not the most sophisticated way. Still this is far less noticeable problem then sizing up. What it means is that some small details may be resized out of display all together remember you are only seing 1/4 of all pixels that are there. However very similar procedure was sed to be real working alternative early days in 3D to get AA. People would simple render 2x sized images and then scale them back. Those days AA algorithms were so slow that this would offer time saving especially when rendering was done on expensive hired render farms and all the post processing could be handled by individual PC.

However when you switch to zoom 6 now you'll have same 1 pixel of FSH to 1 pixel of screen ration we have with all 1-5 zooms at the default. (except of the now sized down zoom5 of course.)

And if we start making HD props after this discovery has been fully made, then eventually all the props will be HD, and by that time the technology would have advanced enough so the computers can handle a probably small increase in file size.

I'll drink to that!

What my method is is,
Make a model,
Export
Make the model twice as big (200%)
Export
Apply the bigger textures to the smaller model (this can be done for all zooms)

Jonathan

well this method although technically correct, have problems I'm noted in my message earlier on this page. Scaling up has bad effect on some modifiers (say like extrude).
you do unnecessary rendering (for all zooms other then zoom5).
Applying bigger textures to all zoomes is totally counterproductive. As I've explained above you end up with larger than necessary file size, and , what is more important, only 1 pixel in 4 displayed in game for all zooms 1 to 5.

[Jonathan]

well this method although technically correct, have problems I'm noted in my message earlier on this page. Scaling up has bad effect on some modifiers (say like extrude).

I wouldn't know about how it effects certain parts of modeling like extruding, as I don't BAT. So I'll take your word for it

you do unnecessary rendering (for all zooms other then zoom5).

If it has to be under one slab of 128x128, then generally this will not take much time at all. (This is my instinct talking, not knowledge)

Applying bigger textures to all zoomes is totally counterproductive. As I've explained above you end up with larger than necessary file size, and , what is more important, only 1 pixel in 4 displayed in game for all zooms 1 to 5.

You don't have apply to all the zooms, but it's there if you need to for more than 5.

As for suggestion to slice buildings more often, this wouldn't work overall. Even if game would accept unit smaller then 256 - the size of maximum slab this approach would reduce maximum size of building by 2. This is a same reason why you can't render huge building. It isn't memory issue as people think. It all linked to the maximum number of slabs allowed. Actually,originally this number was half of what it is today - 16 slabs (by the virtue of Hex numbering system) then a work-around had been introduced by a team responsible for then creation of the original content. What should probably be investigated is if it would be possible to make the same once more. I may be mistaken about actual numbers but the principle is solid. I have run into this when I was writing preview script and though of re-writing when whole export script for Bat4Max simplifying it. I'll be getting back to this task after the easter when my work load will get lighter and new version of Max will arrive.

I'm pretty sure, but what you referring to as "slabs" are just 'groups'(as the reader calls them) in the S3D file, each with their own FSH.
In which case I have seen models with about 47 groups/slabs/different FSHes. So I don't think there is a limit (well a small one anyway)

One example I can think of off the top of my head is the Highway over Avenue Roundabout puzzle piece preview in the NAM.
There are 16 different groups for the actaul roundabout, and then I think 16 more for the highway?


And I know I understand what you mean in the middle part of your last post.

Jonathan

[buddybud]

anyways this is ugly but i managed to apply an alpha to a bat rather then a mat. I made a tiny railing to see if it would work. Seems fine. I wonder if this is less resource hungry then high detail lodding?

[SimFox]

Warrior, Ripple since you are raising similar questions I'll answer you jointly, If some details are missed let me know and I'll return to them.

Slabs.
What I and scripts call slabs are pieces of the 3d geometry (LODs) that are sliced at given intervals - representing 256 pixels of screen at given zoom level. I believe that this relationship (size to screen pixels) is a hardcoded into game's 3 d engine and can't be changed. But may be I'm wrong. I'm not all that familiar with game coding...
I guess this is done to fit to the 256pix textures that were a mainstream at the day (again I believe it is a hardcoded into game's 3d engine).

Link have to be maintained between these slabs and FSHs. This is done through TGI. I here is that linked particular FSH withing the given SC4Modle to it's Slab.
Let's take a look at Instance ID:
00030xyz
the "0" after3 is for day FSH, 8 is for Night one. that leaves us with last 3 digits.
x reserved for Zoom - where 0 is zoom1 and 4 is zoom5
y represent rotation where 0 is South, 1 is East, 2 is North and 3 is West.
and last one z was left to represent number of the FSH in given day/night, zoom level and view.
The whole Instance ID is a Hex number. That gives us 0 to F eg altogether 16 unique numbers.

Team developing The Game had run into this issue and devised workaround Y - rotation number has been allowed one more number - 4 to represent second tire of FSHs of given Zoom/View. This discussion could be seen in the notes inside of the scripts. so now we have maximum of 32 256 pixel slabs to cover the entire view of the model.
More then that, should this number be exceeded the message is suppose to pop up and tell user - "You model is too large", but this piece of code left unfinished. So all you get when you try to export something too large is Error code 6...

This workaround I believe requires some alteration of the game engine. I may be wrong , but (as in Monk) I don't think so...

Warrior, could you point me to this bat that had 47 groups? I would really love to examine it...

as for you example with NAM you are still within the 32 slabs.

anyways this is ugly but i managed to apply an alpha to a bat rather then a mat. I made a tiny railing to see if it would work. Seems fine. I wonder if this is less resource hungry then high detail lodding?

I'm not sure I follow you...
what do you mean apply ALPHA to BAT Could you may be post somewhere this SC4Modle file?

High poly LODs are definitely not good for game performance. No matter how faster todays cards are games ancient 3d engine wouldn't necessarily be able to take full or even significant advantage of their power.

[callagrafx]

well this method although technically correct, have problems I'm noted in my message earlier on this page. Scaling up has bad effect on some modifiers (say like extrude).
you do unnecessary rendering (for all zooms other then zoom5).

Not if you group everything and use an Xform modifier   

Instead of dissecting everything and telling them that they are wrong, why don't you just leave them to develop this in their own way?  Better still, come up with your own method of creating HD props and textures and demonstrate why yours is (bound to be) superior.

[buddybud]

I'm not sure I follow you...
what do you mean apply ALPHA to BAT Could you may be post somewhere this SC4Modle file?

High poly LODs are definitely not good for game performance. No matter how faster todays cards are games ancient 3d engine wouldn't necessarily be able to take full or even significant advantage of their power.

heres a zip of the desc, model and psd i created it from. Normal bats use mats, mine is truely transparent . you can see the other props through the bat even though the lods cover it. Check out the mats tab for the texture. I only changed fsh 7AB50E44,B970086C,00030430   , just the one rotation and zoom. 

Edit...In order to get the same results you usually need to make lods that conform to the model exactly. This lod is one big square but allows transparency!!!

[RippleJet]

Warrior, could you point me to this bat that had 47 groups? I would really love to examine it...

I don't think there are any models having more than 32 slabs/groups in one view.
I concur with your explanation of the maximum number of FSH files per view.
The biggest number seen in the game is the south and north rendering of the Empire State Building, which at zoom 5 has 29 slabs (materials/FSH textures).

That still wouldn't restrict people from rendering HD props where zoom 5/6 has more than one slab/group though.

[cogeo]

I don't see why the scaling must only be 2?
I tired it with 4 in the reader and it worked, but I didn't try this in game.

Actually scaling the model by a factor that's a power of 2 should work, as long as BAT will export the same number of FSH textures (they should all be equally scaled). The "problem" with 4 is that splitting the textures is more likely. Scaling by any other factor (non power of 2) shouldn't work, as UVW maps would be affected too (according to my guess, of course  ).

Leaving "workmanship" aside GMAX doesn't apply any AA during the export, unlike the preview which AA-sed. This has probably me done in order to ensure that rendered images are not Anti-Aliased against background in order to prevent black fringing. Whatever the reason may be result is bad distortion of small objects and texture elements.

Looks like gmax does some sort of antialiasing. The problem lies in the alphas exported: all pixels at the edge of the model become 100% opaque. The game then attempts some AA at runtime, which interferes with the black backgorund, and that's why you get those ugly dark pixels at the model's edges.

Things in 3dsmax are different, it allows to set AA on, and this generates an alpha with grayshades too (not just black and white), that is the alpha is AA-ed too! This is how AA is usually implemented. Still, this doesn't work ingame, unless the blending parameters are set (in the same way as for the semitransparent models). This method was proposed by Autovino on ST. I would also lik to add my own recommendation, which is change the background colour to that of the material's, eg for the model above it should be steel blue. If the objects at the model's edges are textured with different materials, the background can be set to a colour that matches most of them, or to gray (128,128,128) - this is much more "neutral" than the default black. Check the models in my "Spirulina Farms" lots (the tubs) to see what I mean.

There is a trick to force gmax generate an alpha, you just need to have an object with a material of less than 100% opacity. If you don't have such a material in your model you can add a (dummy) object with an opacity of 1% (this doesn't affect the BAT at all). The alpha generated won't be AA-ed though. It would also be nice if the background could be adjusted. This is not possible in gmax itself, but by tweaking something in the .INI files or the scripts maybe?

The utility I was talking about is now in the making. I can read datfiles now, and identify all S3D models (it worked even with simcity_1.dat), but I'm not sure if I can successfully tweak them. If this finally works, it will contain basically two functions, scaling model(s) and setting/removing transparency (a tedious procedure too).

[Jonathan]

SimFox,
The NAM doesn't use the same IID scheme as the BATs, so it is not a limit of the IID scheme in the NAM that prevents us from having more than 16 or 32 slabs.

I can't remember which model was 47 (it might have been on one of the occassions when I mucked up importing another S3D file into one.)
But There is one with 36, which would be over the 32 limit:
In NetworkAddonMod_Roundabouts_Avenues_Plugin.dat
the model with IID: 0x584ADFF0

Also then saved the S3D, raised it be 20 higher, and imported the model again (so there was the model on top of the other model) making 72 slabs, and there was no problem in game. But that might be because it is a preview of a transit item, not a BAT.

BuddyBud, what version of the reader is that, it looks different to mine?

Jonathan