Track editing progress notes

[checkpoint10]

Thank you Pavel! Great reference.

[checkpoint10]

Brake markers: something you'd think are simple to put in, but have plenty of complexity of their own:

First, I decided to use the .PMP version of the brake markers. These are the objects in ICR2 that look the same from whichever angle, for example trees. I believe most if not all of the brake markers in the default ICR2 tracks are .PMP, so I just took the ones from Toronto to use in Caesars.

Now, since I am pretty committed to doing everything possible in OPE, I took the ICR2 to N2 converted brake markers (which are now .SRB textures) and did my usual bit of editing in OPE. I also used a technique for placing 3 markers with equal spacing, by placing the 1st and 3rd markers first, and then placing the 2nd marker but manually coding its location to be the average x and y location of the 1st and 3rd markers.

After converting it back to ICR2, I noticed that the brake markers are about the twice the size - I guess converting these types of objects to and from N2 creates this problem. So, I just copied over the .3DO and .PMP file from the stock ICR2 Toronto .dat file. More precisely, I have now extended my Python script to include the unpacking of the ICR2 .dat file after conversion, copying the load screens and brake markers (whatever didn't convert properly) directly into the unpacking folder, and then repacking the ICR2 .dat file. This is a really big chore of a workflow that I would recommend anyone to automate, either through batch file or your own script.

Other miscellaneous lessons from today:
1) The Tutorial recommends against putting down more than 3 walls in a section. But I added a 4th wall today (to close off the pit lane island) and it seems to work okay in game. So I don't know why the Tutorial thinks 3 is the maximum.

2) More conversion errors today, which I believe are not caused by fenced or unfenced walls as I had reported before. Instead, the errors seem to be caused by something related to TSOs. Eventually I resolved it simply by adding another TSO - a most unsatisfactory solution. It is still a mystery to me why that fixed it.

[Wolf_pd]

That 3 wall reference is odd. Using a third wall next to the outer and inner wall is good practice. Adding a fourth wall to create a double walled pitwall might give bleeding issues though. More than 4 walls does not work in ICR2.

From my personal notes from 2005

[Pavel 69]

First, I decided to use the .PMP version of the brake markers. These are the objects in ICR2 that look the same from whichever angle, for example trees. I believe most if not all of the brake markers in the default ICR2 tracks are .PMP, so I just took the ones from Toronto to use in Caesars.

Now, since I am pretty committed to doing everything possible in OPE, I took the ICR2 to N2 converted brake markers (which are now .SRB textures) and did my usual bit of editing in OPE. I also used a technique for placing 3 markers with equal spacing, by placing the 1st and 3rd markers first, and then placing the 2nd marker but manually coding its location to be the average x and y location of the 1st and 3rd markers.

After converting it back to ICR2, I noticed that the brake markers are about the twice the size - I guess converting these types of objects to and from N2 creates this problem. So, I just copied over the .3DO and .PMP file from the stock ICR2 Toronto .dat file...

It's bad idea to convert ICR2 objects to N2 then and back again. 3do size will increase, pmp objects properties will be corrupted and most important - palette and texture colors will look bad.

I always have two working temp folders. First is temp folder with objects, textures and palette in ICR2 format. Second temp folder is OPE folder with objects in N2/N3 format. Most of this objects are not from track but just replacements. I don't convert objects form icr2 but use simple lamp poles 3do as replacement. So I add several new objects to OPE.TSO manually, then in OPE load OPE.TSO and generate TRACK.3D. From this 3D I create TRACK.3DO and then simply drop it to ICR2 temp folder without conversion. Then I open TRACK.3do in ICR2 temp folder with 3doEdit, it loads all objects. I placed them in 3doEdit as I want and then copy new objects coordinates to OPE.TSO file.

[checkpoint10]

It's bad idea to convert ICR2 objects to N2 then and back again. 3do size will increase, pmp objects properties will be corrupted and most important - palette and texture colors will look bad.

I always have two working temp folders. First is temp folder with objects, textures and palette in ICR2 format. Second temp folder is OPE folder with objects in N2/N3 format. Most of this objects are not from track but just replacements. I don't convert objects form icr2 but use simple lamp poles 3do as replacement. So I add several new objects to OPE.TSO manually, then in OPE load OPE.TSO and generate TRACK.3D. From this 3D I create TRACK.3DO and then simply drop it to ICR2 temp folder without conversion. Then I open TRACK.3do in ICR2 temp folder with 3doEdit, it loads all objects. I placed them in 3doEdit as I want and then copy new objects coordinates to OPE.TSO file.

Pavel, I really appreciate your time sharing your insights. Hoping for more clarification on the following:

1) When you mention 3doEdit, may I confirm you are talking about 3doEd by Dave Noonan and which version number? (I use version 1.0i).

2) If you are using 3doEd, how do you easily move an object around the track? Are you just typing in the coordinates under Object Info or is there a more visual way to do it?

3) When you convert a TRACK.3DO from the N2 format to ICR2 format, are you using "n2toicr2" also by Dave Noonan? Version number is 1.00l for me.

4) What is in your TRACK.3DO at the time you convert it to ICR2? From your comments above, I believe you would have placeholders for any ICR2-sourced objects. Is the rest of the track fully built and textured as it would appear in game? What do you do when you source objects from N2/N3 or build your own objects from scratch - do you let those convert along with TRACK.3DO?

[Pavel 69]

1) Yes, version 1.0i
2) Unfortunately it can be done only by typing coordinates under object info.
3) Yes
4) In N99 tracks folder I have track called 'icr2'. Inside this track folder there are all usual track files. But dat file is almost empty. So when I need to covert any 3do (object or main track.3do) from N3/N2 format to ICR2 format I just add only 3do file to dat with DooDat tool and convert this track folder with converter. Then I extract converted file from dat and add it to my ICR2 track. I never convert full track folders.

Track folder is below

[checkpoint10]

Thanks Pavel. This is interesting to compare workflows - when I read the Tutorial (and I admit I have misread it before!), I got the impression that I should try to convert the entire track. On one hand it is nice because OPE provides a "WYSIWYG" editing experience and I am usually assured of what the track will look like in game after conversion. But doing the conversion piece by piece might provide better control over what is going into the ICR2 track folder and .dat, and you are right the 3DO files are larger and may have palette issues when converted from ICR2 to N2 back to ICR2. I currently have an inelegant approach where I keep a folder of files that I know will not convert well, and then copy them back into the converted ICR2 track.dat.

Today I found v1.01c of the N2toICR2 converter (it is in the N2<>ICR2 converter package in http://trackshoppe.com/utilities/utilities.htm). It seemed to be an improvement for my existing workflow because it successfully converted a track when the previous version gave a conversion error, and the documentation says that "tree texture" conversions have been improved.

[checkpoint10]

I made a billboard! It might not sound like much, but I coded it in a text file and converted using 3D23DO following the guidance from Pavel's document. It might be a bit large at the moment, but at least I have good control over exactly how big it needs to be just by editing the text file and recompiling the .3DO.

From here, I will move on to objects with more than one face.

Here's the source:

3D VERSION 3.0;

% USER DEFINED POINTS
point0001: [< -200000, 0, 0>, T=<0, 127>];
point0002: [< -200000, 0, 400000>, T=<0, 0>];
point0003: [< 200000, 0, 400000>, T=<127, 0>];
point0004: [< 200000, 0, 0>, T=<127, 127>];

% POLYGONS
side1: POLY [T] <41> {point0001, point0002, point0003, point0004};

side101: MATERIAL MIP="bill2", GROUP=3, side1;

% BSP TREE
_S1: FACE (point0003, point0002, point0001), side101;

[Wolf_pd]

Nice work.

[checkpoint10]

Thanks Wolf.

I was able to create a couple of real 3D objects today - the screenshot shows two buildings that I've stuck together to form the Caesars Palace hotel towers.

I didn't want to do manual keying of coordinates, so I put together this process:
- I took a screenshot of the top view of the building from Google Earth
- Traced the vertices in GIMP to form the corners of the building
- Listed the coordinates in a CSV file (about 7-8 per building)
- Then I wrote a Python script that loads the CSV file, asks how many meters long the object is (which I can measure on Google Earth), and how tall I want the building. Converts everything to Papy units.
- It will then take the outline of the building and automatically create another set of vertices for the roof, and create polygons for all the sides and the roof, putting all these things into the .3D format for conversion to 3DO using 3D23DO.

I will share the script at some point, but I am still working out some bugs and the code is messy. But you can see I now have custom buildings - with authentic measurements - that work in game, and I can make more very quickly!

No textures yet but I imagine it's no big deal to add those by hand. Also, I do notice some bleeding of polygons against other objects from certain angles - I am not sure why, although it is not much different than similar graphical issues that happen on the default ICR2 tracks, so I don't know if it's something that can be fixed anyway.