Forums

(03-23-2021, 06:44 AM)checkpoint10 Wrote: [ -> ]Yes, the tire tracks are TSDs. Trees are generally 3DOs that reference PMP files, yes. This picture from my Nashville track in 3DOEd shows green squares that are standing in for tree1.3do, tree2.3do, etc.

I'm trying to make some small 3DOs that will be like your green squares that you use as placeholders for trees.  I used your brake marker example and I modified it some.  I was going to use a purple-square to identify palm trees.  I picked colors 116 and 117.

Here is the code that I used:

---

3D VERSION 3.0;
% USER DEFINED POINTS
% a d
%
% b c

% POINTS
a: [< -6000, -6000, 0>];
b: [< -6000, 6000, 0>];
c: [< 6000, 6000, 0>];
d: [< 6000, -6000, 0>];

% POLYGONS
top: POLY <116> {a,b,c,d};
bottom: POLY <117> {d,c,b,a};

% BSP TREE
nil: NIL;
s1: BSPF (a,b,c), nil, top, nil;
s2: BSPF (d,c,b), nil, bottom, s1;

---

I figured 2ft by 2ft would be a good size for testing.  I think I got it to work but I am still pretty much lost when it comes to the BSP TREE. 

I figured I'd just pick a few different color squares like this to represent different kinds of trees.

I assume I'd have to make the entire track and run it through the conversion process back to ICR2.  Then when I am completely done I can swap the correct PMP/3DO files with the actual tree image in there into my game....  I will need to make sure they have the colors from my tracks sunny.pcx right?

Looks like you are getting the hang of coding the 3D file. Great job.

One small feedback, it appears you intended for points b and c to be the ones closer to the viewpoint, in which case they should have negative y values. On the y axis, positive values go away from you, negative values go toward you. This will matter more later on - keep this in mind if you find your polygons flipped or otherwise not appearing as you expect.

Also, unless you intentionally did this, it was not necessary to have a polygon on the underside since you will not ordinarily see it from that angle. As an exercise, you may want to try it with just one polygon so you can tell whether you have defined the BSPF points in the correct order. If you got them backwards (or your coordinates backwards) they may not appear in OPE or the game as you expect (i.e. they become invisible).

(03-24-2021, 06:22 AM)checkpoint10 Wrote: [ -> ]Looks like you are getting the hang of coding the 3D file. Great job.

One small feedback, it appears you intended for points b and c to be the ones closer to the viewpoint, in which case they should have negative y values. On the y axis, positive values go away from you, negative values go toward you. This will matter more later on - keep this in mind if you find your polygons flipped or otherwise not appearing as you expect.

Also, unless you intentionally did this, it was not necessary to have a polygon on the underside since you will not ordinarily see it from that angle. As an exercise, you may want to try it with just one polygon so you can tell whether you have defined the BSPF points in the correct order. If you got them backwards (or your coordinates backwards) they may not appear in OPE or the game as you expect (i.e. they become invisible).

Really I was just trying to take your code for the brake marker and turn it flat so I could use it as a tree-marker, I read the BSP instructions and I still have no clue how to use the BSP stuff.

USER DEFINED POINTS part is easy.  I see how you use a little diagram that looks like "A D" on the top, "B C" on the bottom. 
X negative is on the left, X positive is on the right.  Y negative is on the Top, Y positive is on the bottom.  That's how I came up with this:

% POINTS
a: [< -6000, -6000, 0>];
b: [< -6000, 6000, 0>];
c: [< 6000, 6000, 0>];
d: [< 6000, -6000, 0>];


Now, with the polygons, I only used 2 sides because your example (which I modified) had 2 sides.  Looking at the purple square from the top, I went around counterclockwise from 12 o'clock.  It goes A, B, C, D.

I imagined myself being on the INSIDE of the screen for the bottom, and went around the opposite direction, it goes D, C, B, A....

This is how I came up with:
% POLYGONS
top: POLY <116> {a,b,c,d};
bottom: POLY <117> {d,c,b,a};

As for the BSP TREE portion, I just guessed.  It's frustrating as all hell that I don't get this part.  We need a youtube tutorial.

I loaded them in OPE, and it seems like they come up OK.  I just wanted to place these where the palm trees will go.  (I'm trying to use your tree method)

I think the ordering of points in POLY (clockwise or not) may be less important than the ordering of points in the BSP function, the latter is what determines whether a polygon is being drawn depending on the position of the viewer. Of course for your sanity you should keep both consistent. We only use the first three points of the poly for the BSP function because you need just 3 points to define the plane that determines whether the polygon is visible or not.

I know BSP is confusing but you can think of it has having two functions - 1) it tells the game what is the plane that controls visibility for that polygon, and 2) it is also a "collector" or "accumulator" so each time you call BSP you are typically adding a polygon to all the ones before it. So, if you think of "s1" as a container with the first polygon "top", "s2" is a container that now contains both "s1" (which includes "top") and a second polygon ("bottom"). Extending this further, if I wanted to add another polygon to the object, I would all another BSP function, reference "s2" which is so far the cumulative list of polygons, and add another one (e.g. "side3") to it.

Don't know if that helps or confuses things more, but I assure you it will make sense after you do some more. Keep at it!

Does anyone know why every now and then 3DOEDIT does not like to cooperate with respect to loading the correct sunny.pcx pallet? When I load my tamiami.3do sometimes it is stubborn and pulls up some random pallet that is not correct. All of my color numbers are right, but because the pallet is different all of the colors look wrong.

EDIT: I found that it seems to act up like this when I have the 3DO open in OPE and I try and open it in 3DOedit at the same time. If I close OPE and re-load it in 3DOEDIT it seems to be OK.

Question for the rules regarding the naming of MIPS and PMPs that are hidden inside of the 3do file.

Normally, I open my 3do file on a hex editor and I can see the name of the file associated with the image...

I know that ICR2 and dos in general supports 8 charecter file names... if the original file name of an image has LESS than 8 charecters, is it safe to expand the name to the next few spots in the 3do when you edit in the hex editor?

Like for example... this "tree1.3do" has an image called "tree1" inside of the 3do when I view it with a hex editor. (So the original image must be tree1.pmp). Let's say I want it to be "midtree1.pmp".... can I do this or is it a bad idea?

I have not tried this, but yes I believe you can do that. According to the BB&B notes on 3DO file structure, "the file names are each stored in 8 bytes, left-justified, with value (00)hex being used to fill in any extra space at the end."

(11-19-2020, 07:09 AM)checkpoint10 Wrote: [ -> ]- I did not like the size of one of the trees, so I am able to adjust the size of the ICR2 tree1.3do by hex editing. Within the hex editor, I noted that offset(h) 34 is a number that probably is the width of the object in 500ths. There are converters online that can convert a decimal number to a little endian hex number, which helped with this step.

I use a website called hexed.it and I loaded the 3do with this.

I see offset(h) 34.... do you see the value of this? here in my example as a 24 BIT integer it shows value 210,000 which should be equal to 35 feet if indeed it is as you suggest... but am I correct saying that this runs into hex values 34, 35 and 36 because it is a 24 BIT integer? I hope this makes sense... for example here if I want to shrink this tree to say only 20 feet, it would need to be 20 times 6000 = 120000. In order to type value 120,000 into spot 34 it will "spill" into spots 35, and 36.

Does this make sense? and do you agree?

So guys- I want to post this so others can benefit and not have to go through what I went through.

I tried doing some work to the trees, which is surprisingly difficult because you can only experience the changes when you load it on a working track.

• I was able to scale the size of the trees in the hexed.it website like I had just posted. The value does take up hexidecimal spots 34, 35, 36.
  
• I was able to rename the file to something longer than just a few letters (in my example I changed the name of a pmp from "tree1" to "tree1abc" and it worked fine, just like we thought it would
  
• I did have some problems converting a tree from detroit over to tamiami, because when I applied the tamiami sunny.pcx to the detroit trees it would not show up in the game. The track would load and drive fine but the trees were completely invisible. I was pretty careful that I used a completely white boarder around the image, color 255. The black portion on the inside was color 0. I saved it as a BMP when I was using winmip 1.2 and made sure the sunny.pcx pallet was applied in GIMP like I always do when I make MIPS for cars (or whatever).
  
• I tried "last chance tools" and I had better results converting the image to a PCX with the appropriate sunny.pcx, and then changed the PCX to PMP. It then worked in the game the way I expected.
  

EDIT- I posted this too quickly, there is still a rogue color showing up in my tree (it's like a silver color) - and it's not consistent when I do this so it has me wondering...

(11-19-2020, 07:09 AM)checkpoint10 Wrote: [ -> ]- Once I convert the track over to ICR2, I bring over the tree1.3do, tree1.pmp, etc. from a default track.

When you took your trees from another track, which track did you choose? Also did you have any colors misbehaving?