Forums

No, you do not need to convert the menus through the N2 to ICR2 converter. In fact, I don't even know if that would work. Those are also the files that you can create without the aid of a converter and I normally add them in manually along with the mips where I do not rely on the converter.

I believe it is almost the case that the N2 to ICR2 converter is only truly necessary to convert .3DOs from N2 format to ICR2. Over in the other thread maybe we will someday get to a point where we have our own 3D23DO for ICR2 once the file format is fully understood.

It is just for 3d0s. Most other files are reusable without conversion and some of them will be corrupted by the conversion.

I was thinking- it would be sweet to build a tool that you can highlight a bunch of 3DO's in windows and right click to chose "convert to ICR2 format" and whalah! it would be done.

(04-01-2021, 06:49 PM)samsepi0l Wrote: [ -> ]I was thinking- it would be sweet to build a tool that you can highlight a bunch of 3DO's in windows and right click to chose "convert to ICR2 format" and whalah! it would be done.

That would definitely streamline the process - I think a simple tool to get a 3DO from N3 to ICR2 format would eliminate a lot of steps we currently have in-between (MRON, fixing the flavors for some of the polys by using 3DO2DEF/DEF23DO, using the converter, unpacking the result and fixing colors).

(04-05-2020, 11:29 PM)checkpoint10 Wrote: [ -> ]I believe I can answer my own question. The key is to add the object to the ObjectList lines for more track sections in the track.3d file:

ObjectList_R2_1: LIST {__TSO41, __TSO40, __TSO25, __TSO26, __TSO2, __TSO38};

The Holiday Inn hotel is TSO41 and TSO40. So I just added them to the couple of track sections before where OPE had automatically placed them in. Also, I found that the order matters - I had some trouble with the farther building bleeding into the closer building, this seemed to be fixed by reordering the ObjectList - for example putting the hotel at the beginning of the list ensures that they are drawn first.

I am having some issues similar to this. I don't know if you had a chance to see the video clip I posted testing tamiami in my "tamiami build thread". You can see in several places that objects (mostly trees) are showing through grandstands and other objects that the trees should be behind. I had originally thought of solving it the way you describe above- but Pavel clued me into the a method of "combining objects" with BSPN. I searched for BSPN to learn how to use this better this morning, but I'm still not sure.

The best example is turn-2, you can see as you approach the left hand corner that there are several trees that you can see that should be behind the grandstand.

I saw the video - the track is looking good! I have not tried Pavel's method using BSPN because I don't yet fully understand the function, but my "quick" solution is to first use OPE to recalculate the drawing order. Within OPE, try F1 > Option 1. Save and run 3D23DO again and see if it helps.

Assuming you still need to fix some drawing orders, you can then identify the specific trees that are problematic and make sure they are appearing towards the beginning of each ObjectList they are in. This will always ensure that they are being drawn before the other objects.

Finally, I can see how an approach to combine multiple objects together may be helpful - in fact I did this on Nashville with the buildings in the downtown area and the stadium, but my method was different. I created a new .3D file that works like the top part of the track.3d file, e.g.:

pointer1: DYNAMIC ..., EXTERN "xxx1.3do";
pointer2: DYNAMIC ..., EXTERN "xxx2.3do";
pointer3: DYNAMIC ..., EXTERN "xxx3.3do";
pointer4: LIST {pointer1, pointer2, pointer3};

Basically I am using LIST to define the drawing order for all these objects (xxx1, xxx2, xxx3) and then in the track I am treating the group as one object. The reason for this is to simplify the track.3d file and reduce situations where individual objects are flipping back and forth in the drawing order.

(04-06-2021, 06:16 PM)checkpoint10 Wrote: [ -> ]I saw the video - the track is looking good! I have not tried Pavel's method using BSPN because I don't yet fully understand the function, but my "quick" solution is to first use OPE to recalculate the drawing order. Within OPE, try F1 > Option 1. Save and run 3D23DO again and see if it helps.

Assuming you still need to fix some drawing orders, you can then identify the specific trees that are problematic and make sure they are appearing towards the beginning of each ObjectList they are in. This will always ensure that they are being drawn before the other objects.

Finally, I can see how an approach to combine multiple objects together may be helpful - in fact I did this on Nashville with the buildings in the downtown area and the stadium, but my method was different. I created a new .3D file that works like the top part of the track.3d file, e.g.:

pointer1: DYNAMIC ..., EXTERN "xxx1.3do";
pointer2: DYNAMIC ..., EXTERN "xxx2.3do";
pointer3: DYNAMIC ..., EXTERN "xxx3.3do";
pointer4: LIST {pointer1, pointer2, pointer3};

Basically I am using LIST to define the drawing order for all these objects (xxx1, xxx2, xxx3) and then in the track I am treating the group as one object. The reason for this is to simplify the track.3d file and reduce situations where individual objects are flipping back and forth in the drawing order.

I have gotten into the habit of always pressing "F1" and selecting "1" re-calculate drawing order before I save any changes in OPE.

I put together the following images in hopes of fully understanding what you are trying to teach me, and also to help others in the future if the same problems arise.

This is helpful. If TSO22 is appearing in these four ObjectLists, you should ensure that that the trees TSO168 and TSO170 are always being drawn first in all four of these rows. If you sometimes have TSO22 by itself, it may cause it to be drawn first depending on where you are on the track and which lists the trees are at.

The quick fix is to have all four of those lists start with "(__TSO170, __TSO168, ..." and then you make sure __TSO22 appears later or last on the list. If TSO168 and TSO170 aren't already in a list (such as Line 453) you should manually add them to the beginning of the list. To say it another way, if the position of TSO22 relative to TSO170 and TSO168 are important, they should always be in the same lists together, in the desired order.

(04-07-2021, 09:36 PM)checkpoint10 Wrote: [ -> ]This is helpful. If TSO22 is appearing in these four ObjectLists, you should ensure that that the trees TSO168 and TSO170 are always being drawn first in all four of these rows. If you sometimes have TSO22 by itself, it may cause it to be drawn first depending on where you are on the track and which lists the trees are at.

The quick fix is to have all four of those lists start with "(__TSO170, __TSO168, ..." and then you make sure __TSO22 appears later or last on the list. If TSO168 and TSO170 aren't already in a list (such as Line 453) you should manually add them to the beginning of the list. To say it another way, if the position of TSO22 relative to TSO170 and TSO168 are important, they should always be in the same lists together, in the desired order.

I see what you mean. I am going to try that on my next test. I watched my video alongside the youtube footage of the real race (in car camera with Al Unser Jr) I had some other adjustments to make and I think I want to add a few more trucks near the pitlane. Long term though I wonder if it would benefit us to better understand Pavel's method with BSPN because I think the last thing we really need to master is the BSP tree stuff. I'm getting much more confident- I'm at a place now that I never thought I would be. I hope these threads help anyone in the future that tries to take this stuff on.

Reading Pavel's description of BSPN it seems to be useful if a group of objects or polygons may be seen from two opposite perspectives. For example if you have a couple buildings in a row along the track, I imagine BSPN could be useful to ensure that the draw order is correct both as you are approaching the buildings and driving away and looking backwards at them.