Track editing progress notes

[Pavel 69]

And such a huge progress since then

[checkpoint10]

Here is my new web site where I'm keeping all my ICR2 stuff: https://skchow.com/indy/

It contains a section about track editing, where I discuss the process ("Track editing overview") and link to some tools. I will plan to add more information in the future, for example, detail about the file formats.

[samsepi0l]

That is pretty easy. At first you have to add at least one tsd line to let OPE create TSD section in 3d file. TSD section starts with string: % SURF_ED: Total lines right after TSO section. At first part all lines are defined (DetailP, DetailN). After all lines are set starts long DetailList section. Like ObjectList section for TSO it determine at wich track subsection each TSD will be visible. So in that list you need just add TSO to make it visible with all TSD details on the surface.

You have to add TSO only to DetailList H and don't change DetailList M and L. Also if there are several objects in DetailList then it behaves lik TSO list: last in the list - closest object, it will draw infront of other objects in the list.

EDIT And don't forget to remove TSO from ObjectList if you insert it into DetailList.

Pavel - you are awesome!!! Thank you for your help. This was actually easy... check it out! My brake markers are in the right place with respect to the fence polygons!

   

[checkpoint10]

I'm going to revive this thread to document my rebuild of Detroit for Rendition.

If my theory is correct, all I need to do is reduce the number of .mip files to around 40, and the track should be loadable. I'm taking a page (pun intended) out of the Nascar games and combining as many textures into one mip as possible. For example this is my PAGE01.MIP:


Some other notes from today:
- I don't remember if I posted this before, but when we load a textured TSD into OPE, it's going to write MIP="<filename.mip>" along with the file extension, when it really should be MIP="<filename>". Papyrus's 3D23DO apparently has no trouble with this, but Noorok's converter quits with an error. So, the fix is to find/replace all instances of <filename.mip> to <filename>.

- On my original version of Detroit, I had some wall textures as long as 1024x16. I was thinking about making a 64x16 texture repeat itself by coding into the MRK file with dimensions 1024x16. This seems to work in the Rendition game (i.e. textures repeat appropriately) but it causes an error in OPE, which apparently checks if there are any texture dimensions that exceeds the actual mip. I have decided that for better compatibility I will respect OPE and not utilize this "tiling" technique.

- I am using asphalt.m16 from the "high quality" Laguna that comes with the Rendition game. I believe this asphalt uses RGB colors instead of being constrained by the palette, because when I open it in Winmip it's telling me it uses 19 colors.

[Pavel 69]

M16 is the same mip format used in Nascar 3 and Nascar Legends games.

I still don't understand this '40 mip' limitation. What it try to limit? Memory? Then I'm doubt that having 60 small mips with fewer sub images requires more RAM than 40 big mips with more sub imagaes. And I still haven't found reason why game refuse to load carsets with high resolution mips. Carsets always contain same number of mips. There maybe some variations depending on pacecar model in use. But tests shows that replacing car mips with lower resolution let game to load carset. So I don't think only number of mips is a problem.

[samsepi0l]

Some other notes from today:
- I don't remember if I posted this before, but when we load a textured TSD into OPE, it's going to write MIP="<filename.mip>" along with the file extension, when it really should be MIP="<filename>". Papyrus's 3D23DO apparently has no trouble with this, but Noorok's converter quits with an error. So, the fix is to find/replace all instances of <filename.mip> to <filename>.

Remember I learned this when I made my sanair track- The textured TSD was causing this to crash and I was panicking. We showed nooRok and he figured it out.

[checkpoint10]

@Pavel - I agree there must be a real memory limit but I am proposing that there is a mip count limit that is often reached before we get to the memory limit. Who knows why there seems to be an arbitrary limit but maybe it’s like how there is a ~300-file limit for dat files even though the game can handle more.

[checkpoint10]

I've been continuing to work on combining mips on Detroit but now I am finding the limit to vary, sometimes a track + garage fully works at 51 mips but sometimes it's less. I still believe the limit is the number of images, but it may include the number of subimages as well. Maybe PMPs too. So I think the limit is not ~50 mips, it might be something higher, maybe like 512 total images and subimages (that number is just a guess, I haven't done anything to confirm this).

Perhaps some of the modded carsets don't load because the mips have more subimages than the game expects.

Now I don't know if this can be addressed simply by reducing the number of subimages per mip while keeping the full-size image the same. I haven't done any experiments since I had this thought just now.

EDIT: 45 mips / 299 images is where I'm at now, with garage working. Just adding a couple mips to it (approx 18 more images) breaks the garage.

[samsepi0l]

Do you think this has anything to do with the rendition version being just buggy in general? I heard Jake's review and he says it is very "alpha".

[checkpoint10]

I don't think it's just down to being generally buggy. Whether something loads or doesn't load is reproducible with the same parameters.

46 mips / 314 images and the garage doesn't work.

EDIT: 45 mips / 307 images, garage still doesn't work. Could the limit be somewhere between 299 and 307 images?