Atzara Track

[QuadCoreMax]

Hey all,

I've been working so much for Racer, so here's the last track of mine !
Hope you like it !!

Features :

- Crazy amount of rocks/trees/bushes
- Alpha Textures custom build
- BTB + CSV Real Road Curvature Extraction GE
- AI Spline for Racing up to 10 cars
- Accurate 13 polies collision trees => my invention as described recently
- Movables Cones
- TOD
- Bumps for Dave
- Multiple Surfaces definition
- etc...

Tested with G25 & Qlog debugged with Racer 0.8.39 version.

********************************************************************
Please consider donating as it take lots of time to develop
********************************************************************​

Racer-Max - Free Tracks & Cars For Racer Simulator

​

​

Atzara Track Download

 

[Alexander Knoll]

WoW...THX QCM! Looks and feels great!





...my best time was a 1:59.2....^^

 

[QuadCoreMax]

Thanks Alex !

Be careful on the last curve, it's a tricky one, you need to align your car in the middle of the road to avoid loosing sudden control...

 

[Alexander Knoll]

yep, THX i know^^ (had already some faults) nice Track!

 

[AMGfan(BPM)]

Great track man! Really funny to drive on it.

 

[boomer541]

Very similar to avernaz track, get about 30 fps. Good track, QCM. I made an ai run with the Imp and no violent oscillations like avernaz track. will try it with your default ai also.

 

[Mr Whippy]

I just don't get why stuff runs soooo slowly.

It's just not really playable properly. Put a few cars on there and it's sub 15fps...

With Cam's F458 (beta) on interior view it's about 11fps here


Also rolled it in one bend... is the grip factor of 1.35 a bit too high maybe?



Generally, technically, the shaders/textures/build seem good, so it's frustrating that it runs so badly...

I swear it's newton related, despite the 'physics' CPU load being low, I just think it's newton...



This is my frustration right now. 0.8.34 can look great, but the FPS are unusable... this track simply shouldn't be costing that much FPS... Shift2 here runs at 60fps in a higher res with much more detail going on! I can't believe that our shader system is 10x less efficient... something is costing us big time somewhere!?


Lastly, I'm getting ** OVERRUN DETECTED ** flashing at the top of my screen at times during play... anyone else?

Dave

 

[Mr Whippy]

More testing...

Started track.

C key.

Watching from track camera.

FPS are about 7, then after a while get to say 17fps...

'reload track'

6 ish, then up to 17fps ish

'reload track'

5 ish, then up to about 30fps, wow...

'reload track'

4 ish, then up to about 15fps

'reload track'

3 ish then up to about 10fps

'reload track'

2 ish then up to about 7fps

'reload track'

same as above consistently, maybe dropping slowly still...


Something REALLY odd is going on with newton/racer track initialisation. I can 'hear' something dropping each time I do it, like cones falling over... (we have 60 movables on this track)

Removing the flags on the cones seems to get me about 20% more fps...

However, now I've removed the flags to 0 for the cones, 'reload track' crashes Racer hahaha!



As said, I'd tinkered with Racer lots and lots and lots over the last decade, and I'm pretty sure this 'feels' like it's a Newton problem through and through and through... Newton and track loading... time to pester Ruud


Dave

 

[Mr Whippy]

Then again, looking at CTRL6 debug screen and the amount of gfx calls, it seems maybe every DOF gets called.

So it might be better to have ALL trees that share the same shader in ONE big DOF... that way it gets called and rendered in one pass for example.

So in theory you want as many materials that share common properties to share the same texture (ie, a 2048x2048 atlas for all asphalt), and then have ALL objects that use that single tex/shader in one DOF... can probably keep them split in authoring package, but select and go to ASE > DOF (which seems to have many geob in one dof?)


No idea really.

QCM, do you mind trying that? Group your current tree textures into one atlas, adjust UVW appropriately, and then combine ALL the trees into one DOF?

Just see if it makes any difference?


I'm just testing on my old Dunsfold track quickly, and I have thousands of trees all around the edge of the track, yet my FPS there is 120fps...

Just trying out a few tracks and

FPS ~ render calls... and render calls seem to be a combo of dof * shader, so 1000 tree DOF's using the SAME shader is still 1000 render calls!


Dave

 

[camsinny]

Then again, looking at CTRL6 debug screen and the amount of gfx calls, it seems maybe every DOF gets called.

So it might be better to have ALL trees that share the same shader in ONE big DOF... that way it gets called and rendered in one pass for example.

So in theory you want as many materials that share common properties to share the same texture (ie, a 2048x2048 atlas for all asphalt), and then have ALL objects that use that single tex/shader in one DOF... can probably keep them split in authoring package, but select and go to ASE > DOF (which seems to have many geob in one dof?)


No idea really.

QCM, do you mind trying that? Group your current tree textures into one atlas, adjust UVW appropriately, and then combine ALL the trees into one DOF?

Just see if it makes any difference?


I'm just testing on my old Dunsfold track quickly, and I have thousands of trees all around the edge of the track, yet my FPS there is 120fps...

Just trying out a few tracks and

FPS ~ render calls... and render calls seem to be a combo of dof * shader, so 1000 tree DOF's using the SAME shader is still 1000 render calls!


Dave

I've not tried this track yet, might tonight...But yes, consolidate the trees to lower batches, batches are polygons*material basically.
Say you have 100 trees, assuming each tree is one material (x-tree for example) you have 100 batches. Add more detail to the tree, no more materials - still 100 batches, even though they might be 1000 polies. Apply a material to 500 of those polies as a trunk and branches and suddenly you have 200 batches. Merge all those trees together and then you have 2.

Batches make a big difference in how a scene runs, so try to keep them as low as possible.

Note though that I'm not sure how Ruud's view culling works, if it's based on pivot point then you may want to not bunch all the trees into one object as that will mean they're pop out of view when you're looking away from the pivot.

 

[DavidI]

...Note though that I'm not sure how Ruud's view culling works, if it's based on pivot point then you may want to not bunch all the trees into one object as that will mean they're pop out of view when you're looking away from the pivot.

This is exactly what happens, well it used to anyway. Working on Mugello I made a lot of the similar objects like fences all one object to make it easier to work on mainly. I'd find that in game parts of barriers would be missing/culled that shouldn't have been. Haven't noticed that happening recently, but then maybe I split the objects up a bit.

 

[Alexander Knoll]

@Dave
hmm..i tested this group thing...i put ~400 objects in to one DOF...no shader changes...and i got 1 fps+....next test i use one shader for the big DOF...

EDIT:
hmm....ok it's LoL...with one big DOF and one shader call (4096x4096 Texture) the fps is +/- 0,5 the same...but the CPU% graphics (strg+6) is ~30% less...i try it with a smaler texture too...

EDIT1:
hmm... if i use one big DOF and one shader with a texture 2048x2048 i'm back to the same as i use the 400 small DOFs with theyr shaders...

EDIT2:
Sry for the OT QCM!
ok back...öhm...if i hit one of the movables i get a fps + from 3fps^^ loool after i hit a second, again...3fps+ ^^ it's verry funny....

 

[boomer541]

Tried ai "default.ini" file and ran quite good with Imp, just a few oscillations until starting lap 2. Then spin out. added global, velocity=0.95 to top of default.ini and it still had bad oscillations on second lap. Other cars run ok, real bummer!

 

[Mr Whippy]

This is exactly what happens, well it used to anyway. Working on Mugello I made a lot of the similar objects like fences all one object to make it easier to work on mainly. I'd find that in game parts of barriers would be missing/culled that shouldn't have been. Haven't noticed that happening recently, but then maybe I split the objects up a bit.

It'd be an issue with LOD's, since LOD's use the pivot point.

But I've got terrain ALL around my track for 10km in all directions, and you can see it all, all the time. It's culled in the lower level of the rendering pipeline now I think, so you don't need to worry about it.
I did some testing about a year ago I think... no difference in speed.

I basically cut out all the terrain I knew I couldn't see behind the car, 125fps or so.
I then put that terrain back in (10k polys or so + texture etc), and still had 125fps...
Also split it along the cut out so it was a separate object which could be turned off, still the same speed.

Yet when I spun the camera round, it was all there still in any case.


I'd just like to know the best way to do stuff.

I'm sure Racer is still slower than it should be for some big reason. Maybe the CSM is really costly... I see about 3x more fps turning it off... but even those frame rates feel slow considering what is on screen.

Dave

 

[DavidI]

I've had the suspicion for a while it's something to do with interactions between certain shader combinations, but never found any hard evidence. Looking in certain directions in certain places on Mugello, the framerate drops dramatically, but changing the camera angle and/or moving the car/camera position while looking at the same general scene improves the framerates. Maybe its something to do with distance to certain shaders, or combinations in a scene.

 

[Mr Whippy]

Hmmm, alpha to coverage seems to be costly if the objects that are overlapping are in separate dof objects...

Need to do more testing but it just takes a while to build the tests

Dave

 

[DavidI]

Hmmm, alpha to coverage seems to be costly if the objects that are overlapping are in separate dof objects...

I think you're onto something there, but from my mucking around with Mugello, I'd expand on that and say it is when there are multiple overlapping materials in a scene using alpha2coverage, maybe the amount of objects is also a factor. I've not tested this, but it fits with the spots on Mugello I get poor fps on in certain view directions. I've got a heck of a lot of modelled (not x-trees) trees as seperate objects on Mugello, framerates are reasonable except in certain places on the track AND when looking in certain directions the framerate slides.

 

[QuadCoreMax]

Maybe some1 should try to Gdebugg (Gdebugger/GlsDevil) it, I think it's a combination of non optimized algorithms. The fact is when using multi-layered shaders as the bump shader, that has implicitly some more impact on the fps rate. Does anyone tried just to replace all shaders with standard & only 1 layer ?

Too bad, we aren't getting any feedbacks from Ruud/Mitch, I suppose they now the truth, but the whole system seems more complicated to fix it & that doesn't surprise me, because it would need some deep changes in the C++ code & the openGL profiles...

Compare to Shift 2, we theoretically could do a lot better, but let's say, we better be patient, as we all know, things change at a drastic rate now & all kinds of new technological discoveries are making things harder to figure out...

 

[DavidI]

There's not even racer.nl documentation atm... it's been down most of the weekend

 

[Mr Whippy]

DavidI, I agree that it might be transparency related, specifically alpha to coverage.

I've not done any specific testing yet, but try just make all things using an alpha to coverage a standard material (no alpha) and see what happens...

It may well be that A2C has to be checked on each 'group', so if you have many elements behind an A2C, then it'll be more costly than having less groups that are rendered in one pass!?

So lots of trees with different shaders overlapping is gonna be really expensive!?


All that said, the movables are still a bit iffy point for me. Cosmo and I have had some really weird behaviours with them.

On my development airfield, if I have 300 movable cones, I get about 4fps at load, if I then 'reload track' I get about 60-70fps... I used to not have to do a reload for it to work ok, while Cosmo ALWAYS had that issue, it never ran fast.
Then sometimes 'reload track' would crash it.

Even though physics is saying a fairly low figure in the debug readout, I don't think that includes Newton stuff, just the Racer physics itself...

I think Newton is initialising badly and just hogging resources... lots of them!

Just look at the FPS go up on this track if you set flags=1024 > flags=0


Dave