• Welcome to SC4 Devotion Forum Archives.
 

News:

The SC4 Devotion Forums are no longer active, but remain online in an archived, read-only "museum" state.  It is not possible for regular members to post or use the private messaging system, and no technical support will be provided for any issues pertaining to the forums in their current state.  Attachments (those that still work) are accessible without login.

The LEX has been replaced with SC4Evermore (SC4E), and SC4E maintains an active Discord server.  For traditional forums, we recommend Simtropolis.

Main Menu

scale a rendered B.A.T.s size

Started by justinrpg, February 22, 2011, 08:35:13 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

justinrpg

i have been using B.A.T. for quite awhile now... and i've gotten to know that if a model is too big, it will render the first view then hang for about 10 minutes then error out... i have had this happen enough times that when creating my model i know the largest size B.A.T will render without erroring out... but i recently downloaded a building from simtropolis that is WAY bigger than anything B.A.T. has EVER allowed me to create successfully, i was wondering how in the world did the creator successfully B.A.T.ed a building of that size, and what he/she did to get it that big, or render it that big without erroring out... does anybody know what his/her trick was?

Lowkee33

I would imagine the power of your computer is a limit in a way.

I do believe that there is a limit within BAT as well.  People get passed this by breaking their model into smaller pieces, and then rendering each piece.  The pieces are then carefully put back together in LE. 

SimFox

Maximum size of single piece BAT is limited by the number of FSHs tiles that game could use for it. And this number is 32, because there are 2 HEX digits withing Instance ID that are reserved to index these FSHs.

In case of large models, particularly when you have sort of conical like tall tower with a low wide base, or otherwise complex shape, you should aim to "conserve" FSHs by making custom LODs that doesn't leave much empty space around actual model, since FSHs technically are textures for LODs, which, in turn, are 3d objects used in game.

During export process scripts slice LODs as well as rendered image in slabs/slices equivalent of 256x256 screen space at zoom5. Then each slice (of rendered image ) is chanced if it occupies same space as any of slabs (piece if LOD). If it does a number is assigned to it and tally of your 32 numbers gets smaller by one. If, on the other hand it doesn't, this particular slice/FSH is simply discarded and the number is saved.

I know this may be a bit difficult to visualize for those not familiar with structure of SC4Model file, so I've made this little illustration based on my SEV building, as it has quite appropriate shape. So let's first take a look at what will happen when export will try to process automatic LODs (which is basically a bounding box) for this model:



and here is what could be done with custom LOD:



So you see custom LODs not only make it easier to pick the building in game (as when you select there is actual LOD) but also save you 6 FSH tiles. Actaully mode adjusted lods would make possible to save 3 additional tiles, but I guess by now you get my point!


RippleJet

#3
Thanks SimFox, those pictures are worth more than a thousand words! :thumbsup:


Quote from: SimFox on February 22, 2011, 12:26:16 PM
And this number is 32, because there are 2 HEX digits withing Instance ID that are reserved to index these FSHs.

Would you allow me to elaborate on these two HEX digits a bit further? :)
It's the question of the last two HEX digits (the least significant ones).
Those two digits can actually have 16² = 256 different values. But...

The last digit can be used in its entirity to index FSH files (0...F).
The second from last digit, however, also includes two other bits of information;
viewing direction (S,W,N,E) and the distinction between day and night time (overlay) textures.

In order to explain it easier, let's list all these 256 indeces and FSH files,
split up into 8 groups (8×32=256):

These 32 indeces are available for the Day Time South View:
0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07,
0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F,
0x40, 0x41, 0x42, 0x43, 0x44, 0x45, 0x46, 0x47,
0x48, 0x49, 0x4A, 0x4B, 0x4C, 0x4D, 0x4E, 0x4F

These 32 indeces are available for the Day Time West View:
0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17,
0x18, 0x19, 0x1A, 0x1B, 0x1C, 0x1D, 0x1E, 0x1F,
0x50, 0x51, 0x52, 0x53, 0x54, 0x55, 0x56, 0x57,
0x58, 0x59, 0x5A, 0x5B, 0x5C, 0x5D, 0x5E, 0x5F

These 32 indeces are available for the Day Time North View:
0x20, 0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27,
0x28, 0x29, 0x2A, 0x2B, 0x2C, 0x2D, 0x2E, 0x2F,
0x60, 0x61, 0x62, 0x63, 0x64, 0x65, 0x66, 0x67,
0x68, 0x69, 0x6A, 0x6B, 0x6C, 0x6D, 0x6E, 0x6F

These 32 indeces are available for the Day Time East View:
0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37,
0x38, 0x39, 0x3A, 0x3B, 0x3C, 0x3D, 0x3E, 0x3F,
0x70, 0x71, 0x72, 0x73, 0x74, 0x75, 0x76, 0x77,
0x78, 0x79, 0x7A, 0x7B, 0x7C, 0x7D, 0x7E, 0x7F

These 32 indeces are available for the Night Time South View:
0x80, 0x81, 0x82, 0x83, 0x84, 0x85, 0x86, 0x87,
0x88, 0x89, 0x8A, 0x8B, 0x8C, 0x8D, 0x8E, 0x8F,
0xC0, 0xC1, 0xC2, 0xC3, 0xC4, 0xC5, 0xC6, 0xC7,
0xC8, 0xC9, 0xCA, 0xCB, 0xCC, 0xCD, 0xCE, 0xCF

These 32 indeces are available for the Night Time West View:
0x90, 0x91, 0x92, 0x93, 0x94, 0x95, 0x96, 0x97,
0x98, 0x99, 0x9A, 0x9B, 0x9C, 0x9D, 0x9E, 0x9F,
0xD0, 0xD1, 0xD2, 0xD3, 0xD4, 0xD5, 0xD6, 0xD7,
0xD8, 0xD9, 0xDA, 0xDB, 0xDC, 0xDD, 0xDE, 0xDF

These 32 indeces are available for the Night Time North View:
0xA0, 0xA1, 0xA2, 0xA3, 0xA4, 0xA5, 0xA6, 0xA7,
0xA8, 0xA9, 0xAA, 0xAB, 0xAC, 0xAD, 0xAE, 0xAF,
0xE0, 0xE1, 0xE2, 0xE3, 0xE4, 0xE5, 0xE6, 0xE7,
0xE8, 0xE9, 0xEA, 0xEB, 0xEC, 0xED, 0xEE, 0xEF

These 32 indeces are available for the Night Time East View:
0xB0, 0xB1, 0xB2, 0xB3, 0xB4, 0xB5, 0xB6, 0xB7,
0xB8, 0xB9, 0xBA, 0xBB, 0xBC, 0xBD, 0xBE, 0xBF,
0xF0, 0xF1, 0xF2, 0xF3, 0xF4, 0xF5, 0xF6, 0xF7,
0xF8, 0xF9, 0xFA, 0xFB, 0xFC, 0xFD, 0xFE, 0xFF

cogeo

Apart from the points SimFox raised, your system may be running out of resources. This could be due to a number of causes:
- Does your system have enough memory? I'm not referring so much to physical memory, but mostly to virtual memory, as this is the memory the OS "sees" (then having more physical memory is advantageous, as this results in better performance, due to fewer memory pages swaps). So check the settings of your virtual memory, and if necessary increase the initial and max amount. Better defrag the disk where the pagefile is stored, before doing so. I use to put this file on a specially reserved disk volume, which is used exclusively for hosting the pagefile (and of course is 100% unfragmented). However, if you are not installing the OS yourself, you may not be able to do this, or it may be a little dangerous (eg requires re-partitioning the disk, which results in all data getting lost), so I do not recommend this to everyone.
- Are you exporting in high-resolution (HD)? Please do not do this for large models, as it is extremely resources-consuming, both during exporting and ingame. Use it only for small props, or for special cases, where showing-off detail is paramount. HD causes textures to become 4 times bigger.
- Complexity of your objects may be a reason too. For example, do not use 36 faces for a small cylinder, if 18 would work satisfactorily. There's also another trick I use when I want to export a large BAT. After you're finished with BATting, just before exporting, select everything and convert them to Editable Poly. This reduces the number of faces a lot (nearly by half), and results in a considerably shorter export time, without any loss in quality (and of course DO NOT save your BAT after converting to polys or exporting, it should have been saved BEFORE!!!).
- Use of many nightlights may cause problems too, due to excessive calculations. Better use the Attenuation parameters to confine the light effects to limited areas if possible (there's no light beyond the Far Attenuation limit).
- The resolution of your textures may play a role too. Many BATters think that using high-resolution textures is advantageous, however this is not true. Actually BAT works fine with textures of about 6-12 pixels per (BAT object) meter (eg for a wall 10x10 meters large, you should use a texture 60x60 to 120x120 pixels large). Using textures of higher resolution causes a sort of "blurring" and/or "bleeding" of colours. From 15 pixels per meter and above, some "softening" is already observed, and for textures of more than 20 pixels per meter, a considerable loss of detail can occur, eg details of stucco, scratches etc may be completely lost, or replaced by a fuzzy "blob". And of course this overloads the graphics engine (I'm talking about exporting only) and increases export times. So I would recommend textures of lower resolution. I really like the textures at cgtextures.com, but they are actually too large for BATting; the textures of their thumbnails, are definitely more than enough for most BATs!!!