Racer v0.8.40 released

[Ruud]

A newer version. Get it at http://www.mediafire.com/?dm4nkc5bnn3j96n
The latest patch (textures in subfolders) can be found at
http://www.mediafire.com/file/g5i0mkhzbkcejmh/racer0_8_42exe.7z (exe/pdb only)

The changelist:

- User camera offset and angles now take an approach relative to the camera. It might take a while
to get used to it compared to the old method.
- User camera offset/angle works with fixed & free (SMD) car cameras.
- Selecting graphics options and then doing a race would not have any controllers loaded.
- Look left/right works again (although not set by default; go into Controls)
- Onyx classes now supports member functions (no constructors yet)
- Added Onyx mouse functions to get coordinates & buttons (see data/scripts/onyx/include/racer.oxs).
- Added timing.fixed_time_step for ultrasmooth graphics; set vsync=1 and fixed_time_step to 0.016666
for example for a 60Hz screen. May go wrong when Triple Buffering is turned on though.
- Shadowmap rendering pass will now invert culling (instead of turning culling off entirely).
- TrackEd's Split function would generate bad DOFs if more than 21,845 (or perhaps 65,536?) vertices were present
in a single cell. Now it will generate multiple DOFs, each containing at most 21,000 vertices.
- Replay exporting development using DirectShow (instead the ancient VideoForWindows) to get better
video files. May requires openglfilter.ax to be registered (run 'regsvr32 /s openglfilter.ax').
See http://www.racer.nl/index.php?jump=tutorial/replays.htm
- Replay export using DirectShow (replay.video.type=2) now requests a filename (intermediately generates replay_TEMP.avi/wav).
- Replay format changed; now stores the driver names as well and can display those in replays (if show_names=1 in racer.ini).
The format is incompatible with previous replay formats.
- Added replay.auto_save, replay.database.dir for more control on saving replays
- Added support for custom reflection maps in tracks, see http://www.racer.nl/index.php?jump=tutorial/reflection_map_creation.htm
- audio.frequency was unused for a long time. It became apparent when writing replays where timing was off due to 48kHz vs 44.1kHz
discrepancies.

For an interesting experiment, download http://www.mediafire.com/file/04t1dvj6tl2qyvb/WORLD.7z and put the files in data/tracks/carlswood_nt. Very alpha stuff.

 

[Some1]

I don't think it had issues per se, just lack of understanding how it'd fit into workflow from me at least. I remember the discussion we had and it was just a matter of working out the best way to do stuff (mainly me being told because I'm an old man using Max since '95 )

I remember looking for a collapse that did generate multi-sub (default one didn't iirc) but didn't find one but remember seeing it was really easy to script it any way.

Perhaps if you do anything with it, have an option at export time (tick box?) that just makes the selected items into one dof with multi-sub?

Then it'd be perfect for cars for my needs any way. The only way you'd improve it perhaps is taking camera positions from Max and creating a car.ini camera section code snippet. Add a custom properties for the other flags?! I dunno.

Yeah, I guess it came down to the workflow of each individual among other things. I always work with multisubs, Usually, the car is assigned one multisub with sub materials for body, details, windows etc... Perhaps others work without multisubs, but I found It was causing problems when I wanted to merge two objects with different materials.

I kinda based my exporter on the rFactor gMotor tools for Max, which force the modeler to work with multisubs only. I like.

 

[Mr Whippy]

Yeah, multi-sub merge can be messy.

I did find a way and wrote a little script. It's probably still sat somewhere in an obscure user folder somewhere. Why Max can't just be set up for single user and keep all it's bits in it's own folder hehe!


In theory even doing it the old fashioned way, collapse all to edit poly, select one, merge list, select all, then select the right multi-sub merge box. Ok. Done.

Export, then undo, or reload from before merge ideally


I did have a chuckle again at the silly slate/node material editor in more recent versions of Max though. Nodes would be great but they way they did them was just so bad, it was like they took the worst parts and ideas of nodes and then mixed them with the least useful bits of the old editor, and then took away useful scene material browsing in the selection box (spend hours in there when you do a track conversion )

I hope 2014 is gonna be the new 2010 haha!

Dave

 

[Stereo]

'reload track' console command doesn't include reloading scripts, so they're all disabled.

Color grading is not working the way I'd expect, although the exact manner I'm unsure of (using the original image, things work out as expected). Mostly I've been trying it with monochrome maps.

blue map -> green in-game
cyan (blue+green) -> cyan
green -> blue
yellow (red+green) -> magenta (red+blue)
red -> red
magenta (red+blue) -> yellow (red+green)

 

[Mr Whippy]

I've never used the colour grading thing really, I get the point for a final artistic adjustment but generally I don't want that when I'm driving.
It's nice to accentuate a screen shot though... which is imo why all these things should be in fs_filter area...

We could have vignetting toggle, DOF toggle, tone map toggles, exposure tweaks... it's all in fs_filters now, just hard coded and fixed... but it is kinda a DIY notepad edit photomode in the making

Dave

 

[camsinny]

'reload track' console command doesn't include reloading scripts, so they're all disabled.

Color grading is not working the way I'd expect, although the exact manner I'm unsure of (using the original image, things work out as expected). Mostly I've been trying it with monochrome maps.

blue map -> green in-game
cyan (blue+green) -> cyan
green -> blue
yellow (red+green) -> magenta (red+blue)
red -> red
magenta (red+blue) -> yellow (red+green)

So I guess that issue hasn't been fixed yet. Damn.

I've never used the colour grading thing really, I get the point for a final artistic adjustment but generally I don't want that when I'm driving.
It's nice to accentuate a screen shot though... which is imo why all these things should be in fs_filter area...
Dave

I'd just been messing with them for the car selection screen. I was attempting to make a cool little environment. However that went nowhere quickly.

 

[Mr Whippy]

Ruud, is there any specific way to set a camera to fixed or SMD? There is no flag, so does it just detect something in the entries? Ie, if we want it fixed what do we need to use?

As Alex said, the camera follow at least in roll isn't working, yaw and pitch are... this is with fixed cameras...


Also, the new SMD now seem broken vs how they were...

camera1
{
  fov=65
  model=1
  name=driver
  wheels=0
  follow
  {
    pitch=1
    yaw=1
    roll=1
  }
  offset
  {
    x=-0.363
    y=0.5
    z=-0.545
  }
  offset_to
  {
    x=-0.363
    y=0
    z=-0.545
  }
  angle
  {
    x=0
    y=0
    z=0
  }
  src
  {
    mass=10
    k=2500
    damping=300
    maxdist=1
  }
  dst
  {
    mass=1
    k=1
    damping=1
    maxdist=0.01
  }
}

If you try that with a car with an interior, you'll see Racer loads up with the most bizarre rendering for that view, like warp speed or something.

When you move around a bit it then appears normal (ie, apply some forces)

The view should just look straight down to the base of the drivers seat but obviously really struggles. Before (ie, the little fix you added the other day) this worked fine.
I could then adjust the angle of the camera in Racer (not via the camera car.ini entry, angle variables seemed to be ignored), to look forward.

You then had a camera which was in essence pivoting about the seat base despite being positioned at the drivers head, giving a nice movement like the head rolling in a bend or pitching down and forwards when braking hard...
No, not essential for the people with platforms where your head REALLY gets moved around, but really useful for us people with an office chair and a G25 wheel imo.


So sorry to say it, but it still looks broken

Apart from that the other stuff all feels good and I've not spotted any issues. I'm guessing this new issue is the revised up-vector calc since it's only an issue when the SMD cam is looking near straight up or straight down I think (or the vector between from/to is in the vertical plane I should say!)


Thanks

Dave

 

[boomer541]

Mr. Whippy,
Have you tried Tib's Jaguar Sedan? Those SMD cameras appear to work properly, inside, outside and other views. The most realistic of any car I've seen.

 

[Alex Forbin]

Mr. Whippy,
Have you tried Tib's Jaguar Sedan? Those SMD cameras appear to work properly, inside, outside and other views. The most realistic of any car I've seen.

I just tried the Jag and it has the same problems, it doesn't show most of them simply due to the motion being very limited. However it does plainly show the roll is not locking as it should.
The odd motion where the camera pivots/slides is the most disconcerting and appears to simply be a bug that's been hiding for a while now. Ruud will kill it, I'm sure.

Alex Forbin

 

[Mr Whippy]

Mr. Whippy,
Have you tried Tib's Jaguar Sedan? Those SMD cameras appear to work properly, inside, outside and other views. The most realistic of any car I've seen.

Yeah the Jag is nice, but the SMD cameras are still broken

This is where ideally we should have a preference for how car cameras work because I like a bit of movement ala GT5 (which got it really good imo), and that pitches the head and rolls it under g forces... that is why I'd really like to get a similar behaviour in Racer.

Iirc, rFactor has head variables you can adjust per user so you can get a head movement that works for you. Iirc, you can control the SMD properties for pitch/roll and up/down independently of each other too, so lots of fine tune control there!


I must admit that at first the pitch/rolling head made me feel a bit motion sick but I think that is a good thing because your brain is seeing it is natural and thus not liking it
After 30mins I got used to it and it was better by a long way than pure side to side and forward back SMD movement...

Each to their own, I know Cosmo doesn't like cameras that move to much for example and wonders how I can even drive with the ones I have hehe... but I find it a great indicator for instance of how smooth you are.
If your heel and toe isn't perfect you can see the pitch change really clearly because the view tilts up/down and that is really obvious, twice as obvious as with the SMD moving back/forth, and probably twice as much again as a fixed solid camera!
I guess it helps you see really clearly if you are being smooth or not... the camera moving about a plane not in line with the cars accelerations (except up/down where it now doesn't move at all) gives you loads more sensation I think.


It sounds like Alex has another problem though which I've not spotted, wrt pivot/sliding. The roll not locking is an issue too. I also note that cameras with an offset to vector laying in the vertical axis or near to it also go very badly wrong (appear about 1km above the car haha!)

A few fixes still to come but I'm sure they will be fixed up soon.



The system is currently broken again but I'll post up some values once it's fixed for the SL65 AMG drivers camera and see how you rate them...

Cheers

Dave

 

[boomer541]

Mr. Whippy,
I think I unferstand what you desire the cameras to do now. Having the cam view bounce around like my head was moving due to tha car bouncing round just plain makes me sick and I hope that Ruud never locks the cameras to that. JMHO.

If I remember correctly there was something in the racer.ini file that alowed that, I'll have to check it out.

I did try a car with the folow pitch, yaw and roll = 1 and when driving on a slope the camera view operated as it would in a real car.

 

[Mr Whippy]

Roll does work with SMD now, but not with non-SMD.

That said, I don't know how SMD or non-SMD are defined specifically, I guess it's just the absence of the SMD specific settings from the car.ini?

I can drive on a banked circuit with most bonnet view cameras and the camera is flat to the horizon still. SMD one banks with the car though.


The bouncing camera doesn't need to be locked to anything. The behaviour will be linked directly to the values you put in for the camera. You can have bouncy, solid, rocking, whatever you want.
I only want flexibility within the potential of what the system can offer, which has always simply been "add angle support for SMD", that is it. There if you want it, the same as before if you don't, but imo something that should have been in since day 1 with any camera type any way, not just non-SMD.
Bit like track cams, the inability to mix spline/free cameras on tracks is really limiting, there is no real reason for it and it just stalls creative solutions.



The bouncing head is indeed not ideal (up/down/left/right etc), however the rocking head feels more natural as you don't feel to move around as much, just you get some sensation of the forces via the amount the head leans around... a fundamental difference that makes it much better.
I guess this is why GT5 went with that solution, they had about 7 years to think about it and I do believe it works really really well

Dave

 

[boomer541]

Racer.ini has "pov_follow" which gives some really bad camera operation dependant upon the folow pitch, yaw and roll settings. relly bad stuff imo with a lot of pouncing round and probably everyone leaves it disabled, I do anyway. Never knew why it was there in the first place.

I agree that cameras are messed up but imho we should have cameras that rotate round the car cog or nullpoint and cameras that rotate round the camera location and in the first case the camera screen view should be as it would be IRL.

Enough about cameras lets find other problems for Ruud to fix.

 

[Mr Whippy]

Yeah the POV follow is never turned on here. I get the reason for it but it gets weird if you start doing fast steering etc



Cameras are still buggy and I'd personally prefer them to be fixed. There is no point breaking the cameras just before v0.9 might arrive and leaving them half working.

We should either move forward and fix them till they work properly or go back a few steps and say that is what we will take into v0.9.


In any case I imagine Ruud will STILL be fixing these cameras any way because there is probably a commercial need for Track IR support or something similar at his end... so we may as well benefit from it in our Free Racer version


We may as well work with Ruud's goals and general direction and try get our desires thrown in at the same time than not.

All I ever asked for was the angle variable for SMD's to be usable to give us more realistic head movements (like rFactor 1, rFactor 2, GT5, Shift 1/2 used)... I think it's pretty important Racer keeps up with other stuff if it's going to attract either racers/players, or more content creators


Cheers

Dave

 

[Alex Forbin]

Evidently I have extraordinary neck muscles, or a small head because when I drive my car my head doesn't wobble around. That being said, I do support Dave having the option for a
"ceiling-zipper-ear-ear" style camera if he wishes. Maybe you should try a H.A.N.S. device
since this same affliction affects the poor racer drivers as well.

Seriously, all I would like is to have the current SMD cameras move about their assigned position in a foreward-backward-left-right manner instead of slightly rotating around another point somewhere else in the car.
Assigning a camera a position "offset" and a viewing vector "offset_to" is fine, I think if there were one more value such as "rp" to define the rotation point then Dave could have his rotation as well.

Alex Forbin

 

[Mr Whippy]

Hehe, wobbling would be bad.

All I'm after is a subtle angle change when you brake or steer rather than a totally flat offset type movement (as if your head isn't attached to a neck/body)

Ie, you brake hard and your POV moves forward but also slightly downwards.

Indeed it'd be nice if when we set damping = 0 Racer just sets critical damping as it's a pain calculating it ever time I change values


I believe the angle stuff is already in Alex, all we need to do is tie the 'angle' variable in car.ini camera section to the angle you change when you press numeric keypad keys while using an SMD camera.


But they are still buggy however you look at it. Before these latest changes they were not correct. Even now the statics are now broken in roll locking

Then there is still the old distance from origin thing which is a pain. If anyone uses SMD on content and a newbie comes along and runs it on a big track they are gonna be off at the first corner due to crappy camera movement induced loss of control

The only 'safe' cameras for V0.9 really are the old statics and personally I'm not keen on that hehe.


Cheers

Dave

 

[boomer541]

Alex's rp idea sounds like a good solution to part of the camera problem. I've reread the car cameras page on racer.nl several times and still have ytouble getting the cameras exactly where I want them due to the reference to the cog calculation. I usually forget about it when setting the offset/offset_to points.

 

[Mr Whippy]

I'd like a Carlab type solution these days, or probably live in racer with a certain mode. So car.ini values are live updated while you drag etc so you can see stuff move etc.
Even if it's not live but updates after value adjust like Carlab it'd be good. If racer had it a decade ago I can't imagine it'd be hard to have in racer today!? Hmmm

Dave

 

[DavidI]

I propose we rename Mr Whippy to Noddy! ( I now have the mental image of you as one of those nodding Einstein dolls in Night at the Museum lol)

 

[Mr Whippy]

Critically Damped Mr Noddy and I'm happy

Dave

 

[KS95]

Unfortunitely I don't have those abilities