Tracks Absolute newbie needs help creating track

I've uploaded a video of the problem:


Something is wrong, because my start points are far from the landmarks I see in the screen. These tree-like things are in the middle of the map, while my start point is at one of the corners of the map.


I don't have any problem running any other tracks or cars. Has anyone else encountered similar spinning issues when starting on your track?
 
I've packaged the current track folder here. Is anyone else able to help me test?


Just unzip the entire folder into your AC\content\tracks directory and load in CM. The track name is "mymarinacoastalexpressway".

When I load it in my AC, the car starts in the sky and falls and keeps rolling. It won't stop rolling on the ground. I used 'practice', 'start from pit'. I want to see if anyone else has the same problem. I've already run steam and checked my AC file integrity, and it checks out find.
 
1.jpg

it works okay-ish, car falls a little but respawns on the road again, but I think I found out why: I use the "Use double precision physics engine" setting of CSP.
If I turn it off, I will fall again, but on respawn the suspension is totally destroyed.

Try moving the start position up by a little, and also add 90° of rotation on the X-axis. Currently the car spawns pointing down I think, just like the pit guy.
 
Last edited:
Thank you! I finally got it to work.
What I did was

1. for all the start points, rotate them along the y axis -90 (original position assumes the car is pointing straight up, so this rotate action will point to to the front instead). Don't apply the rotate transform; leave the start points as Y axis -90 degree rotation

2. When exporting to FBX, use -z forward, y up

I guess now that I can finally drive on the track I'll be refining the geometry, adding elevation and thinking about how to texture it.
 
I'm planning to add a lot of trees.. is the best way to use 2D planes for every tree, to reduce CPU usage?
No, not per se.

Here are two posts that might clear things up :)
 
You are limited to the materials and texture slots given in ksEditor. So basically you are right and every material needs its own texture (preferably DDS and not PNG/JPG/TGA).
There are some shaders that can mimick procedural textures, like the multilayer ones. You assign a diffuse map and with the help of a mask texture you can let the game know which tileable texture to use on which parts of that diffuse map. It's extensively explained in this post and the thread linked inside: https://www.assettocorsa.net/forum/index.php?threads/boujma-race-track.26681/#post-549151

Or: https://www.assettocorsa.net/forum/...k-materials-shaders.10174/page-35#post-478923
Or: https://www.assettocorsa.net/forum/...ack-making-plus-tips.27180/page-2#post-596213
Or: https://www.assettocorsa.net/forum/...k-materials-shaders.10174/page-37#post-497112 (example for terrain)

But sometimes it's best to just try out stuff and see where it takes you :) (or use CM's object inspector to get an idea how other tracks use it).
 
I've come up with another problem. I was adding road barriers at the sides of the road, and it turns out that they have too many vertices. Here's how it looks:


I used 1 basic building block and arrayed it 2513 times. KSEditor says it has 120624 vertices and won't be loaded. But I was thinking since the roads are curved more segments for the divider would be better. Does anyone know what level of segment reduction is best? i.e. how much can we lower the complexity without noticing the detail has gone low-res?
 
Last edited:
You don't want objects like that to be one object. Seperate them so parts of them can be culled by the game engine, and set LOD distances to prevent rendering when you're not close. The import limit is 65k and you don't really want to be anywhere close to it for performance's sake. Be sure to set the shading type to smooth and use "sharp edges" where nessecary, or the vertex count is going through the roof.
Array-ing is definately the way to go, but for export you might want to apply it and cut it into pieces. Or have multiple array objects (say, 200 pieces) and offset each next one with "200×length of piece"

Also, visual and physical meshes should always be separated. By that I mean: a concrete barrier looks great with all its detail, but it horrible for physics calculations. So we tend to make a vertical plane and tell the game "this is where the car bumps in to".
2021-10-18 08_15_21-Window.png

The simple mesh is called "1WALL.004b" (making it a physical object), the barrier itself is called "barrier_pitlane_low" (without the number in front (or with 0) it is non-collidable).
For physical meshes it's also preferable to have them not too big. Sections of 200 m at most is a good starting point.
 
You don't want objects like that to be one object. Seperate them so parts of them can be culled by the game engine, and set LOD distances to prevent rendering when you're not close. The import limit is 65k and you don't really want to be anywhere close to it for performance's sake. Be sure to set the shading type to smooth and use "sharp edges" where nessecary, or the vertex count is going through the roof.
Array-ing is definately the way to go, but for export you might want to apply it and cut it into pieces. Or have multiple array objects (say, 200 pieces) and offset each next one with "200×length of piece"

Also, visual and physical meshes should always be separated. By that I mean: a concrete barrier looks great with all its detail, but it horrible for physics calculations. So we tend to make a vertical plane and tell the game "this is where the car bumps in to".
View attachment 511102
The simple mesh is called "1WALL.004b" (making it a physical object), the barrier itself is called "barrier_pitlane_low" (without the number in front (or with 0) it is non-collidable).
For physical meshes it's also preferable to have them not too big. Sections of 200 m at most is a good starting point.


Thanks, I read these tips in other threads too. For now, since I'm doing a working copy, I don't want to apply the modifiers just yet as I need to modify the layouts quite a bit. But in the production copy, I will. Same for separating the complex objects into smaller groups, I'll need to think about how to do it.

Also definitely noted about enclosing the shapes in a bounding box for collision detection. I'll do that when the road layout is finalized. At present there's no collision detection anywhere.

For now, for anyone who's keen, you can try out the basic track. I've added some elevation and road dividers but still a long way to go. Just drop the folder into your \AC\content\tracks folder. Start from the starting line in practice mode.

[updated with lighter road texture]


I have this feeling the buildings are a bit too small.. the export scale factor I used was 0.01. However when I tried export scaling to 0.05 or even just 0.02 to enlarge them a bit, the old problem comes back - the car keeps spinning in mid-air and never stops spinning. Very odd.
 
Last edited:
I have this feeling the buildings are a bit too small.. the export scale factor I used was 0.01. However when I tried export scaling to 0.05 or even just 0.02 to enlarge them a bit, the old problem comes back - the car keeps spinning in mid-air and never stops spinning. Very odd.
Judging by the Marina Bay Sands: ingame it measures around 200 m; it's 194 m according to Wikipedia. I'd say the scale is right :)

Little tip: brighten up your asphalt; it's really dark which makes it hard to see where you're going.
 
Thanks for the insight.. I was trying to build the geometry around ground level of the skyscrapers and it just felt off.. like my bus stops were oversized and the buildings were too small.. but if it's really close enough then it's fine. I've changed the road texture.

I noticed that as I drive down the curved bend leading to the Sands building, as I descend sometimes the car goes flying. Very odd.
 
I guess I can finally start creating the tunnel area.

Does anyone know how to reduce the light in a specific area, and how to turn objects into lights? Is there any preferred way to do this?
 
Lighting is handled by a material's "ksDiffuse" and "ksAmbient" values; where the ksAmbient determines the brightness when the material is in shade, and the ksDiffuse for when it's in the sun.
So whereever you want it to be truly dark, the ksAmbient value should be low enough to be able to get that dark. But with the lack of global illumination, if you go too dark you won't get nice looking results (i.e. anything out in the open will become way too dark once some shadow hits it, whereas in real life it's still recieving some light due to the bouncing around of light from other surfaces).

To get the lights themselfs, the CSP wiki provides most information: https://github.com/ac-custom-shaders-patch/acc-extension-config/wiki/Tracks-–-Lights
Or else any track that has lights, you can look at the ext_config.ini and at ingame object names and such (with the object inspector).

I noticed that as I drive down the curved bend leading to the Sands building, as I descend sometimes the car goes flying. Very odd.
Is that at the junction with one of the roads? The road going off is sticking through the other road, creating a ramp.
If it's at the hill going down: the slope is a bit steep. With fast enough cars you'll get airtime and with enough air underneath a car it's basically a wing and creates lift, making the airtime only bigger :p
 
Sorry, I don't understand.

Does AC have some means to detect if a region is blocked from light (e.g. a tunnel that has a canopy blocking off direct overhead light? So all we need to do is create an enclosed canopy and everything inside will assume the ksambient value?

I did a new build with the tunnel region but it's very bright inside, so I don't know the problem. I did create an extension folder and add in the lights portion, assigning it to 2 meshes, but I didn't give any lighting values. Is that why the tunnel is so bright?

Folder is here for anyone who wants to take a look.

 
Last edited:
The way to block light is as in real life basically. As long as your tunnel has a roof, this will block the light from the sun.
2021_10_20_14_42_04_Assetto_Corsa.jpg

For your light series to work, be sure to not forget the _ in front of the ... .
2021_10_20_14_53_47_Assetto_Corsa.jpg


You can also add them one by one by doing something like this inside the ext_config:
Code:
[LIGHT_...]
ACTIVE=1
POSITION = -80.8, -26.7, 1037 ;X,Z,-Y
DIRECTION = 0, -1, 0
CONDITION=ONE
CLUSTER_THRESHOLD=25
COLOR=220,236,224,0.05
DIFFUSE_CONCENTRATION=0.500
FADE_AT=500.0
FADE_SMOOTH=200.0
OFFSET=0,-3,0
RANGE=250
RANGE_GRADIENT_OFFSET=0.1
SINGLE_FREQUENCY=0
SPECULAR_MULT=0.25
SPOT=175.00
SPOT_SHARPNESS=.8

And it will look like this (all depending on the input, can be changed real time):
2021_10_20_14_50_56_Assetto_Corsa.jpg
 
Thank you, turns out I forgot the _.

For my building material (e.g. skyscrapers, tunnel walls) I set my ksambient to a value lower than the ksdiffuse, and I didn't alter the default ksdiffuse values.

The problem is, in the tunnel the walls are dark but the skyscrapers also became very dark even though they're in the sun. I thought when they're under the sun they'd take on the ksdiffuse value?

I'm also puzzled because I've placed a canopy over the tunnel but some areas are very brightly lit (even when there's no light and the canopy is there) and some areas dark. I'll have to explore this further.



This is how the tunnel looks now:

1634813238241.png



This is what I'm trying to achieve.

1634813347370.png



Right now there's the light_series pattern that looks too obvious, and I want to have a uniform yellow tint in the tunnel.
Should I change the material to something with a yellow tint? Or can I turn the grey concrete uniformly yelllow (rather than in a spotlight pattern) through the use of CSP lights?
 
You could try:
Code:
[LIGHT_SERIES_...]
MESHES = Cube.278, Cube.551
COLOR=255,255,100,0.025
SPOT=210.00
The SPOT defines an angle for a spotlight. Set this to larger than 180 to illuminate the roof as well. Resulting:
2021_10_21_13_30_33_Window.jpg


Add
Code:
FADE_AT=2000.0
to prevent lights from jumping into sight. 2 km is insane, but with long tunnels you might have to. With anything less it shows (I just tried), anything more is not doing anything it seems :p



I wouldn't worry about diffuse values that much yet. Once you've done all the texturing work, you need to tweak those values anyway.
 
Last edited:

Latest News

How long have you been simracing

  • < 1 year

    Votes: 230 14.7%
  • < 2 years

    Votes: 159 10.2%
  • < 3 years

    Votes: 156 10.0%
  • < 4 years

    Votes: 117 7.5%
  • < 5 years

    Votes: 223 14.3%
  • < 10 years

    Votes: 186 11.9%
  • < 15 years

    Votes: 123 7.9%
  • < 20 years

    Votes: 87 5.6%
  • < 25 years

    Votes: 70 4.5%
  • Ok, I am a dinosaur

    Votes: 213 13.6%
Back
Top