Forums

I made a Python program that goes through a list of track sections and changes the direction of the right side fences within the .3D file! Turned out it was not too difficult to do, and I think some of the code could be adapted to do other things with the .3D file as well.

Oh, that's great! Btw, can you write some script that will aplly some offset to all points in 3d file? So that I can specify 3d files, x,y,z offset and script then add this offsets to all points.

I have been a bit silent lately but please know that I am following your progress with admiration.

(08-20-2021, 08:09 AM)Pavel 69 Wrote: [ -> ]Oh, that's great! Btw, can you write some script that will aplly some offset to all points in 3d file? So that I can specify 3d files, x,y,z offset and script then add this offsets to all points.

Yes, that should be possible. I was wondering how that might be useful in track editing - maybe you are thinking of applying that to trackside objects (or parts of objects that you want to fit together)?

(08-20-2021, 08:57 AM)Tjerk Wrote: [ -> ]I have been a bit silent lately but please know that I am following your progress with admiration.

Thanks Tjerk!

(08-20-2021, 04:26 PM)checkpoint10 Wrote: [ -> ]

(08-20-2021, 08:09 AM)Pavel 69 Wrote: [ -> ]Oh, that's great! Btw, can you write some script that will aplly some offset to all points in 3d file? So that I can specify 3d files, x,y,z offset and script then add this offsets to all points.

Yes, that should be possible. I was wondering how that might be useful in track editing - maybe you are thinking of applying that to trackside objects (or parts of objects that you want to fit together)?

I need it for carset editing  Damaged parts should be centered around zero coordinates to fly off properly from the car, as I understand. So I need to move them.

(08-20-2021, 07:01 PM)Pavel 69 Wrote: [ -> ]I need it for carset editing  Damaged parts should be centered around zero coordinates to fly off properly from the car, as I understand. So I need to move them.

Got it. In that case, I could even build a function to calculate the center of the object (at least taking the average of the minimum and maximum x,y,z points) and move the object accordingly.

Are you editing carset parts with an N3 .3D file now (as opposed to the vertex.def/flavor.def from the Bassino tool)?

Ah, that's not needed to calculate center. I will better eneter offset manually.

Yes, I know edited/converted carset 3do with new tools. Before I never touched car parts, because it was hard and too long manually convert flavor and vertex files to 3d format. New converters changed editing process in better way.

(08-20-2021, 08:25 PM)Pavel 69 Wrote: [ -> ]Ah, that's not needed to calculate center. I will better eneter offset manually.

Yes, I know edited/converted carset 3do with new tools. Before I never touched car parts, because it was hard and too long manually convert flavor and vertex files to 3d format. New converters changed editing process in better way.

See if this works for you.

[attachment=1837]

The function you need is called "move_vertices" and I have it set up right now so that you just need to change the (x,y,z) that is given to the function, and also change the input_file and output_file.

I commented out some other stuff I am working on, one is used to flip fences and the other one simply outputs a list of track sections. You can ignore those for now.

Thank you! I will test it.

(04-06-2021, 01:12 PM)samsepi0l Wrote: [ -> ]

(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.

(04-07-2021, 07:08 PM)samsepi0l Wrote: [ -> ]

(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.

(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.

So I am trying to solve some of my drawthrough issues.  How does this look for the previously posted issue with the trees showing through the grandstand?


I figure the best way to test this, is with the new tool that lets me convert it from N3 without all of the old foolishness we had to do right?