Forums

I made some additional progress on track editing and wanted to share my notes. I will update this thread in the future for any more progress.

- I have noticed that N3 Sandbox includes some default wall textures and ground textures (specifically sand) which are the wrong textures. So if you create a new track via N3 Sandbox it will look particularly bad until you manually fix those textures, including bringing in a horizon from another track.

- N2 objects are in fact compatible with the N3 Sandbox suite of tools, such as 3D23DO and OPE. The palette structure (i.e. sunny.pcx) is largely similar.

- After running TRK23D and before running 3D23DO, you have an opportunity to edit the .3D text file, and in fact you may have to do that to change the colors of the walls, ground, fence, start/finish line, etc. The colors are based on the index in the palette which you can find in sunny.pcx. (Edit: I have just realized this process is also described in the Tutorial)

- I do not run SG2TRK, 3D23DO or TRK23D from N3 Sandbox, because I am unable to see the output from those utilities before DOSBox vanishes. So, I manually run them from the DOSBox command line. I had some frustrating issues with the N99 to ICR2 conversion utility which I am now almost sure is because 3D23DO had thrown an error that I didn't catch.

- It is possible to move around OPE without a joystick, by using the keypad home, end, ins, del, pg up and pg dn keys. This can be tricky because you can only move in the north, south, east and west directions, and up/down. You can't move towards some arbitrary direction even if you are facing that direction, unless it happens to be one of the 4 compass directions. (I still don't have a joystick in my current configuration although I understand it is better to have one)

My folder setup and workflow is as follows:

- I do all my work in a working folder totally separate from my ICR2 folder. I run SGE, SFE, SF2TRK, 3D23DO, TRK23D and OPE from that folder, all in DOSBox (instead of through N3 Sandbox)

- To save time, I made a script to automate the following after I am done with the N3 tools and want to try it in the game: 1) Copy MRON to the working folder. 2) Run MRON. 3) Make a packing list for the working folder. 4) Pack the working folder into a .dat in a "fake" Nascar2 track folder. 5) Launch N99 to ICR2 converter and convert the Nascar2 track directly to my ICR2/tracks folder. 6) Restore the 3DO files that MRON copied to the 3DOBackup folder.

Finally, I want to offer the observation that, once you figure out the workflow and go through the tutorials, it is very easy to build a minimally driveable track. I have prior experience building tracks for CART Precision Racing and I have to say that the ICR2 track building process is a much better experience and a lot more logical in how the geometry is laid down.

Attached screenshot of what I was able to do so far.

I was able to bring in a 3DO from a default ICR2 track using this technique. This may not be the most efficient but it works.

1) Used the ICR2 to N2 converter to convert an entire track to N2.
2) Unpacked the N2 version. Noted that the filenames are lost in the N2 conversion - they will have filenames like _072.3do which is a little inconvenient, but using 3DOEd it is not too difficult to identify which 3DO is which.
3) Copied the 3DO file to my working folder, renaming the file to something friendly. Any MIP files should also be copied over.
4) Load the 3DO in OPE and add to the track as usual.

Because I have no joystick, I had a workaround to adjust and finetune the location and orientation of the object. At the top of the .3D file, there are lines that look like this:

__TSO0: DYNAMIC 8742105, -8728374, 150000, 900, 900, 900, 1, EXTERN "vanloop";

The numbers from left to right are:
Latitude
Longitude
Altitude
Rotation (spinning around up/down axis)
Rotation (pitch)
Rotation (roll)
Scale, usually 1. Decimal amounts to attempt to scale below 1 will work in OPE but do not work once converted to ICR2. So probably should keep it at 1.

Rotation units are in degrees * 10.

I will gladly buy you a joystick if you can help me along with this. I think there is incredible value to this thread you've started.

(03-25-2020, 01:15 AM)samsepi0l Wrote: [ -> ]I will gladly buy you a joystick if you can help me along with this. I think there is incredible value to this thread you've started.

Appreciate the thought. I think I might just order a USB game controller. But I believe it is possible to get the keyboard mapped to the joystick in DOSBox. I will confirm later if that works.

(03-25-2020, 03:58 AM)checkpoint10 Wrote: [ -> ]

(03-25-2020, 01:15 AM)samsepi0l Wrote: [ -> ]I will gladly buy you a joystick if you can help me along with this. I think there is incredible value to this thread you've started.

Appreciate the thought. I think I might just order a USB game controller. But I believe it is possible to get the keyboard mapped to the joystick in DOSBox. I will confirm later if that works.

U can do it with a steering wheel for the "indy 500" game so joystick should work as well

Funny I was just watching vancouver 1991 on video (espn recording) and I saw the "loop" the other day.

Today's experiment is to decompile the N2 Watkins Glen, recompile, and convert to ICR2.

1) First step is to unpack the track into a working folder.

2) I opened WATGLEN.3DO in 3DOEd and performed List Inserts, which created INSERTS.TXT with the locations of all trackside objects.

3) At this point, the Tutorial says we use INS2OPE to getnerate an OPE.TXT that is readable by OPE. However, I found that INS2OPE does not translate the coordinates of INSERTS.TXT into the correct units for importing in OPE. Specifically:

Lat, lon, alt need to be multiplied by 19685
Rotations need to be multiplied by 10

I did not find any documentation for INS2OPE or 3DOEd about this issue, so I made a Python script to process INSERTS.TXT to create OPE.TXT with the right units. This was not too difficult because they are both text files. I will share this script when I have a chance to clean it up for public use.

(Edit: See later post in thread about the different versions of 3DOEd. The older one supports Papy units)

4) Now, I have to use TRKSG to extract a WATGLEN.SG file by putting the TRK file into the main track folder where the .DAT file is. The process is discussed in another forum thread.

5) I copy the SG file to the working folder, where I ran SGE (being sure to save it because it needs to generate a MRK file). Then ran SFE. Then ran SG2TRK, TRK23D and 3D23DO.

6) Open OPE and using menu F1, option 3, import OPE.TXT. All the objects should now be in the right places.

7) Save, exit OPE. Open the WATGLEN.3D file in a text editor and manually fix colors.

8) Run 3D23DO to create the 3DO again.

9) After this, the steps are the same to convert the entire track to ICR2.

As you can see from the screenshots, the track is mostly good even after conversion. The wall textures have been lost and would all need to be reassigned. Interestingly some of the TSD (lines on the ground) have been retained although skid marks have not been. (Edit: And the reason for that is, the painted track borders are in fact defined in SFE, by laying down "Paint Curbing" which is a bit of a misleading title as you do not actually lay down curbing but instead a solid color line.)

What does this mean for scratch built tracks? As far as I know, OPE for some reason does not allow you to save the locations of TSOs, so if for some reason you have to rebuild the SG, TRK and 3D files again, you lose all the TSO information unless you go through the above process to save the list inserts in 3DOEd etc.

This process should also work for ICR2 tracks if you first converted from ICR2 to N2 using that tool I described yesterday.

I would appreciate any feedback or corrections from the masters!

There is one problem that I can see now, and I am not sure of the best way to deal with.

The wall textures are automatically assigned by either SFE or one of the downstream utilities and I do not know an easy way to change those textures in any of those utilities. For some reason, the walls seem to be randomly assigned to any of the six default wall textures.

The textures are defined in the .3D text file, but there are lines of code for possibly hundreds of walls, where it is not obvious which wall is where on the track, except that the walls are defined in sequence by track section, possibly from left to right.

I imagine one way to deal with this is to open the track.3DO file in 3DOEd, use that to discover which section I need a texture changed, and then go into the correct spot in the .3D file to make the edit before recompiling the .3DO.

It appears that each track section may be identified in the .3D file as a main track section and then a sub track section. For example, the sections right after the start/finish line may be "sec0_s0" and "sec0_s1", and then followed by "sec1_s0", "sec1_s1" and so on. It looks possible to figure out both of the section/sub-section numbers in 3DOEd if you click on any object or polygon associated with that track section.

The other complication is that textures are reversed for the walls on the right side of the track, as seen in my screenshot. I wonder if it is easier to fix in the .3D file, or create texture files that are mirror images. The more elegant solution seems to be to fix it in .3D (to avoid duplication of texture files) but that would take additional coding. (Edit: As proof of concept, I manually flipped the textures on two of those wall textures, as you can see in the 2nd attachment. This process is not scaleable as I can't imagine having to do this hundreds of times.)

Perhaps I can write another Python script to parse and rewrite the .3D file to perform some basic functions like making all the walls the same texture, or flipping the texture coordinates for the walls on the right. However this would probably be a much bigger effort than my previous coding projects for ICR2.

EDIT: The answer is to use the .MRK file as described in some later posts.

I only see it reversed on the right side of the car in your picture.... not the left?

(03-26-2020, 09:42 PM)samsepi0l Wrote: [ -> ]I only see it reversed on the right side of the car in your picture.... not the left?

Yes, that is the problem. Textures are reversed by default on the right side.

---

To clarify, they are textured to appear correct when viewed from one side. It is like a flag where on the other side there would be a mirror image. So, one has to be careful not to have walls that can be seen from both sides, unless it's a plain texture (like concrete) where it doesn't matter.