TresCom Forums

I have a question. While this doesn't effect a level in any way, for some reason very often GUIApp gives the info "Terrain object with bad CLUT!" about most terrain objects that gets imported to a level, even if it is a terrain object from a retail level. It appears to happen mainly to objects that are either "too large" or "too complex". The last one it having to much verts, which I guess is because some terrain objects have been made directly from the terrain and are not flat.

What exactly does "Terrain object with bad CLUT!" mean?

CLUT = "Color Look-Up Table". The palette, in other words.

Oh. Well at the moment I have only imported the terrain objects and not applied the same palette, so that makes sense. Great to know. Thanks

Huh. Are we sure it's the palette? There's always that odd unmanaged detail about object colors for stuff like CBackdrop, where the ingame color appearance is some sort of internal variable not carried through TPM export/import.

Fun fact: GUIApp CE can load levels that have an object with over 50k verts, while it crashes when loading ingame.

EDIT: I have also noticed that CE is not a big fan of TresEd .scn files, or rather those saved with "Generate SCN Partitions" as it tends to crash on loading with levels saved with that enabled.

Okay. So it appears Trespasser have an issue with loading objects with a high vert count ONLY if they are visible. For the Island mod that TI and me are working on I use the terrain as a mesh as it is much easier to work with when placing objects as TresEd don't render terrains properly, and the more detail, it renders it even worse. Going in and out of Terrain Edit mode is just too annoying.
So what I do is that I have the terrain as a trigger, as there is no other trigger or only a few in the level at the moment, and then switch so Triggers are not transparent.

So I just loaded up the level in CE, and when the terrain is a trigger (not visible), it loads it fine. Keep in mind that the terrain trigger is somewhere around 100,000 verts. However, making it a mesh that is visible, it crashes during loading. I would guess this is because Trespasser only care about the triggers boundary and not the specific trigger mesh, and never actually load the mesh itself.

I guess this info is of no use overall, but could be useful for people who wanna make it easier in the level editor to keep track of triggers, allowing to have them being different shapes and quality to easily spot which trigger is a voiceover etc.

I am gonna do a double post. And I hope Lee can take a look at this or know why if he gets time to answer.

I've encounter one "major" issue when working with this mod. It appears that when a .PID file gets above 1MB, the game have issues with generating MipMap's and will crash when loading. I don't know if it is related to the .PID having a limit in size or information stored in the .PID. I am pretty sure it is not a .SWP issue cause I've manage to load it with a .SWP bigger than the one now but with a smaller .PID size.
The only way for a level to load is to disable "MipMapMode=" and "AutoMipMap=" all together and increase "SysMemSizeD3D=" to a number to allow it to load the textures. However, I guess this will disable MipMaps all together and I have not done any testing how this effect performance.

Thought I would write it here as I don't know if there is a way to fix it, maybe there isn't enough memory to create all the MipMaps or whatever. In any case if anyone working on bigger projects get this issue, this is a quick fix at least.

Huh what causes a PID file to be larger or smaller for a given level?

Draconisaurus wrote:Huh what causes a PID file to be larger or smaller for a given level?

Presumably the number of palettes...it is the "Palette ID" file, after all.

Okay, so now I've run into another weird qurik with CE. Yesterday I imported a higher-poly model into the game, and naturally it crashed due to it being a higher triangle count than 3072. However, a while ago I'd imported a second model with more than 4000 tris, yet the game doesn't crash when that model is in the level, and I've been testing the level frequently with that mesh in it without a hitch. (You can also see that I have several other models with more than the usual 2048 tri limit, but they all work fine)

GeomAdd's log: Sooo what the heck is this all about..? I don't understand why a model with 4000+ triangles works fine, when a model with almost a thousand less doesn't. The SRaptorCrate00 model isn't broken or anything, it imported into the level fine.

*er-hem* *puts on Drac jacket* I think you seriously underestimate the complex error possibility web in Tres crashes. Tons of variables at work... for whatever reason I happen to be thinking of a mass of curved faces in close proximity causing unusual located stress on a polygon calculation.

Draconisaurus wrote:*er-hem* *puts on Drac jacket* I think you seriously underestimate the complex error possibility web in Tres crashes. Tons of variables at work...

Hmm, maybe. Though I have consistently been able to get models working so long as they are less than 3072 tris. I honestly didn't expect those two super-high-poly meshes to work at all. In any case, I'll just break down the RaptorCrate model into a second mesh, which seems to be a good way to counteract the actual poly limit for now since the game doesn't appear to have much trouble with lots of polys in one spot, so long as they are different meshes.

for whatever reason I happen to be thinking of a mass of curved faces in close proximity causing unusual located stress on a polygon calculation.

I somehow doubt that's it, my mesh doesn't really have anything like that since it's mostly just a series of box-shapes:

(Click on thumbnail for full size)

The much higher-poly mesh has a lot more of that sort of thing than this does, really, since it's got a lot of 3D wires.

Is it possible the number of faces plays a part and not only the number of verts?

tatu wrote:Is it possible the number of faces plays a part and not only the number of verts?

I think the faces are already what you are limited by, the verts might be the problem though...very strange. I'm wondering what would happen if I were to remake the mesh identically from scratch (which I don't have time for unfortunately), whether or not it would work then.

EDIT: Okay, I did a bit more testing. I lowered the face count to 3068 (the lowest I could make it without ruining the model), which should be below the limit. However, instead of the level just straight-up crashing when I import the model, I now get a "Runtime Error". Never seen this happen before with Tres. Deleting the model allows the level to load up again without a hitch. I tried importing the model into a different level, and somehow it works fine in that level. However, the second level is only a small test level with few objects, where the other is RTJP~Helipad with 20000+ objects. I'm wondering if there is some kind of load limit or something for high-poly objects per level? Will have to test this further - I'm probably just going to import a 3000-face sphere and see what happens...should help me find out whether or not it's the model itself or some kind of limit I've encountered.

Huh well TI, your mod is doing things which no other Tres-modder has ever done before. Be careful that hidden engine limitations do not creep out of the woodwork to ruin it before we've even seen the park yet -

Draconisaurus wrote:Huh well TI, your mod is doing things which no other Tres-modder has ever done before. Be careful that hidden engine limitations do not creep out of the woodwork to ruin it before we've even seen the park yet -

Life will find a way! I'll have to figure this out since if there is some kind of high-poly mesh limit, I'll have to remake a couple of models, and it'll be a challenge to make good-looking character models as well.