RELEASED-wip Vallée du Parc 2020 0.5

[maruto]

maruto submitted a new resource:

Vallée du Parc 2020 - Short custom bumpy countryside Track

Welcome to Vallée du Parc. A quiet ski resort located in Shawinigan, QC, Canada. I imagined the place to be invaded by a local race club with almost no budget for a summer... using mainly old tractor tyres for protection. This track is based on a real road, but this is pure fiction.

This is a very short bumpy tricky track, very fun with small cars like the Ford escort RS1600 or the Skoda RS 130.

It has 20 pits layout and AI for both reverse and normal.
I rented some Wanco light generator...

Read more about this resource...

 

[luchian]

I just love to see projects like this popping up out of the blue . It's really the purpose of this site. And from photos (did not try it yet) it looks awesome for a first track. Actually, for any n-th try. Keep it up, hope to test it soon.

 

[maruto]

hello, I want to work again on my track but i'm a little stuck because I don't know how to proceed... my main concern is that i feel i did something wrong but i cant put the finger on it...

The DIP is quite high for such a small track, on a simple screen 1980x1080 i'm between 1200-1600, when i compare to the track Deepforest, which is far more complex with a lot more details, materials, etc with the same car/grassfx settings, the DIP goes around 600-1000...

before I was even higher above 3000-4000 sometimes and it lagged and every time i changed a something in my 3D model, importing the fbx in kseditor took hours and I was going crazy...

So i started optimized everything, starting with the workflow.

Rhino ==> .fbx ==> kseditor ==>.kn5

When i started this project, I had one fbx file for the whole track, that was getting bigger and bigger and took a lot of time to export and to load into kseditor. the most frustrating part was when everything opens black again and i had to retexture everything... I did it many many times.

until i found out you can split your .kn5 simply by using the model.ini file(3)

Now i export separate fbx files for every different parts of the track: the track itself with it's roadside, the landscape, the cones, the lampost, the trees, etc... every .FBX files is in it's own directory with it's own texture directory. so there are few textures in each this way I don't get lost and it is so much easier. the exports take seconds and the loading time in kseditor is greatly reduced. and when it won't load, i know there is a problem and i know what part of the track is causing the problem.

another advantage is to make variant very easily loading different combinasons of .kn5 in the models.ini file swithching them on an off using ;; in front of a line.

Using this method, I checked the DIP for the track alone with the landscape: already around 700....

is it high? I think it is because when i add the trees and treelines it is already beteween 1000-1200

this is really frustrating because i did everything I've found these threads : (1,2, ) many times I reduced the polygon count for the track, created separate invisible physical mesh, splitting the mesh into 400m segments, splitting the landscape into segment also... Well it helped me a lot, it drasticaly reduced the DIP to an acceptable level, but it is still high and i don't understand why...

The total polygon count for the whole track with trees and flowers and tyres ans lightning tower is around 1 090 190 triangular polygons...

the whole basic setup including the track, the roadside, the white\yellow lines, the field and the landscape has only 238 512 total triangular polygons... The track has still low poly i would like to increase the density of the physical mesh but i'm afraid that it will increase the DIP also...

this use only less than 10 materials:
one NULL.DDS for the phys
one multilayer for the road, (religiously following theses great advices (4)
one multilayer for the roadside only to have the same gravel color at the junction,
one for the yellow line, (ksPerPixelAT blend mode alphatest)
one for the white lines (ksPerPixelAT blend mode alphatest)
one for the pit, (ksPerPixelNM)
one for the sarting line, ksperpixel
one for the fields
one googleaerial map for the surrounding

I don't understand!!



thanks for any advices

Martin

 

[maruto]

I also have another question, I noticed that some tracks put their CSP extension.ini in their track directory in /extension in a file named ext_config.ini

is it different than the file normaly putted in .../assettocorsa /extension/config/tracks/loaded ?

does it override it?

 

[fughettaboutit]

extension\ext_config.ini
has priority, yes, the only difference is - well, the place, so a trackmaker could just offer a track without any extra folders

About your higher density physical mesh, thats exactly what you want, at least for the road. you can make it as detailed as you want, and in ksEditor you set Renderable to false:

make those invisible physical road parts not longer than 1km and not having more than 30.000 vertices.

 

[fughettaboutit]

your track looks pretty good already, maybe work with LOD_OUT values for optimization, set to like 300 for very small objects, 500 for skidmarks or larger objects, higher for large things and tree-walls

 

[fughettaboutit]

oh and think about making one invisble wall too, with normals pointing towards the track , using complicated objects as 1walls... makes them sticky or not working properly

 

[fughettaboutit]

oh and this is actually the wrong way around, mesh-name needs to be 1GRAVEL_side12
material name doesn't matter for physics-collider

 

[fughettaboutit]

actually only your tyre-walls are normal-flipped, maybe only change that

 

[maruto]

it feels good to know someone has answers!!!

(but it brings more questions.....)


yeah, effectively my tyre wall's normals are facing the wrong way, didnt pay attention to it when i did my initial block....

i made a block with a simili low res mesh for the tyres stack with a another simple cylinder of a slightly smaller diameter inside, that cylinder mesh is named 1wall.... (i wanted to simulate the tyre not beeing like concrete but when hitted, the car goes a little deeper than the surface of the visual mesh)...the visual mesh has no name but is in a different layer.

then i sprayed this block all over, exploded it and separated them to be on a black or white layer with different materials, then i selected all the simple cylinder and joined them by section, removing as much unnecesary faces not facing the track, this way i could rapidly get a small physical mesh corresponding to the visual mesh.

but i didn't check the normals.

i'll flip them i think it will remove this weird behavior of getting stuck in it... thanks now i understand

 

[maruto]

oh and this is actually the wrong way around, mesh-name needs to be 1GRAVEL_side12
material name doesn't matter for physics-collider

View attachment 5434

yeah this is a mistake, most of this track has been made with trial and errors, i might have tried to use the 1GRAVEL on the roadside material on one model and forgot to rename it.... i like it better with 1SAND that i use on the physical mesh of the roadside, it is so cool to see the dust when cutting the barn corner

 

[maruto]

extension\ext_config.ini
has priority, yes, the only difference is - well, the place, so a trackmaker could just offer a track without any extra folders

About your higher density physical mesh, thats exactly what you want, at least for the road. you can make it as detailed as you want, and in ksEditor you set Renderable to false:
View attachment 5433

make those invisible physical road parts not longer than 1km and not having more than 30.000 vertices.

that's what i did, but for now the physical and visual mesh are duplicates... and are quite low poly, i think i have a vertex every 1.7m.... I wrote a script in grasshopper to move every vertex in a random direction (+-2cm) and it feels already bumpy but i want to try increassing the vertex count for the physical mesh....

So around 30.000 vertex is a good number for a road segment? I have read somewere to cut it every 400m...so that's what i did... those segment have actually around 1200 vertices... wich is far from 30.000... is it better to aim at longer count? like 20.000 for example?

Do both physical and visual needs to be cutted? I splitted both.

I imagine my physical will have shorter segment if i increase the density.

...


thanks for the answer on the location of the config file, it is much cleaner to keep it inside the track directory, i'll do it too.

 

[maruto]

your track looks pretty good already, maybe work with LOD_OUT values for optimization, set to like 300 for very small objects, 500 for skidmarks or larger objects, higher for large things and tree-walls

I haven't looked out yet for what exactly are LODS
but i think i get the idea of less defined objects for far distance, but i don't know if you have to make all of those and supperpose them and give them different attributes or if AC does it by itself, I need to read about it, i haven't yet, as for how skidmarks and groove are done.... didn't know even this concept was applied to trees... does it also aply to the track?

no need to answer all those questions, i can look out for myself too, but thanks for those reference number, it will make me gain time of trials and error

 

[fughettaboutit]

When using LOD_OUT without any self-made lod's, its simply to hide the object at a distance, which in turn increases performance

About the invisible road mesh tri count: if you have not as many poly's per meter, you can go up with the length of the road-part, only if you really have as much as ~30k, you should divide more

For comparsion, this picture is the first corner into green hell of ks_nordschleife, so compared to your mesh you have less variation and detail and can still go way up

see this to add micro-bumps and longer stretched bumps:
https://assettocorsamods.net/threads/road-how-to-physical-and-visual-layer.996/

 

[fughettaboutit]

Visual road can be completly on its own, you dont have to cut it down so much into pieces, if vertex-count (or tris?) is under 65k (yes another number , somehow its different for dense meshes with lots of random verts like a road-mesh)

i mean if you can, keep as less objects as you can, join as many as you can (maybe based on same material), helps to keep object count down, which is DIP in Render-Stats app, its very important, if not more important than tri-count

ac easily can handle 5 million tris in a scene, if it then would be only 10 objects (DIP) then performance would be like 200fps

 

[maruto]

Can't wait to get back at it, can you tell me where are those LOD_OUT parameters?

I understand now that is is better to keep the number of object low so i'll split my big visual object so that they don't exceed 65k and split the physical mesh to 30k segments.

I don't use blender so i have to find another way to create nice irregular surface with my tools (rhino and grasshopper), and find those magical number to have that smooth bumpy road.

I understood lilsky's way of using two different wave lenght to have long bumps and smaller local bumps, I will try to apply these concept in a different way...

Grasshopper is really powerful, starting with a simple planar surface i can divide it in precise amount of row and columns and play with those vertices individualy... that way i control camber and bumpyness... and it will affect the roadside also because everything is interconnected....

here is an example: i tried to remove the linearity between the road and troadside mesh by simply randomly disrupting the vertice on the edges...(moved them with a indidual random number between 20 an -20 cm in X and Y axis) and then the roadside surface has been divided into 4 row and i reduced the number of vertice by 2 every row to reduce the total amount of poly...

still has to be refined but you get the idea....

the negative side is tt you have to find te magic numbers that works well and the only way i found is to try and drive and retry and drive and so on

I'll use your nords example as a reference to find the correct density.

btw, is there any tools to open .kn5 files other than simed? I used it when i started my track to dissect tracks simply to understand how a track is made of and it helped me a lot, but now my 20 days license is expired... so i fly around in AC with the camera to explore tracks, but you can't see what is invisible

 

[fughettaboutit]

nice to see you put some effort in it

kn5unpack https://drive.google.com/file/d/0B6GfX1zRa8pORVhibl8tODlicmM
-generates a "persistence file" too, so it would be FIRST choice
-it scales everything by 100, scale down on or after import in Blender by 0.01

source: http://forum.simracing.su/topic/3205-redaktirovanie-trass-assetto-corsa/

also in dev mode of ContentManager and with full application integration, if you double click a kn5 and quickly hold ALT key pressed, CM will unpack the track in its folder...

 

[fughettaboutit]

lod_out params in ksEditor in object tab

or in the .fbx.ini (Persistence file)
generated by:

 

[maruto]

This AC comnunity deserves effort to be put in!!!

I've never seen anything like that, I love it. Content manager is a game changer also, to me AC is not a game anymore, it's an encyclopedia, it's an apology to freedom, it's a gift made by thousand hands.... don't know how to describe it, but it is big.

I've got me the full CM, but didn't know there's a dev mode to it.... i'll explore that... thank you so much!

 

[maruto]

lod_out params in ksEditor in object tab
View attachment 5443
or in the .fbx.ini (Persistence file)
generated by:
View attachment 5444

View attachment 5445

ok i get it:
if you do multiple version of one object, with this variable you can control wich one is seen from a certain distance?

let's say you have three:

one detailled poly:
LOD_IN=0
LOD_OUT=100

one little less detailled
LOD_IN=100
LOD_OUT=300

one very low poly
LOD_IN=300
LOD_OUT=500

when car is in a 100m radius it will show detailled one, from 100 to 200 second one, from 300 to 500 the third... and above 500m, no poly at all....

am i right?