+- Forums (https://www.icr2.net/forum)
+-- Forum: CART Racing Headquarters (https://www.icr2.net/forum/forumdisplay.php?fid=1)
+--- Forum: Indycar Racing 2 - CART Racing (ICR2) (https://www.icr2.net/forum/forumdisplay.php?fid=2)
+--- Thread: Riverside track project (/showthread.php?tid=1537)
RE: Riverside track project - checkpoint10 - 05-25-2024
I made some rough LPs to test car visibility and I have found:
- As Dennis suggested, moving the TSOs as far back as possible minimizes the cars disappearing.
- The DYNO statement doesn't appear to work in TSOs (i.e. cars are not drawn on the track TSO when the rest of the TSO is visible).
- TV cameras seem to treat objects differently, I think the TSO is still overlapping the track when the car is at a section that shouldn't have the TSO there.
I am wondering if it might be possible to adjust the DYNO statement within some track sections of the track.3d file to make the game draw the cars at farther DLONGs. There was one time on Nashville that I somehow made cars visible from the other side of the bridge, even though there is obviously a big DLONG gap between one side and the another side.
RE: Riverside track project - Dennis - 05-25-2024
(05-25-2024, 07:42 AM)checkpoint10 Wrote: I made some rough LPs to test car visibility and I have found:
- As Dennis suggested, moving the TSOs as far back as possible minimizes the cars disappearing.
- The DYNO statement doesn't appear to work in TSOs (i.e. cars are not drawn on the track TSO when the rest of the TSO is visible).
- TV cameras seem to treat objects differently, I think the TSO is still overlapping the track when the car is at a section that shouldn't have the TSO there.
I am wondering if it might be possible to adjust the DYNO statement within some track sections of the track.3d file to make the game draw the cars at farther DLONGs. There was one time on Nashville that I somehow made cars visible from the other side of the bridge, even though there is obviously a big DLONG gap between one side and the another side.
You have to modify the structure in the TSO sectors.
It's still a mystery, why the structure of the regular sectors in the 3D file works, because it shouldn't, if I understand the functions of the 3D file right, and it doesn't, if I use the same structure in the TSO sectors.
This is the structure of a regular subsector
FACE (track surface)
LIST
BSPA (right wall)
BSPA (left wall)
left objects
left wall
DYNO
right wall
right objects
track surfaces
And this is the structure of a TSO subsector, how I did it
BSPN(right wall)
BSPN(left wall)
left wall
FACE(track surface)
LIST
track surfaces
DYNO
right wall
To collect multiple subsectors to a single object, I used the BSPN function, with the plane of the end points of the walls at the border of the subsectors. There are probably different ways to do this, I did it like this.
Let's say the sector has 6 subsectors: s0, s1, s2, s3, s4, s5
then my BSP tree is
r1: BSPN() s5,s4
r2: BSPN() s1,s0
r3: BSPN() r1,s3
r4: BSPN() s2,r2
r5: BSPN() r3,r4
RE: Riverside track project - checkpoint10 - 05-25-2024
I actually didn't try anything too different for my track TSOs. All I did was remove the first FACE statement and then remove references to objects. For example:
Code:
sec35_s0_LO:
LIST {
% Output right wall BSP
BSPA
([< 13912035, 2718786, 381643 >],
[< 14750644, 2713883, 433171 >],
[< 14751565, 2714049, 412192 >]),
% Output left wall BSP
BSPA
([< 14055077, 3467040, 317105 >],
[< 14637663, 3340504, 367395 >],
[< 14638473, 3344103, 343680 >]),
% Output left side TSOs
LIST { NIL } ,
% Output left side wall
POLY __wallreg2__.c {
[< 14055077, 3467040, 317105 >],
[< 14053472, 3465808, 341019 >],
[< 14637663, 3340504, 367395 >],
[< 14638473, 3344103, 343680 >]
}
,
DYNO { 25816887, 26532228, -353500, 408304 } ,
% Output right side wall
POLY __armcreg1__.c {
[< 13912035, 2718786, 381643 >],
[< 13911229, 2718940, 402626 >],
[< 14750644, 2713883, 433171 >],
[< 14751565, 2714049, 412192 >]
}
,
% Output right side TSOs
LIST { NIL }
,
% Output road surface
POLY __Grass2__.c {
[< 13912129, 2719277, 381643 >],
[< 14751477, 2714541, 412192 >],
[< 14717379, 2904505, 351172 >],
[< 13948368, 2908844, 320559 >]
} ,
POLY __Dirt1__.c {
[< 13948368, 2908844, 320559 >],
[< 14717379, 2904505, 351172 >],
[< 14710312, 2943876, 349922 >],
[< 13955879, 2948132, 319439 >]
} ,
POLY __Paint__.c {
[< 13955879, 2948132, 319439 >],
[< 14710312, 2943876, 349922 >],
[< 14709605, 2947813, 349797 >],
[< 13956630, 2952061, 319327 >]
} ,
POLY __Asphalt3__.c {
[< 13956630, 2952061, 319327 >],
[< 14709605, 2947813, 349797 >],
[< 14670384, 3166321, 342897 >],
[< 13998314, 3170113, 313114 >]
} ,
POLY __Paint__.c {
[< 13998314, 3170113, 313114 >],
[< 14670384, 3166321, 342897 >],
[< 14669677, 3170258, 342773 >],
[< 13999065, 3174042, 313003 >]
} ,
POLY __Concrete2__.c {
[< 13999065, 3174042, 313003 >],
[< 14669677, 3170258, 342773 >],
[< 14667557, 3182069, 343441 >],
[< 14001318, 3185828, 313598 >]
} ,
POLY __Dirt1__.c {
[< 14001318, 3185828, 313598 >],
[< 14667557, 3182069, 343441 >],
[< 14644943, 3308056, 338441 >],
[< 14025352, 3311551, 309098 >]
} ,
POLY __Dirt1__.c {
[< 14025352, 3311551, 309098 >],
[< 14644943, 3308056, 338441 >],
[< 14638473, 3344103, 343680 >],
[< 14055077, 3467040, 317105 >]
} ,
% Output the racing line
NIL
% Finish the segment
}
;At the end, I did this. Basically just a list of all the sections in descending order:
Code:
root: LIST {sec40_s0_LO, sec39_s1_LO, sec39_s0_LO, sec38_s1_LO, sec38_s0_LO, sec37_s0_LO, sec36_s0_LO, sec35_s0_LO};It seems to work well enough...
EDIT: I think I may get better results if I broke up my track TSO into the 8 TSOs and put each of them in the ObjectList only as needed. I also found that I was able to get around the TV view issue by putting a BSPF function to make the TSO invisible when the view is slightly above the highest point of my TSO.
RE: Riverside track project - samsepi0l - 05-28-2024
(05-25-2024, 04:59 PM)checkpoint10 Wrote: EDIT: I think I may get better results if I broke up my track TSO into the 8 TSOs and put each of them in the ObjectList only as needed. I also found that I was able to get around the TV view issue by putting a BSPF function to make the TSO invisible when the view is slightly above the highest point of my TSO.
I think BSPF makes the game run faster than BSPA. I use BSPF more because of this if I can get away with it. I think part of the problem with my Chicago oval is that I used BSPA on many parts of the main grandstand and this might cause some slowdown with many cars on the track at once coming out of t4.
RE: Riverside track project - samsepi0l - 06-21-2024
Do you have these 3d files? I was going to make the bridge on the back straight tonight.
RE: Riverside track project - checkpoint10 - 06-25-2024
I shared the working folder with you offline. Handing the track build off to you now!
RE: Riverside track project - samsepi0l - 06-26-2024
let the TSO's begin
RE: Riverside track project - Pavel 69 - 06-26-2024
(06-26-2024, 02:33 PM)samsepi0l Wrote: let the TSO's begin
RE: Riverside track project - samsepi0l - 06-27-2024
Do you guys like this for a track screen? I think it is from some fancy modern racing game.
I also looked at the "floating grandstand" and I think the easiest way to fix it would be to do a few things:
change the hill which is actually a TSO right under the grandstand like pavel said- to make it wider. This way when you approach the braking zone it will take up the full space under the grandstand.
Move the objects back further to other sectors so they come on sooner.
I am hoping this will work sufficiently.
RE: Riverside track project - Pavel 69 - 06-27-2024
I don't like that picture
What about this:
![[Image: 32615824788_52d1438e28_c.jpg]](https://live.staticflickr.com/4809/32615824788_52d1438e28_c.jpg)
![[Image: 98f09b455d87f248c416a2a22208fd89.jpg]](https://i.pinimg.com/736x/98/f0/9b/98f09b455d87f248c416a2a22208fd89.jpg)