TUTORIAL Build your FIRST track - BASIC GUIDE

[Pixelchaser]

looks like you have that orientation problem in the last pic.. your green arrow needs to point up and the red points the direction you spawn in. From default orientation we flip on the x 90 degrees to get that green going up.

 

[DrPenguin]

So I pulled in the objects from the working cut and I'm still having the same thing, both with where the camera is in the pre-drive screen and what happens when you click drive. I also used Set Origin to Geometry on the spawn objects before saving and exporting to FBX.

Pixelchaser, when I rotate the objects the coloured points don't move, just the letter. I've tried them with Z pointing out of the pits and pointing back towards pit entrance, wtih Y up on both as Luchian showed in the troubleshooting post on the first page of this topic. Same results. I've also tried with the objects both render-able and non render-able in ksEditor to the same result.

I've attached a screen from ksEditor- this is how the track loads into the editor and where the camera sits when the map loads before driving.

 

[fughettaboutit]

"Set Origin to Geometry"
in Blender unfortunately sometimes you need to use this two or three times until it actually sets it correctly
in 2.8 you can select all the AC_... objects at once and do it 3 times... but maybe its still something else

 

[LilSKi]

All about spawn points and getting the track in game.

 

[Prototype]

All about spawn points and getting the track in game.

You knocking these things out now! I cant watch them fast enough without new episodes coming out

 

[DrPenguin]

Thanks Lilski!

 

[LilSKi]

You knocking these things out now! I cant watch them fast enough without new episodes coming out

I was comfortable in my rig doing the recording session so I just banged out the 3 episodes at once. Not sure I will continue that pace from here on out but the process is pretty efficient from recording to posting so it saves me lots of time.

 

[Tomaszeqq]

Hello which way is the best for make white lines on roads If I trying to make a part of my city ?

 

[fughettaboutit]

roadlines, "BlendMode" could also be alphaBlend, not sure:

--------------------------------------------------------------------------------------

another topic, these are restrictions for names of track- and car-folders, from x4fab and/or shared memory definitions:

max length for track (folder-)name: 32
max length for additional layout (folder-)name: 15
max length for car (folder-)name: 32

all lowercase, latin-digits-underscore, NO utf8- or fancy characters like é or something

@luchian maybe you can put this in the first post? [edit: Done]

 

[Tomaszeqq]

Another thing. How can I receive paving sound effect on paving surface?

 

[fughettaboutit]

; default sounds available to use in "surfaces.ini" - from "steamapps\common\assettocorsa\content\sfx\GUIDs.txt"

; WAV=kerb.wav | grass.wav | extraturf.wav | sand.wav | gravel.wav | old.wav | tyre_rolling.wav

never tested this, but maybe you can insert you own sounds by using a "sfx" folder in your track folder and put a .wav file there, but again: I never tested this by myself, but i found these tracks to have tried it:

 

[Tomaszeqq]

Ok I will try. Thanks

 

[Aureliano Buendia]

nervermind

 

[Pingypoker]

Hey everyone! I'm having issues with my first track. I followed this tutorial to import LIDAR mesh into Blender.

My problem is that cars are falling through the track surface. It seems the further away I drive from the origin, the more unstable the car becomes, eventually falling through.

This is what the road mesh looks like. 63,000 verts. Around 1000m x 1000m. Named 1ROAD_0

These are my export settings:

I'm really having trouble figuring this out. Cars drive perfectly where they spawn, but once it leaves a certain point it has issues. Everything seems to be in order with the mesh. Please help!

 

[fughettaboutit]

its too big, divide into 20k, 24k or 32k parts
1ROAD_1
1ROAD_2
...

or normal-direction is wrong

 

[Pingypoker]

its too big, divide into 20k, 24k or 32k parts
1ROAD_1
1ROAD_2
...

or normal-direction is wrong

Dividing the mesh seemed to do the trick. This is odd to me. I have not read anything about a physical layer having too many polys. For example, in this thread about the importance of highly detailed driving surfaces, there is no mention of the driving surface needing to be any lower than the usual 65k vert limit. Is there anywhere I can read more about this? This seems like something that would be important to mention, however I can not find discussion about it anywhere...

 

[fughettaboutit]

I know, they say 64k everywhere, but i found out the hard way like you, that espacially for road-meshes - 32k or lower is needed. Oh and also one roadpart should not be longer than 1km.

For only visual meshes its not that important, it can go up to 64k

 

[Pingypoker]

I know, they say 64k everywhere, but i found out the hard way like you, that espacially for road-meshes - 32k or lower is needed. Oh and also one roadpart should not be longer than 1km.

For only visual meshes its not that important, it can go up to 64k

Usually I can Google my way out of problems, not this time! I had been frustratingly trying to figure this out for hours. Glad I posted here. Thank you so much!

 

[luchian]

Dividing the mesh seemed to do the trick. This is odd to me. I have not read anything about a physical layer having too many polys. For example, in this thread about the importance of highly detailed driving surfaces, there is no mention of the driving surface needing to be any lower than the usual 65k vert limit. Is there anywhere I can read more about this? This seems like something that would be important to mention, however I can not find discussion about it anywhere...

The "trick" is that the 65k is limit is not about verts, but about "values" (as named by Si3v, the Lead track designer at Kunos). And "values" include any piece of data that a mesh can have (coordinates, UV mapping, and what not - I would not know to name them all .

It is true that this info might be missing from first post (I'll check in detail), but it has been mentioned a couple of times otherwise.. here, there, here, there, here. Anyhoo - one more, does not hurt . Good luck with the project, sorry you've lost time.. (ask the guys how come they "know" tho )

 

[Pingypoker]

The "trick" is that the 65k is limit is not about verts, but about "values" (as named by Si3v, the Lead track designer at Kunos). And "values" include any piece of data that a mesh can have (coordinates, UV mapping, and what not - I would not know to name them all .

It is true that this info might be missing from first post (I'll check in detail), but it has been mentioned a couple of times otherwise.. here, there, here, there, here. Anyhoo - one more, does not hurt . Good luck with the project, sorry you've lost time.. (ask the guys how come they "know" tho )

That makes sense. Are you suggesting that the reason my original mesh was causing problems is because it has a value that exceeded the limit? If that is the case, I would rather figure out which value that might be and address it, instead of splitting apart the mesh. Or do you agree with fughettaboutit that, for some mysterious reason, a driving surface needs to be below 32k values?