jimmy2040's BAT thread

[OffshoreTacos 5]

You're right on both counts, Todd. It looks way too shiny in that render, but it's so small in-game that you can't tell.

I'm currently working on modding the building so that it creates very high, steady demand for R$. The idea is to have a landmark that will help me quickly build up R$ hi-rise complexes. I'll release it in that form, as well as a CS$. The building is 14m x 14m, so I'm going to try to figure out how to add it to the CS$ 14x14 cohort.

I'm having one problem. In-game, the model has unsightly seams at certain zooms and rotations. I know this is a common problem, but I haven't heard of how to fix it. Any thoughts?

[SimHoTToDDy 2,938]

Could you show some pics? That might help those who know. These models can do any number of bizarre things, so its hard to pin them down with out some more information.

Best of luck, and hope its no major issue,

-Todd

[Odainsaker 2,134]

If I am thinking of the same unsightly seams that are bedeviling you, then unfortunately, there may be no real fix for them. It is almost like an aliasing effect, except it is being created where different mapped image pieces meet at the seams between face segments of ingame geometry. Occasionally, as a result of the way the game's graphics engine manages and puts together all the disparate pieces onscreen, the results do not always nicely coincide at the seams, creating disjoints and slip fault effects. It is a built-in game effect, affecting every BAT, including Maxis's own original buildings. I don't think there is a convenient or reasonably intelligible editing trick that can be done to the FSH files that might avoid all this, as you can try jostling images going into the FSH files to fix one seam only to exaggerate another seam somewhere else, and none of it can be seen for testing until actually assembed by the engine ingame.

This graphics bug can be minimized. The effect is related to a BAT's position when rendered onscreen ingame, so adjusting which tiles or which rotation a BATted LOT is placed on ingame will increase or decrease the effect, as will minute adjustments of the BAT position on its own LOT inside the Lot Editor. Adjusting a BAT to minimize the seams in one rotation or zoom will have carry over effects on other rotations or zooms, increasing or decreasing their bad seams. It will be a balancing act finding the right compromise between all of them. Sometimes, complex LOD geometry will create greater numbers of ingame geometry segments or more unusual shapes for them, so simpler LODs may sometimes minimize their occurence. Finally, bigger BATs will require more pieces used by the game engine to reconstruct the BAT ingame, with a corresponding increase in seams.

BATs which have strong visual patterns and predictable textures in their design will inevitably make the bad seams more pronounced. For example, a facade with a rigid pattern of thin vertical columns will likely acquire a noticeable slip fault seam slashing across some of them ingame. Or what is intended to be a perfect sphere or some other tight classic geometry will, if large enough, seem to have a chunk visually shifted ingame. On the other hand, BATs with mottled patterns and messy textures, richly sculptured or amorphous geometry, or an already segmented or deconstructivist style that avoids long extents of stark lines, tend to hide seams. Hence, I have noticed BATs based on clean modernist building styles often get the worst bad seam effects, while those based on older building styles with deep sculptural detailing tend to hide them.

Fortunately, with every building having always shown seams to various extents, the fan community has apparently long ago learned to read past them.

[OffshoreTacos 5]

Thank you, Odainsaker. From the sound of it, I will, more likely than not, have to live with the seams. That's fine by me.

I have a new and rather weird problem. I've had great luck with Bat4Max 2.5 so far. I'd even done a successful export of Wallace Distribution. But now, when I do my DAT FSH Insert and look at the file in the Reader, all the S3D files show the LODs as pure white boxes. The FSH files appear fine in the reader; it's just the S3Ds that are wrong.

Has anyone seen this before?

[SimFox 802]

I would like, if I may to clarify some tech details.

LODs

LOD5,4,3 are freely adjustable. Higher polygon count does introduce additional burden for the computer. How does that burden affect gameplay, though, is an open question. There are to many variables at play here. For instance how well could graphics board(VGA card) deal with this geometry. How compatible is a language which game is written with modern APIs etc. At zoom 1 and 2 Lods revert to the simple scene bounding box.

Volum,e of the LOD isn't directly responsible for the "exportability of the model into the game and memory issues have absolutely nothing to do with it. The limiting factor is number of unique HEX names/numbers that could be generated for the slices. At zoom5 the slice is 256x256 pixel. Plus export script rather intelligently casts off "empty" slices. Developers clearly understood that one tire naming system wouldn't quite do it as it allows only 16 slices. so 2 tire naming system was used, as a result we are limited with 32 slices to cover entire model. If that number is exceeded the export of model or LOD will fail. As you see it has nothing to do with computer power or memory etc.

Using self illumination materials to light up scene.

This could be done with any raytracer and self illuminating material. More efficiently if the material is HDRI eg contains more brightness levels that normal screen graphics 256 levels. So mental ray (with GF, naturally) V-ray or any other would work just fine. This type of illumination has little to do with accuracy but gives nice visual effect. I have been using it from day one. both with V-ray and MR.

Reflection of the neons... i thing it is fine!

Custom Night Rig.

This is a field that is desperate for some standardization. And I have been doing some preliminary work with it, but is is still in early stages. Actually same could and should be said about day custom rig as well.

Jimmy2040: I think you're missing the entire point of truNite. It has nothing to do with what light sources you use for your "nightLites" but has all to do with the absence of strong shadows. So your night views can NOT be called truNite. they are just a modified versions of default night views. If you use the truNite export that it is sort of hybrid. As a truNite it uses the total masks, but to a point pointlessly since the effect is same as with regular settings. One advantage would still be presence of specific night time reflections, though...