Model/BAT render issue? (aka what's wrong with this model)

[Tyberius06 12,189]

Hi everybody!

I need a BAT expert who can tell me what's going on with this model and if there is a way to fix it. I have a WMP station platform model, which was rendered/exported off-set. In PIM-X on every zoom level it shows up properly. In reader the s3d and fsh properties show up properly (at least as far as I can tell, so there might be some missing FSH-s in the original model or anything I don't know). In Maxis LE on zoom level 1-2 (the two farest zoom levels) the model shows up:

But on level 3-4 it disappears:

And then on zoom level 5-6 (closest zoom levels), half of the model is not there just the shadows.

Now in PIM-X it shows up properly on every zoom level:

In game, on level 2 it seems to show up properly, but on 3-4 it completely disappears only the shadows show up, and on level 5-6 I get this as a result:

So could anybody tell me, what is this? As far as I know, there is no officially released lot with this model/prop, so if it's not something what can be fixed, then I just simply exclude this model from the upcoming WMP mega prop pack.

Thanks in advance!

- Tyberius

[rsc204 21,808]

Can you send me a copy of the model or a link to it?

[Tyberius06 12,189]

3 minutes ago, rsc204 said:

Can you send me a copy of the model or a link to it?

It's in the wmp_ad_station_bldgs.dat. It has 3 platform models which were never used on WMP lots for sure. The model name is: wmp_platform2_48m. 

Thanks

[rsc204 21,808]

1 hour ago, Tyberius06 said:

It's in the wmp_ad_station_bldgs.dat. It has 3 platform models which were never used on WMP lots for sure. The model name is: wmp_platform2_48m. 

Well the first odd thing is that the model appears to be a True 3D model, not a regular BAT, but more akin to automata. I'm not sure why you'd make a model this way and then use it as an RKT1 prop. Perhaps it will work as an RKT0 prop which may or may not be better, I'd have to test it. Otherwise, aside from being offset, I can see nothing wrong anywhere.

Having separated this model and centred it, I am seeing the same issues in-game and what is happening is that only one part of the model is actually being displayed. Look at the #####4#X model/textures. The S3D has two groupings, one to display texture 400 and another to display texture 401, but only the latter is appearing in-game. The 400 group takes care of zooms 5&6. In both zoom 4 (300) and zoom 3 (200), no model displays at all, just it's shadow. But, in zoom 2 (100) and zoom 1 (000), the model displays fine in all rotations.

I think what is happening here is not so much that it's a True 3D model causing the problems, but the number of verts/polys in use exceeds the meagre 500 limit SC4 allows. This would explain why zooms 1 & 2 are fine, since they use as is typical for all SC4 models, very simple LODs. Zoom 3 & 4's LODs are the complex True 3D kind and exceed the allowed limit. Zoom 5's 1st grouping exceeds the limit, but it's 2nd grouping, because it's much smaller does not. Ergo, we see only group 2 here.

We can't really rectify these problems in Reader, I think ideally it should be re-rendered for the affected zooms in SC4 BAT. The good news, since we have contained inside the DAT both the model and texture/UV mapping, it can actually be done. But mapping the textures back to the model is not something I could do personally. After that, any nightlights would likely need to be re-made too, since those textures can't just be reused. Long and short, until someone can fix this, it's probably not much use as a prop.

What's odd is how all the models in that DAT use the same True 3D model setup. It just seems that the others are not so complex (geometry) as to run into the limit. Again complex but in theory if we re-grouped the model so that no single grouping contained more than 500 polys, that would work fine too.

[debussyman 1,348]

This is an interesting case because lately I've been having a similar with my test renders of several pieces of the Louvre (It is divided into props), in the LE looks fine, but in game and in certain zoom levels it is only a shadow with some of the FSH textures appearing here and there.

I don't know what could be causing it, as this is the first time it has happened to me. The LODS are not particularly complex, just an L or T shaped box usually, and it is corrected if I remake the LODS and re-export it, even if the LODs are exactly the same shape. Hoewever, they are also offset props, so there might be the issue.

I haven't tried to see if it only happens when used as a prop and it is an issue of the game itself, or maybe it was an error when exporting the LODS in gmax. Rigth now I can't check because I've already deleted the faulty files, but If it happens again I'll take a deeper look.

Edit: Oh, and one more thing I noticed is that I can "predict" if it will behave like this from the LOT editor, as the it appears to be divided by a row of transparent pixeles for each texture section on the model.

[debussyman 1,348]

Found one of them.

I'm not sure if it is the exact same problem, but I've attached the model file if anyone wants to take a look. Now is set as the main building, not a prop, on this lot, and the problem still happens.

NE_ESpejado-0x5ad0e817_0xcbc747e9_0x30000.SC4Model

[Tyberius06 12,189]

38 minutes ago, rsc204 said:

What's odd is how all the models in that DAT use the same True 3D model setup. It just seems that the others are not so complex (geometry) as to run into the limit. Again complex but in theory if we re-grouped the model so that no single grouping contained more than 500 polys, that would work fine too.

Thanks Robin!
It's interesting, because this platform is working somehow as one part of a modular platform. The second half (the another 48m long platform) shows up properly and also the full 2-in-1 96m long platform model too. 

I sent a message to David (d_j_p1), he mentioned that he might have some back-ups from Doc with gmax files, I don't know if those gmax files are the ones which were released or these or unreleased stuffs. If we have a little luck, then he still have the gmax file for this model. 
For now, I just leave this model and prop out and if someone will fix it, then I'll update the prop pack later. This model has been broken since its release, so I don't see a real chance that anybody used this on lots. 

[rsc204 21,808]

5 minutes ago, Tyberius06 said:

I sent a message to David (d_j_p1), he mentioned that he might have some back-ups from Doc with gmax files, I don't know if those gmax files are the ones which were released or these or unreleased stuffs. If we have a little luck, then he still have the gmax file for this model. 

A proper gmax model with the correct setup would make fixing this a cynch. But since it's a proper 3D model, we can export it from Reader as 3DS and import it directly into SC4BAT. At which point you need to match the UV mapping (from Reader) to the model in SC4BAT (the bit I can't do), and apply the BAT texture. Normally this isn't possible, since the LODs don't contain the data we need and the textures aren't in a suitable format to do it.

13 minutes ago, debussyman said:

I'm not sure if it is the exact same problem, but I've attached the model file if anyone wants to take a look. Now is set as the main building, not a prop, on this lot, and the problem still happens.

I'll take a look for you, but it looks at first glance like a different problem with similar symptoms. SC4BAT simply doesn't export 3D models unless you've messed with the scripts, so I'm sure you're LODs will be basic planes, which is more normal. However the fact that adjusting the LODs can resolve the issue, suggest's it's a LOD issue. Usually extending the boundaries by .1 or .2 of the LOD in all directions fixes a lot of such problems.

[rsc204 21,808]

@debussyman: Certainly in some views, the UVMapping is not correct and that seems to be messing with the model's display. Due to the unique shape of your model, I think you'd have more luck if you rendered it properly centred. SC4BAT looks at the most efficient way to fit the rendered texture into as few textures as possible. When the LODs are pretty tight, sometimes the calculations just seem to get messed with.

Here for the z4 models, when you look in the UV map, select each texture one at a time, the problem becomes clear. As per the Yellow arrow, sections of the texture are simply not being applied to the UV Map. You'll see similar issues in the other S3Ds.

Sometimes this sort of problem can be easily fixed by adjusting the UV values under the Vert tab manually. But I think in this case, it's better to re-render things, since it doesn't look like the usual halving or doubling of a group of values. This seems consistent with LOD extremities that SC4BAT just doesn't like for whatever reason.

[debussyman 1,348]

@rsc204 Thanks for taking a look. Yes, it seems to be a problem with the off centering, as it has never ever happened to me before. About the arrow you point at, that is on purpose, the LOD does not reach that far, but the Max model does, in order to fit it seamlessly with the other side of the building which will be a different prop. Maybe that also could be prompting the problem.