Racer v0.8.30 released!

Ruud

RACER Developer
A relatively small update, as I've been busy with lots of things.
v0.8.30 is availabe at http://www.racer.nl/download/racer0.8.30.zip (75Mb)

*NOTE* The Carlswood track looks very color-corrected - probably just a one-time thing to demonstrate color-grading.

Changes:
- Car selection would crash after a race
- Car flare light blending modified - alpha,1-alpha (was alpha,one)
- Menu images were sometimes dark - was a 'linear vs srgb init' problem
- F1 stats scaling corrected vertically
- standard_xtree_f.cg didn't use 'sunny' parameter
- Made the menu image a bit more transparent to see the slideshow
- Added color grading per track; see http://www.racer.nl/tutorial/colorgrading.htm

(also added standard_xtree_scale_f.cg, but that should collapse into standard_xtree_f.cg probably as the only real change is that scale is used, and with scale=1 they should be the same).
 
AARGHGHGHGHHGHGH!

So, I'll rebuild my splines to start just ahead of my starting grid on this point to point track. Nice, I can't select my splines in trackEd (no idea why), so I can't delete the ones at the start grid. Oh. Rebuild the lot then.

Ah, all these verts in the road from the trees are confusing the auto splining. I'll hide those trees by commenting them out in geometry.ini.

Create splines, nice. Done. Save.

Thanks TrackEd for now deleting all my commented out entries. Thanks a bunch.

Good job I back everything up ini wise before using trackEd. Even stuff it doesn't need to change it screws up!

Ruud, can we have a better save mechanism so we can save *just* splines, or *just* flags, or something, or layering to hide certain objects in trackEd, or something to make it more viable as an editing program for tracks?!


Three hours today just trying to make some splines work, and 2:50 of that is fighting trackEd and writing posts on here :D :)

Dave
 
Uhhhh, now AI won't get to the first damn spline!

ARGHHHHHH!

And any damn keyframe cameras I do will all be out if I re-number the splines AGAIN...


Ruud, not having a go, but I want to make things, but I just don't know what the best or right way is. I don't want to have to re-do things again and again because the trackEd build process is so linear. We need some non-linear editing capability.


Basically put. How should I make a point to point track that:

Has AI capability, so splines need to run under the start grid.
Will start timing ONLY when I set off, not straight away as it does now (with point to point = 1)
Can have a start point that isn't the first spline.
Can make it so I can record splines that I'm already on top of (they work fine now I'm driving over the 0 spline, I guess you could reverse back to start the AI recording run, hmmm)


Just getting confused here and thats not ideal for a post v0.9 world. Is there a way we can do this properly or not? If not, what is the ideal solution?


Thanks

Dave
 
OK, so now AI recording works, but you have to drive from off spline0, and onto it, to get it going. Not so easy on a point to point system. By definition you need to run splines under the start grid so AI will go.
This means all AI recording on point to point tracks will need the user to reverse off the splines before initiating their recording run.

A side issue may be that timing starts automatically on a point to point = 1 course. The start timing line is forced by trackEd to the first spline in any case...


Yay, I can now also select splines in trackEd. Not sure how. But it's still a struggle once any other objects are in there, especially X trees with the verts sticking onto the road surface or nearby.
Again, this is a problem when trying to non-linear edit. You create splines best with nothing else there, but then the same stands true for cameras, but ideally you NEED trees etc there to gauge if the camera is in the best place, which is hard when you turned them off to aid spline selection.
Any way to make it so when you are in keyframe camera screen, AND press shift, the auto-snap of the cursor is forced to spline coords, so you basically can only ever select a spline when that is your intention?


Hmmmm, just trying to write out best process here. I'm struggling and others new to Racer v0.9 will, so best we determine the best course for authors to generate content efficiently :D

Dave
 
Hmmm, which track cameras should we be using?

Keyframe only, or the old ones, or a mix?

Right now if there is a single splines gap in the KF cameras, then it reverts back to the car camera, and then doesn't return back to the KF cameras where present.

I'm guessing KF and old style camera mixing is ideal to get a mix of cool camera movements? KF cameras are just an alternative addition, rather than the ones to use exclusively?

Thanks

Dave
 
i always extract the track/driving surfaceto a new object, and make a spline.dof from it, breaking in more detail where needed. Then I use a spline geometry.ini with only the spline.dof referenced, and splines are done in five minutes. There was no other way of splining broken springs otherwise...
 
Nah, the target spline would always jump to some completely unrelated point on corners and thru some bits of the multilevel carpark where it'd jump to the level above or below; even using just a spline dof. Always needed correcting maunally. I'll tell you how fast I can do it soon, as I'm working on broken springs v2 atm.
 
Mr. Whippy,
What version of tracked are you using? Are you using the one that came with ver 0.0830? Isn't it all black with just the positions/cameras/splines visible?

Didn't anyone read my post on page 2 of this thread cocerning the screwed up tracked?

The numbering of splines is from 0 to the last number, if you have 1000 spline the paint will be 0 to 999!

Ruud, Please fix tracked!!!!!!!!
 
Question, do I design splines & track as before, where I had more 'detail' for elevation changes (flat road to ramp surface transitions etc) than the track mesh had, or should I be now designing that 'detail' into the track mesh itself as well?
I used to have more detail in the splines as while they gave a smooother driving surface, the extra detail didn't hinder graphical performance also; but as the future seems to be using the track mesh instead of splines for the driving surface maybe I should be adding the detail into the track.

Another thought on AI & sharp corners, where the look-ahead becomes too large & the cars try & cut corners thru immovable objects. Maybe the look-ahead value could also take into account how much heading change occurs from spline to spline, and if it's large (i.e. on a tight corner) scale the look ahead back to one or two splines?
 
Mr. Whippy,
What version of tracked are you using? Are you using the one that came with ver 0.0830? Isn't it all black with just the positions/cameras/splines visible?

Didn't anyone read my post on page 2 of this thread cocerning the screwed up tracked?

The numbering of splines is from 0 to the last number, if you have 1000 spline the paint will be 0 to 999!

Ruud, Please fix tracked!!!!!!!!

Still on 29 here. Sounds like 30 is broken.

Just trying to develop content this weekend so didn't want the distraction of new bugs etc etc...

Yeah, the whole splines count isn't clear really. Shame there is no way to append to the start/end and TrackEd re-number them appropriately. You essentially have to start again from spline0 if you want new entries at the start of the course! Eeek!

Dave
 
Question, do I design splines & track as before, where I had more 'detail' for elevation changes (flat road to ramp surface transitions etc) than the track mesh had, or should I be now designing that 'detail' into the track mesh itself as well?
I used to have more detail in the splines as while they gave a smooother driving surface, the extra detail didn't hinder graphical performance also; but as the future seems to be using the track mesh instead of splines for the driving surface maybe I should be adding the detail into the track.

Another thought on AI & sharp corners, where the look-ahead becomes too large & the cars try & cut corners thru immovable objects. Maybe the look-ahead value could also take into account how much heading change occurs from spline to spline, and if it's large (i.e. on a tight corner) scale the look ahead back to one or two splines?

I've struggled with having low-polygon splines here. If your splines don't match up with the polygons they are made up from, then setting up the keyframe cameras, which need you to select splines to set keyframes, is nigh on impossible.
My track is fairly high density mesh, so the splines made are very high too, too high really, the AI car judders around and makes odd decisions where it doesn't need to really.
Ideally I want to just reduce the spline density by about 5x, but as said, the issue really is that trackEd authoring is quite poor, and the spline selection *RELIES* on the model verts that made those splines, NOT the splines themselves for selection.
If that can be changed around, then it'll be loads easier to work from, for any person doing anything I think.

Right now it's just so limited it stops you from being creative. Well, you can still be creative, but it takes hours and hours (as I found out yesterday), to do even the simplest things. It could have taken 10mins with a spline selection tool, rather than one that always tries selecting verts.

I'll certainly be looking at more scripting for 3DS Max export when I get the time... I just don't have the time to fight with trackEd when I could be making real progress and doing actual productive work.

I'm amazed the content guys at Cruden haven't already written scripts from 3DS Max or whatever they use to ease workflow in this regard. It'd take weeks to write them really well perhaps, but over the coming years it'll save them months of just dead time in TrackEd!

Dave
 
Also, just another note.

I know we had the new ff_factors added, which are mighty useful, but I've already had discussions with Cosmo over the weight of the steering we encounter, he prefers less, I prefer more.

Right now there is no "one stop shop" to alter the weight of steering in a car.ini to ones tastes. We have to edit the ff_gain (which alters all but the ff_factor), and the ff_factor...

I'm not sure why ff_gain is only adjusting the on-wheel effects. Anyone choosing the right balance of those (often the author), will be tweaking them all up and done and all over to find the right balance. I've not moved ff_gain from 1 since it was added, except to find out what it did :D

Should ff_gain just be an 'overall' FF strength per car?

Then when I get Cosmo's cars, I just tweak it up, and when he gets mine, I just tweak that one value down? Eventually maybe even have users adjust this to taste and expect them to do that.


I can just see it getting all messy, and people just editing values without understanding them properly.

I think ff_gain might be useful still, but on top of that, a ff_global might be useful then?

I also think better naming is going to be useful?!

ff_factor is only a factor for tyre forces. So how about calling it ff_tyre_factor?

ff_gain is only a gain for wheel effects, so how about calling it ff_effects?

ff_global then makes sense too.

Right now it's just a load of badly named coefficients.

Users for now (because all wheels are not centrally calibrated to feel the same) WILL need to edit these to their preference, and it will be harder with the system in place now!



On FF generally, doing things like reload car, reload track, back to menu and back into game, screw up FF forces, some disappear, some stay, sometimes it feels to get lighter etc etc...
Not sure why, but I often end up just restarting Racer because it's the only way to assure the assessment of my FF changes are actually what they should be when tuning the variables.

Thanks

Dave
 
I know we had the new ff_factors added, which are mighty useful, but I've already had discussions with Cosmo over the weight of the steering we encounter, he prefers less, I prefer more.

The main reason why I usually set the overall strength lower is that I want to feel a nicely (and appropriate for the vehicle) weighted resistance and clear slip angle feedback, but simply can't accept the strength, noise and stress on parts that happen when a bigger bump is being hit, a kerb or sidewalk, or Ruud forgot to turn down the steer_noise on Carlswood's grass and gravel again :)

In these situations the steering forces are way higher than I want them to be, but I can't single out those effects and thus have to compromise and run weaker overall forces, which isnt ideal.



I've not moved ff_gain from 1 since it was added, except to find out what it did :D

Right now it's just a load of badly named coefficients.

Same here, it feels slightly obsolete and confusingly named to me, especially if you consider people who aren't used to working with them and just want to adjust the steering strength on a vehicle once in a while.



On FF generally, doing things like reload car, reload track, back to menu and back into game, screw up FF forces, some disappear, some stay, sometimes it feels to get lighter etc etc...
Not sure why, but I often end up just restarting Racer because it's the only way to assure the assessment of my FF changes are actually what they should be when tuning the variables.

I'm running into similar issues here. Tweaking these things should be a reliable and simple process, but it's currently not. Having to quit and restart Racer all the time makes it hard to evaluate differences between steering force settings.
 
I haven't seen yet a solution for the problem Cosmo mentioned in the beginning of this thread:

... if you check out the flares in v0.8.30 as well as the sky on garage1, they all go slightly crazy colour shifts/low bit colour mode.

As the sky in garage1 has been already fixed with update for data/renderer/common/utils.cg, link:
http://www.racedepartment.com/racer/46460-racer-v0-8-30-released.html#post708650

I am still wandering how to fix weird looking flares (see photos)..

screenshot003.jpgscreenshot004.jpg
 
Thanks DavidI for confirming black tracked in ver 0.0830.

If you have an old version of tracked, prior to ver 5, then use that one.

Shadows on tatra tire in wheel well with my shadow settings.

shadow1.jpg a little hard to see as everything is black.
 

Attachments

  • splits.txt
    2 KB · Views: 290
  • constants.7z
    1.1 KB · Views: 144
They slow me down by about 15% FPS... that is 2048 maps generally after testing vs 1024's... in some cases it's less or none (not sure how/why), but on average on a busy track with AI drivers etc with lots going on, it's about 15% cost.

I also considered that on anything under a 1600px wide view, then you were essentially putting more than 1px of shadow map data into 1px on screen nearby, which seemed a waste. On a big 30" display at native resolution though, then it might add nice extra detail :D

I like the improved view distance for shadows, but I'd really want that from the inside view too. Why only from the outside views? For screenshots?

My main worry as always is that we can improve things further with 4096 maps... but where do we stop?

The bloom map would be better at 1024 too, but again, where do we stop?

I'm all for a set of these that run at F12 time, like photomode, that crank up all the settings loads... if that were possible it'd be cool :D


Personally I really think the defaults right now are perfect for v0.9. If we can tidy up the acne more, great, but the shadows as they stand are a big enough FPS hit without making the demands on sub 512meg gfx cards even higher (my Quadro at work is crippled on FPS with 512meg, as was my old GFX card at home with 512meg)
They are so easy to ramp up, that if you post a shadow upgrade setup at v0.9, I'm sure many will use it if their hardware allows :D


*BUT, I'd just check with Ruud that stuff elsewhere isn't hardcoded now to expect 1024 maps. That hard coding might be doing weird things, so just best to check!?

Deffo something Ruud should consider having a way to toggle in the menu though. It doesn't really harm anyone to have a way to switch these things so people can load Racer in 'extreme' shadow mode or something :D





Not wanting to be negative generally, but we are testing these shadows and lots of things in Racer oddly. Zooming in on a car whose wheels have 25meg of textures on them, which even in that screen shot are mipped down because the textures are so huge. Testing on empty barren tracks, and simply picking holes in small artifacts and so on.
OK, it's important we get it good, but razzing around Carlswood with 10 Lambo's and blur on the shadows off, in 1920x1200, and my FPS is already only just playable at around 50fps, and my system is pretty good (275GTX)
Drop it to 1600x1000 and it's nicer speed, but still. At no point did I go "eughh" look at the nasty shadows. They just blended in perfectly.
I think we really need to start getting realistic about what we can get away with in our graphics.

I'm all for beauty shots and Racer looking fantastic, but I'm also looking forward to pushing every boundary Racer has visually in other ways, like your track, I want tons of sounds, surfaces, things going on, movables, a really really rich environment. I just worry that if we steal all the gfx performance now for shadows and fancy other stuff that isn't really THAT important, there will be no space left for making engaging content.

Racer right now is, imo, not so good in visual bang, for the buck it costs! NFS HP looks amazing on my system with better FPS!

Thats up to us to fix, but we need to start thinking about the content we make being rich, rather than expecting our shaders and shadow settings trying to achieve that visual quality for us :D


I'm all up for the challenge :D

(thats a general thought by the way, not a targetted rant on anyone :D )

Maybe I've been reading nVidia docs too much, but we have got into some bad practice over the years. To get the good visuals and good speed, we NEED to think about how we make stuff much more these days :D
Optimisation is king!

Dave
 
Bug:
This appears after running carlswood in tracked and making no changes. Tracked appears to change Newton version. After running carlswood with 1 lambo ai car the Qlog is:
(INFO): [racer/3616] Loading track 'carlswood_nt'
(WARN): [racer/3616] PNewtonGeom:LoadTree; 'data/tracks/carlswood_nt/cache/trackcollision.bin' was generated by a different Newton version. File: 2.26 RacerNewton: 2.29. Load fails.

Also have to press a different car camera key before key 0 will work on ai 2nd car, and if in track camera mode and focus on "The Driver" car the track camera switches back to car 1-key camera. driving back onto track switches back to track camera.

Bug: Can't see the slide show images in the GUI, just fix the menu_overlay.tga image alpha so it is more tramsparent, also why is it not a 24 bit compressed .tga image.

Bug: Tracked changes "Alternative with light sky" variable in special.ini file to bright white!
sky=8.076190 8.076190 8.076190 0.000000

All of the above was posted in the 0829 thread twice but got lost with all the problems others kept posting about.
Tracked tracks are all black. IT NEEDS FIXING, PLEASE!!!!!!!!!!!!!!!!

Color grading works with Paint Shop Pro as well as Photoshop, adjusting the colors is a bit tricky as everything is affected. To make Carlswood like it was in 0829 just comment out the color grading in the special.ini file.

I posted my shadow settings, I think it was back in ver 0.0828, and they give me very good shadows with a mapsize=2048 which doesn't lower FPS. if anyone wants them I'll post them again.

Bugs noted; tracked.exe has now been recompiled to use Newton 2.29; it would indeed pingpong between 2.26 and 2.29 as you run tracked.exe, then racer.exe etc.

I'm not using the 2048 mapsize; internally with splits=4 you get a 4096x4096 map (4x 2048x2048) which is quite heavy even for modern cards. If fps doesn't change at your computer, that just means that the memory and/or bandwidth isn't the bottleneck in your case, but generally it just means a lot of used gfx memory and bandwidth.

The menu tga is 32-bits since it needs alpha to define where the menu image is visible. 24-bits can't do that... It was already improved in v0.8.30, where I added a bit more transparency.
 
Ruud - It seems that textures aren't cleared from memory after changing car (yet to test track).
i.e. I ran the 458 at carlswood then the lambo - but the 458's textures are still in memory. They mightn't be being used or mightn't make a difference but I was just wondering if there might be a performance increase possible there?

Also - I agree that a 2048 shadowmap is OTT. It does indeed generate a 4096 texture which just eats the VRAM.
I'm just trying to optimise things as much as possible...I'm currently using gDEBugger which came with the perfKit but it seems that the perfSDK page (2x ctrl-f6) doesn't show anything. I know you said there were problems with x64 OS and that feature...was just wondering how to PROPERLY set it up to optimise content.

Oh and heat affects brakes WAAAAAAAAAY too much. The settings I had were much more subtle and better.
 

Latest News

How long have you been simracing

  • < 1 year

    Votes: 364 15.8%
  • < 2 years

    Votes: 254 11.1%
  • < 3 years

    Votes: 245 10.7%
  • < 4 years

    Votes: 181 7.9%
  • < 5 years

    Votes: 303 13.2%
  • < 10 years

    Votes: 260 11.3%
  • < 15 years

    Votes: 166 7.2%
  • < 20 years

    Votes: 129 5.6%
  • < 25 years

    Votes: 99 4.3%
  • Ok, I am a dinosaur

    Votes: 297 12.9%
Back
Top