Forums

Just coded a traffic signal for my Nashville build and really happy how it turned out.



Here's the .3D file for this, all the lines beginning with % are comments and not picked up by 3D23DO. I broke up the object into sections and combined them together with BSPF or BSPA as I went along.

To compile, I ran 3D23DO /s=6000 filename, the /s converts my feet into 500ths

I just realized that I reuse the tags "o1" and "o2" which originally referred to the stages of putting together the light pole, but I guess once it gets collected with BSPF/BSPA, I was able to use those same labels for other points. Didn't seem to affect the end result.

3D VERSION 3.0;
% USER DEFINED POINTS

% LIGHT POLE
%
%  a  d
% b  c
%
%  e  h
% f  g 
% units = feet

a: [< -0.25, 0.25, 20>];
b: [< -0.25, -0.25, 20>];
c: [< 0.25, -0.25, 20>];
d: [< 0.25, 0.25, 20>];

e: [< -0.25, 0.25, 0>];
f: [< -0.25, -0.25, 0>];
g: [< 0.25, -0.25, 0>];
h: [< 0.25, 0.25, 0>];

% COLORS = 29,30

% POLYGONS
ls: POLY <29> {a,e,f,b};
rs: POLY <29> {c,g,h,d};
fr: POLY <30> {b,f,g,c};
bk: POLY <30> {d,h,e,a};
tp: POLY <22> {a,b,c,d};

% BSP TREE
nil: NIL;
o0: BSPF (a,b,c),nil,tp,nil;
o1: BSPF (a,e,f),nil,ls,o0;
o2: BSPF (d,h,e),nil,bk,o1;
o3: BSPF (c,g,h),nil,rs,o2;
pole: BSPF (b,f,g),nil,fr,o3;

% ====================================
% LIGHT BRANCH

%          k                  m
% i        l                  n
% j

i: [<0.25, 0, 15>];
j: [<0.25, 0, 14.5>];
k: [<20, 0, 17.5>];
l: [<20, 0, 17>];
m: [<60, 0, 17.5>];
n: [<60, 0, 17.2>];

% POLYS
br1: POLY <30> {i,j,l,k};
br2: POLY <30> {k,l,n,m};

% BSP TREE
o4: BSPA (i,j,l),nil,br1,pole;
o5: BSPA (k,l,m),nil,br2,o4;

% ====================================
% LIGHTS AND SIGN

%  o  r
%
%  p  q
o1: [<20, 0, 19>];
p1: [<20, 0, 15>];
q1: [<22, 0, 15>];
r1: [<22, 0, 19>];

o4f: [<25, 0.1, 17.5>];
p4f: [<25, 0.1, 16>];
q4f: [<32, 0.1, 16>];
r4f: [<32, 0.1, 17.5>];

o2: [<35, 0, 19>];
p2: [<35, 0, 15>];
q2: [<37, 0, 15>];
r2: [<37, 0, 19>];

o3: [<50, 0, 19>];
p3: [<50, 0, 15>];
q3: [<52, 0, 15>];
r3: [<52, 0, 19>];

% POLYS
l1: POLY <30> {o1,p1,q1,r1};
l2: POLY <30> {o2,p2,q2,r2};
l3: POLY <30> {o3,p3,q3,r3};
s1f: POLY <104> {o4f,p4f,q4f,r4f};

% ==================================
% ATTACH LIGHTS/SIGN TO POLE/BRANCH (o5)

% BSP TREE
o6: BSPA (o1,p1,q1),nil,l1,o5;
o7: BSPA (o2,p2,q2),nil,l2,o6;
o8: BSPA (o3,p3,q3),nil,l3,o7;
o9: BSPA (r4f,q4f,p4f),nil,s1f,o8;

things like light-poles and signs seem so simple when you think about them quickly, but they add so much detail to the track when you are actually driving.

I have a question- the MRK images in my track seem to load when I am driving a little late.... it's almost like I can see them pop up later than they should, is there a way to adjust this so they have appeared when driving at a further distance?

I was reading the word document about BSP and BSPA, BSPF the other night and I understand very little of it now. It got to the point where I was frustrated so I had to stop. The XYZ coordinate stuff is easy but mostly I was lost with the BSP tree (I deal with XYZ at work because I use a CMM tool)

I don't know of a quick way to adjust when the textures appear on the walls as they come at you, but for each wall texture you use, you should be able to give it a unique polygon color. So from far away it will be a solid color but hopefully one that is similar enough to the texture so that it is not such a jarring transition when the game starts to use the textured wall.

I agree, the Word document is not an easy read for a beginner, unfortunately it is the only thing we currently have and to Pavel's credit it is actually a good source of detailed information once you know the fundamentals of .3D coding. Let me see if I can break it down to the most basic steps:

1) The easiest thing you can do is probably a billboard, so let's start there. It will only need 4 points, which you can define with any names you like (I just like using a, b, c, d...). This part I think you can get intuitively. You will probably end up with something like this:

3D VERSION 3.0;
% USER DEFINED POINTS

a: [< -20, 0, 20>];
b: [< -20, 0, 0>];
c: [< 20, 0, 0>];
d: [< 20, 0, 20>];

2) Make a polygon using those points. In the example below, I define a polygon using four points, and you can imagine it is a rectangle that starts on the upper left and goes through the points counter-clockwise. I give it the color at index 30.

p: POLY <30> {a,b,c,d};

3) Many .3D files contain the following line. All it does is assign the name nil to NIL, which seems to be an actual function that is understood by the compiler. I believe this can be skipped if you don't mind typing out all-caps NIL later.

nil: NIL;

4) The next part is the BSP tree. The purpose of this is to tell the game when to make the polygon visible. Let's say you have a plane that is defined by 3 points on your polygon (for example, a,b, and c). The game will check if you are "above" or "in front" of the plane, and if you are, then it will draw the polygon. Otherwise it will not draw it. This is advantageous for a building, where you may have 4 surfaces, each facing a different direction. If you are in a position where you are not supposed to see a surface (i.e. the surfaces that face away from you) then you don't want the game to draw those. Otherwise you may end up having surfaces that draw on top of one another.

Back to the example. We just need to worry about one surface. Let's call it s.

s: BSPF (a,b,c),nil,p,nil;

Here, we're creating a new object called "s" and it is created using a BSPF function. The BSPF function will take an existing object and add a polygon to it. In this case, we're adding a polygon "p" to "nil" (nil because this is the first surface in our object). Remember our discussion about the plane that defines the polygon's visibility - that plane is defined by the points "a,b,c".

I believe you can create anything with only BSPF. In most situations, you don't need to use BSPA or BSPN. BSPA might be handy if you have some reason to make a polygon that is visible from any direction, but you probably won't need to.

5) From here, you are done and you can do 3D23DO /S=6000 <filename> to check out your work. /S=6000 assumes you used feet as units but you could use Papy units as well in which case you do not need the /S argument.

6) So what if you have more than one polygon? Let's say you've got a two polygon object. You still create the first surface using BSPF as in the example above. Next, you will make a second BSPF line like this:

s2: BSPF (d,e,f), nil, p2, s;

What does this do? It takes the "s" object we already made in Step 4, add the polygon "p2" to it (you would've defined this polygon earlier in the file), and define a plane of visibility as (d,e,f) which is likely 3 points that are found in the polygon "p2". The whole thing is now assigned the name "s2." And if you are adding another polygon, you'd do the same thing, but pick up "s2" to add the new polygon to. Like a chain of polygons.

s3: BSPF (g,h,i), nil, p3, s2;

You'll notice I have left nil in there as the second parameter. I admit I haven't figured out what that would be useful for. I think I leave it as nil in 100% of the objects I've made so far.

(02-28-2021, 11:23 PM)samsepi0l Wrote: [ -> ]things like light-poles and signs seem so simple when you think about them quickly, but they add so much detail to the track when you are actually driving.

I have a question- the MRK images in my track seem to load when I am driving a little late.... it's almost like I can see them pop up later than they should, is there a way to adjust this so they have appeared when driving at a further distance?

I was reading the word document about BSP and BSPA, BSPF the other night and I understand very little of it now.  It got to the point where I was frustrated so I had to stop.  The XYZ coordinate stuff is easy but mostly I was lost with the BSP tree (I deal with XYZ at work because I use a CMM tool)

Do you use the -al or -am option at TRK23D? If yes, you could try it without them. I think wall textures only appear in high resolution segments. If you would have only high resolution segments, you would always see the wall textures. I've never tried this.
The other way is, as checkpoint10 says, you have to change the polygon colors in those segments, to have a better transition between the resolution levels.

Where to use the BSP commands?
---single objects---
FACE - 2D object, visible from one side (road surface, terrain surface, outside wall of a building)
FACE2 - 2D object, visible from both sides (billboard, trackside wall)
BSPF - 3D object, which isn't completely visible from point of view. One part of the object hides the other part. (house)
LIST - 3D object or a part of it, which is completely visible from point of view. No visible part hides another visible parts. (hillside, flagpole)
---multi-object collections---
LIST - Objects far away, which always appear in the same order
BSPN / BSPA - Near objects, which can appear in different order. BSPN for 2 objects, BSPA for 3 objects. I used that, as I redone the drawing order of the track segments, to import them as TSOs.
BSP2 - I haven't needed it yet.

Dennis, that is a great summary of BSP commands. I should look into using FACE for simple objects.

(04-04-2020, 08:03 PM)checkpoint10 Wrote: [ -> ]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;

I am trying to make the huge tower that is on the outside of tamiami turn-1 this way.  I figure a "billboard polygon" would be sufficient.


Here is the MIP/BMP I am trying to use.  It is 128 wide by 150 tall.


Now your original billboard for caesars was 128 x 128. I see this is why you used "0 to 127" as your coordinates. What does not make sense to me, is which one is X and which is Y?

I also see in the pavel document that it says:
Form:
pointXXXX: [< X, Y, Z>]; - point without texture mapping
pointXXXX: [< X, Y, Z>, T=<X mip, Y mip>]; - point with texture mapping

I don't see how the X and Y would match up. To me, spot (0,0) would be the lowest left corner. Spot (127,0) would be on the right bottom corner. Spot (127, 127) would be the top right corner.


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

I need to modify your code so the image will be 128 x 150 tall. I'm not sure which of the "127's" I should change to 149.

I switched the "400000" in your z coordinate to "469000" because of the extra height (150 vs 128 tall)

As for the polygons part, I'm still lost.

Well I just guessed which values should be what they are- and somehow it seems to have come out right (or at least I think?)

I went into 3doedit and viewed it and this came up:
[attachment=1749]

I said to myself I'd try and place this in the track with OPE and the joystick
[attachment=1752]

After I was reasonably happy, I saved it and went back into my text editor to look at the results... at the top of the 3D it shows a line... I believe this is the magic line I need to save right?

This way if I keep a SEPARATE text file with all of my objects, I can just paste it in when I am ready to finalize everything right?
[attachment=1751]

Very good job! That looks very nice.

The convention for images coordinates has always been in the form X,Y with 0,0 being the top left. Compared to the cartesian coordinate system used in geography, the Y values are of opposite sign.

Great job! If you want to keep a separate text file with your objects, I recommend saving both the rows that start with "__TSOxx" and all the "ObjectList" rows. The ObjectList rows determine the order the objects are drawn at any given track section.