1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Avernaz Track

Discussion in 'Racer Tracks' started by QuadCoreMax, Aug 4, 2011.

  1. Hey all,

    I've created a cool fast track...

    Track contains :

    - 1 spline for nice AI playing
    - 10 cars available on race
    - 1 smoothed default.ini AI file => type in command 'ai performance .5' if car doesn't follow the 'bestline' (F3) or inverse.
    - track cams with wide radii ~ 150-200m to avoid too many cameras switching when AI playing or replaying.
    - 5 track sounds
    - 4 timelines
    - 1 colorgraded texture tweaked in the Blues Cyans Magentas + Contrast Levels
    - massive aligned xtrees along with their Racer special shader (bushes : 4974, trees med : 1424, trees big : 997)
    - highly smoothed road
    - 1 custom TOD
    - nicely structured track folder
    - all textures converted to dds for max. GPU calculations
    - cool Racer shaders used like mix2, bump
    - track surfaces set => rumbling on kerbs...
    - animated/movables cones manually distributed in Tracked

    Avernaz, the name is a combination of 3 little villages Arpigny, La Verne & Marcellaz situated at 46° 8'56.82"N, 6°20'58.72"E. It was debugged in 0.8.39 with my G25 with CSM & without, surround resolutions included. It's QLOG debugged, you shall have no problems at all playing it. FPS seems to be good on most parts, some kerbs are unfortunately too complex, so you can encounter some 50% fps drop on those places.

    Enjoy it ! :)

    [​IMG]

    [​IMG]

    [​IMG]


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


    [​IMG]

    Avernaz Track Download
     
    Last edited: Sep 17, 2015
    • Like Like x 1
  2. Awesome work, I just downloaded and tested it.
    At first it was a complete whiteout, but that's because my video card has a limited range for the lighting, so I had to put my own TOD curves, and now it looks OK. Although with my TOD, I don't get dawn/dusk colors, just less light. I will try to fiddle with your curves.

    [​IMG]
     
  3. KS95

    KS95
    RACER Moderator

    You get a cookie for driving a GT-Four :)
     
  4. Thanks QCM, good quality work from you, as always..
     
  5. Alexander Knoll

    Alexander Knoll
    NEVER GIVE UP!!

    Hey QCM, the track is a great work!
    But i don't like the road shader....

    [​IMG]

    sry...looks not real....
     
  6. Good job of making a track, QCM, but I have a problem with the kerbs in the first corner after the s/f line when driving over them with my Bugatti Veyron. They are too high and launch the Bugatti into the air. A Bugatti Veyron grond clearance ranges from 4.9 down to 3,5 inches. Mine is at 4.7 inches when hitting the kerbs.

    They are too many small .dof's which could be combined into larger .dof's.

    Other wise fun track but it don't match the "preview" image.
     
  7. Thanks for your feedbacks !

    @Alexander

    The bump map needs to be scaled to get more detail on it, I would use another map or edit the existing one. It's true, at some cam angles, it doesn't look realistic enough. I've tried 'scale=' in the bump shader layer 1 but that doesn't seem to do nothing...

    @boomer

    Those kerbs just after the s/f line are unfortunately too high & too complex to get a proper result when driving on them. I won't model/bake the detail into the kerbs objects anymore, the same can be simulated via surfaces settings in special.ini. I'll fix those kerbs in my custom Xpack, now I remember, it was also scaled uniformly afterward, to 150% in BTB sobjects props with an original height of 10 cm.

    About all the pieces, it was BTB X generated & I just converted to dae files, leaving almost everything untouched. X files are horror when working with larger meshes, as you know, they are per planar face projected & split, so you can easily understand the reasons. Had some serious FPS drops in Maya when trying the other way...

    The preview image doesn't match 'exactly' because it was imported as an csv file (with height data) set to '2' in the Merge BTB Import Dialog Box, so I lost some minor road curvature detail...Next time, I'll put some more effort cleaning the whole route points in GE prior of exporting it as a kmz file...I usually leave this particular work to the BTB Merge function inside the Import box...
     
  8. Thanks for the release - I'm sure there will be more feedback over the weekend and in the coming days too. A new track sure deserves a better view/reply ratio.

    In my opinion there are some very nice aspects to this track, but also things that I didn't quite get or seem like they could be improved.

    The textures are looking pretty nice and fit well together and the overall track layout works quite well too, being fluid to drive and without any hiccup points like harsh steps in the track mesh. It's also supporting a lot of the current Racer features, comes with default AI files as well and has some ambience sounds (wonder how long the animals will stay once regular racing starts XD ). As a whole, the track shows that a sense for detail was present during the creation process.
    Basic things like the clean qlog and a readme file being included are also nice, of course.

    Even though the following list of things might seem to take up more space, I think that's misleading, or at least not intentionally trying to paint it all black - just some thoughts that I had when driving around and looking some of the files.

    When I read that the name was inspired by that particular region in France, I thought you had included the screenshots for your previous track at first :D But turns out it really is just the name, not the landscape. Now that's fine of course, I just found it a bit odd since I expected more of an alpine track with snowy peaks, juicy greens and cold streams.
    According to special.ini, this is actually located on an airfield in the UK - Whippy might have heard of that one ;) - but it looks like the south of Spain or maybe northern Africa to me.

    You mentioned the folder structure, it's well organized but there are some empty and some double folders as well. Perhaps you could have put the mesh files into an .ar archive to reduce the filesize further and get an even cleaner structure overall? If you set the collision flags for all those tree and bush objects to zero, the size of the cache file can be reduced from 11MB to roughly 1Mb, btw - I don't know whether one needs to have collision checks going on all the time for things you'll never touch way out there anyway?

    As I said before, on a macro level, the track layout is fun and flows nicely - maybe some more micro action could enhance the show even further - some bumps, more road crown and so on.
    I don't have any issues with the kerbs in any case, perhaps boomer is driving a car with pacejka.a111 not set to or close to zero?

    The pylons feel pretty heavy, I'd guess being that size they should weigh around 2kg or so? Right now they kind of tend to offer a good bit of resistance and often launch cars into the air (depending on their collision mesh).

    From an artistic point of view, there doesn't seem to be a panorama texture so the track appears to be floating in space to some extent - the fog settings don't manage to hide that fact entirely.

    Some of the xtrees are aligned in such a way that they suddenly appear in sight because one of their flat sides is parallel to the viewing angle in the car, going down the track normally - that takes away a giid chunk of the immersion in my opinion.

    When I saw the mix shaders being used, I kept looking for them on the edges of the tarmac, kerbs etc - now I'm not saying this is the only way to use them properly, but I think it was the original intention, to help blending of adjoining textures that otherwise appear too cleanly cut.

    I mentioned this next bit in the thread for your other track too, I think - there are no perimeter roads, no connection between different parts of the track, no emergency roads, no entrance/exit to the circuit, no pit area, control "tower", marshall posts etc. It's simply a closed loop in the middle of nowhere so to speak. It would greatly add to the atmosphere of the location if there were more elements like those mentioned.

    The main problem I'm facing with the track is the inconsistent framerate though. Most of the time it seems to stick around 20fps for the entire lap. Sometimes it recovers after driving for a while or using the "reload track" command... but even then the framecounter swings between 30 and just under 60fps for me and it's different in every corner which makes consistent driving very hard.
    I recreated a fresh collision cache a few times now and that also only seems to help occassionally. Now I know this isn't something to blame on you, we've been reporting this issue to Ruud for a while now and there hasn't been much of a response as of yet.

    The thing is just that because of the huge mass of indidivual objects used on this track, this Racer "special effect" has such a severe influence on the performance, because you wouldn't notice it as much on a track with a higher average framerate. I wouldn't mention it if I knew my system was on the wanted list of a nearby museum - it runs the Fernstone CG update I released a while back in the vsync limiter for the whole lap with the same Racer settings and car, as a reference.
    Obviously, when I ran the track with all the green bits taken out of geometry.ini (and a fresh cache file) there were no framedrops anymore.



    Anyway, lot's of words, hope some of it is valuable as feedback - thanks again for releasing your work :)
     
  9. Thanks for the release QCM. The problem with the curbs is more likely due to the fact that Racer doesn't like collision surfaces very close to each other, it will cause an effect similar to Z-fighting in graphics only with collisions. You will usually fall down to the surface below but sometimes it kicks back VERY hard.
    Cosmo is right about the collision detection being turned on for many many objects, it does affect performance.

    A problem with BTB is that is makes it VERY easy to plop down a million trees, this looks great but you will find as I did that it's much better to be carefull when using single trees, tree-walls and tree-groups are much more efficient when conveying a dense area.
    I've tried bump mapping the road myself and found that the specular mapping is much more noticed and framerate friendly too. Carlswood has great looking asphalt and seems to be quite efficient.

    I hope this has helped some.

    Alex Forbin
     
  10. @Cosmo

    Well, I always create duplicates or copies of the most important track files, that's all the inis & the curves, in case someone overwrites/saves to new files without backup.

    The fact I didn't pack the track to ar file, is quite obvious, I didn't tell it before, because I suppose you know already the truth, that ar files were decrypted by Xentax aka Aluigi which is the one, who made it all possible for us with Shift 1/2 unpacking process. Same goes for Racer... I usually unpack ar files just to check the composition of your work. More info on google...

    About the collisions flags, I've intentionally set all vegetation to collidable, because no wall tree, nor outer terrain was created ; that's also 1 reason why I didn't included too many fences & walls, to avoid getting claustrophobia & also avoid that the player doesn't fall into the Newton scene. I was thinking, as Crytek Engine does, to create an invisible big collision mesh which includes/wraps all track objects & set almost everything else to 'flags=0' to boost fps rate. After setting all trees to 0, doesn't seem here to make a huge difference at all, if someone can confirm ?

    You're right about the bumps too, as you can see, I've created some cross sections with 2 different road materials, but I didn't add any randomness, it's almost the same discussion as with kerbs, shall we bake detail into 3D or do the inverse or finally do a mix of both ? I think a mix of both is a good balance...Same discussion with displacement, height-maps, bump/normal shaders & stuff...

    The cones are fixed now, see below the code...

    The panorama texture can be added easily, I'll see what I can do.

    About the xtrees, it's the 1st time I use them along with the xtree shader. Since 1 side of the trees faces/quads doesn't render (you see thru), you could use the fence shader for example, still with CSM on, you'll see what happens. Maybe duplicating, offsetting & finally reversing normals could be a solution. That would suppose Xtrees with 4 quads so 8 faces with normals pointing everywhere it needs to.

    The mix2 shader was used to add that randomness to the terrain, the main issue here, was BTB which doesn't let you project UVs as I originally imagined. So, apart from the BTB road/track UVs, you can't control in depth what's happening to the terrain UVs. They're basically top view projected ones... 1 solution would be to play with cross sections & apply to the road mesh some 2/3 different textures. Or simply blend/re-create the road textures with some terrain at its left/right borders.

    The fps drops/leaks seems to be coming from the 'exaggerated' road subdivisions I've set. It's quite logical really, since splines are the basis for physical calculations. For example, you'll have a serious fps drop in the last corner, as you can see in its wire-frame mode. That piece is the most subdivided part with 1m length panel which makes it abusively smooth but buggy at the same time. I'll avoid 1m panel length in BTB for next releases, that's definitely too much.

    Code:
        file=cone.dof
        flags=1024
        mass=1
        inertia=0.1 0.1 0.1
        type=0
        etc...
    
    @Alex

    +1, I'll change the road shader & see how it looks...
     
  11. X tree is 2 quads at 90deg to each other...

    Then just use this shader...

    shader_mytree~vf_xtree
    {
    shininess=16
    specular=0 0 0 0
    cull=none
    layer0
    {
    map=mytree.dds
    depthwrite=1
    alpha_to_coverage=1
    alphafunc=gequal 192
    }
    }

    FPS drop/leak isn't track driving surface related. I've got a really high density mesh road and the FPS rocket along.

    I think it's newton related somewhere.

    Ie, cones on my track kill FPS by about 4x, reload the track in console, and FPS go up loads.

    Even without cones (movables), the track FPS can go up a fair amount just reloading the track in the console.


    Something is going wrong with loading generally, and I think it's newton/movable related from what we are seeing.



    What gets me is, other games use CSM shaders AND get great visuals AND have great FPS.

    Racer is losing tons of speed somewhere... CSM isn't great, but something else, imo, is hogging tons of speed...

    Pre-CSM days on my old machine, I was getting 140fps on my runway track. Same track today and I'm at about 120fps, despite twice as much GPU power and twice as much CPU power (with CSM off!)


    Dave
     
  12. That's why I comment out the cull=none in track.shd file. At 'time 1200', wrong shading calculations occurs...Still, I admit at 'time 1800', it looks how I originally wanted, dense enough & a good depth illusion effect is simulated.

    The fps drops are also surface related, the 3D should be kept simple enough for quickest tyres Newton/Pacejka calculations...The faster you drive on those parts, the more fps difference you'll get. Delete those (1st 6 kerbs) in geometry.ini & you'll see. Same for the last curve/cross-section, the min. panel length should 2 or 1.5 max. On other places, fps stays amazingly stable with a slight variance when hitting kerbs at high speeds.

    Idk exactly about 'reload track', that doesn't seem to do anything here atm...

    & finally sure other games have better shaders, but even the newest games like GT5 or Shift 2, still have some weird shadows occurring at some angles/perspectives...If Racer CSMs were looking like AC2 (Assassin's Creed 2), then we would be good for a long time...:redface:
     
  13. CSM generally looks good. It's the FPS impact that seems excessive for their visual quality.

    Ie, Shift 2 here has loads more textures on screen, loads more polygons on screen, has shadows that look as good, but is getting maybe double the FPS.

    Our shaders are not THAT bad... something somewhere must be costing LOTS of performance. Are our shaders really many magnitudes slower than other graphics engines?

    Hmmmm

    Dave
     
  14. It depends on many factors really, we have the oldest OpenGL profile & only a bunch of shaders. I still believe we can get a lot more, comparatively talking, if Racer had that equal amount of time for developing shaders, we would be far beyond...
     
  15. Stereo

    Stereo
    Premium Member

    I haven't found object flags to affect performance much... even with everything set to flags=0 except the road, I don't see a change in framerate. Not sure what's costing so much framerate compared to Carlswood - I looked at the # of polies being rendered and it's similar (20-25k) visible on both.

    Also, if you want to quickly compile all the flags into geometry.ini,
    Near the top put generic names for each object type
    Code:
      ads_panels
      {
        flags=2
      }
      big_trees
      {
        flags=2
      }
      bushes
      {
        flags=2
      }
      crowd
      {
        flags=2
      }
      fences
      {
        flags=2
      }
      kerbs
      {
        flags=2
      }
      medium_trees
      {
        flags=2
      }
      roads
      {
        flags=6
      }
      skids
      {
        flags=2
      }
      walls
      {
        flags=2
      }
      cone
      {
        flags=6
      }
    objects
    { 
     ...
    Then run a find/replace with whatever preferred regex tools:
    Code:
    s/  (([a-z_]+[a-z])_?[0-9]+)\n  \{\n(.+)\n    flags=[0-9]+/  \1~\2\n  \{\n\3/
    This matches
    Code:
      object_name_##
      {
        file=object_file.dof
        flags=2
    And replaces it to
    Code:
      object_name_##~object_name
      {
        file=object_file.dof
    This way, in order to change flags for all the objects at once (or add whatever other properties) it's just a one line edit near the top of the file. I think TrackEd always puts file= and flags= at the top of the object, so this should be a quick replace.
     
  16. Thanks Stereo, + 1 for your kindly provided Regex function ! :)

    In my case, I've filtered manually the wanted objects to a new Notepad++ file & finally replaced all file instances at once & merged it to the original one. Done the same for the others...
     
  17. Stereo, just don't go open the track in TrackEd after doing that editing, as it destroys any nesting.

    It also seems TrackEd deletes LOD entries too, which isn't so handy.


    Also Stereo, did you reset the cache after changing flags?


    Dave
     
  18. Did you already use LODs in some of your Racer projects ? If yes, how did they impact to your fps ? Is it worth implementing those LODs ?

    I didn't done anything with them yet, because of the work it represents...
     
  19. The only LOD'ing I did was turning stuff off at certain distances, rather than making lower quality versions.

    I've yet to do a proper test, but it seems turning stuff off saves very little FPS at all.

    I just have these feelings that the whole gfx system is still not perfect yet in these regards.

    Do objects that are not visible actually get rendered?

    Do objects that are part of bigger DOF's get rendered if they are not visible?

    Do items behind you actually get rendered?


    I've done some basic tests that seem to show that turning off items behind you saves no FPS, but I'm less certain about things hidden behind hills but still within the draw distance for example.

    It seems logical to turn items off that are so small you can't tell they are there, ie, fences after 300m etc... but then as said, it seems to make very little difference to FPS which is odd...


    Dave
     
  20. Stereo

    Stereo
    Premium Member

    I don't think # of polygons is very important at the moment, relative to other things - eg. screen space shaders should run about as fast on any track. Using simple fragment shaders on the main visible materials might help.