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.

 

[Ruud]

Sorry for the late reply I've been out of town.
Sure. How can I get the model to you?

Alex Forbin

Just mail me at ruud at racer dot nl. Perhaps use YouSendIt or such if the model is big.

 

[Mr Whippy]

I'd rather have the camera keys work as they do now actually, with the ctrl key moving linearly, and then say holding the alt key making the camera move 'around' a focus point (say the car)


Holding a button to get the old behaviour isn't a problem for me.

But I think for 'end users' later being able to look around inside the car for instance with the numeric keypad straight away makes more sense than them having to hold a button to look around, otherwise if they press a button they appear to float out of the drivers seat and into space looking back at their car!

Thinking for v0.9 final, the new behaviour is more sensible for a 'newbie' to Racer, and makes Racer feel more polished in my view.
Many people now are used to the whole 'real point of view' camera motion because of games like GTA/TDU where you are a person inside and outside the car.


Hmmm

Dave

 

[Some1]

Holding a button to get the old behaviour isn't a problem for me.

It is a problem for me

But I think for 'end users' later being able to look around inside the car for instance with the numeric keypad straight away makes more sense than them having to hold a button to look around, otherwise if they press a button they appear to float out of the drivers seat and into space looking back at their car!

Thinking for v0.9 final, the new behaviour is more sensible for a 'newbie' to Racer, and makes Racer feel more polished in my view.
Many people now are used to the whole 'real point of view' camera motion because of games like GTA/TDU where you are a person inside and outside the car.

Personally, I think it is more natural for the camera to orbit around the car as it has always been doing. Games like rFactor and NFS Shift also have the camera orbiting around the car. I mean, why do we want to change things if they have been always done one way, even if it would somehow be more logical the other way?

Besides, I think that most newbie racers will spend more time looking the at car from outside rather than from inside...

 

[Alex Forbin]

Ruud,
As for me, I have no problem with change especially when it will be beneficial to Racers future. I think having some way to generate an offset for the camera that allows orbiting would be all that's really needed.. other than fixing the $!@#@ bug that's been there FOREVER! lol.
To be serious though, the camera STILL moves in a diagonal motion when turning.
Try the following camera....

camera0
{
  offset
  {
    x=0.3244
    y=0.7582
    z=-0.23
  }
    offset_to
    {
      x=0.3244
      y=0.0
      z=0
    }
  angle
  {
    x=0
    y=0
    z=0
  }
  src
  {
    mass=8
    k=3900
    damping=1900
    maxdist=1
  }
  dst
  {
    mass=1
    k=2000
    damping=1700
    maxdist=0
  }
  name=inside
  model=1
  view=1
  wheels=2
  fov=50
}

This will make a camera looking straight down with an offset to the left of center (as if you were seated in the left seat looking at your lap).
When you accelerate/stop the motion will be as expected, but when you turn you will notice the camera MOVES in a diagonal motion from the upper left of your view to the lower right. I realize that this is an unconventional view but it is the best way to see the problem. Over the last few years I've tried every combination of settings to fix this, but to no avail.
This seems to be a perfect time to address this bug.

Alex Forbin

 

[2o6]

Is there something wrong with the shaders? It won't recognize any shaders for me.

 

[Alex Forbin]

Why not add an optional " offset_pp " function to the cameras to define it's pivot point along the line of sight?

206:
The shaders are working fine here. If it doesn't recognize ANY shaders I would look for a typo, either in the car.shd filename or there may be an incorrect number of brackets early in your shaders.
Check your Qlog.txt file.

Alex Forbin

 

[boomer541]

Thanks for the info Ruud, I hope you also looked at the three different waters on the track and check over the water cg's as there aren't any in the shader folder.

Like your solution to the camera and the other peoples comments can help you fix them so Mr Whippy is happy and also everyone else.

Don't forget the other prblems that I listed, thank you!

 

[2o6]

Never mind, got it fixed.

 

[Ruud]

Ruud,
As for me, I have no problem with change especially when it will be beneficial to Racers future. I think having some way to generate an offset for the camera that allows orbiting would be all that's really needed.. other than fixing the $!@#@ bug that's been there FOREVER! lol.

Ok then. ;-)
I must say these camera things are a PITA. Two types of cameras and doing extra matrices for headtracking and movements. I guess I just wasn't born for linear algebra. ;-)
Have been at it for 2 days but rotation the camera around a focus point after the camera transform has been calculated just always seem to get an axis off.

I've uploaded an inbetween v0.8.42 exe (I tend to increase version numbers quicker these days, it helps a bit in determining timeframes a bit) at http://www.mediafire.com/file/g5i0mkhzbkcejmh/racer0_8_42exe.7z

Try that for a modified camera 'up' vector calculation for SMD cameras.
It also is modified in that SMD cameras still now use the camera-relative movement (as in v0.8.40) but the Fixed camera type rotates around the CG (not the nullpoint it seems, but the nullpoint internally *is* the CG as the car is loaded). Hm.

An intermediate changelist:
- Cubemap images in shaders can be loaded from subfolders (textures/glass*.tga for example)
- Added a few Onyx functions for generic models, key pressing and car retrieval. Enough to make animating trunk and doors (not replayable).
- Light control now works for the car in focus (even AI cars, if they don't have automatic lights turned on).
- Bugfix: light control used to work for the ghost car instead of the real car.
- Most camera position calculations moved from GPU to CPU to avoid pipeline stalls.
- Car position in 'Select Car' screen was bad.
- Onyx compiles could crash when the script had an empty last line.
- From-to (SMD) cameras now have a revised 'up' vector calculation.

 

[Ruud]

1. moveables down when running watkins track was ok in ver 0.0837
2. no sparks when rubbing guardrail, etc.
3. look left, right, up, down not working. -- -- Fixed Thanks Ruud
4. car bounces back when doing a skid sideways stop -- -- Fixed Thanks Ruud
5. car lights on with ghost car - only ghost car lights come on and wheels don't turn
no car or ghost lifhts and can't see the ghost car.
6. backfire not correct, remains pointed in one direction
6. FF problem when reload_car command in console
7. glass in tracks have reflections not good with live envmapping on LE eats about 75 fps. same for cars
8. Max_alpha in particle.ini no longer works.
9. Camsinny colorgrading problem.
10. Damage image s/b able to move to a different position in data/gui/globalvies.ini

On 1: Movables may fall down at the start when the track was loaded. They can't be frozen at the start anymore, according to Julio (from Newton), so they always must land in a equilibrium.

On 8: tried it and it seems to work (smoke's max_alpha=1 leads to much thicker smoke). Couldn't reproduce.

On 10: damage taken out of globalviews.ini. We only used it currently for a specific customer.

 

[Alex Forbin]

Ok then. ;-)

I must say these camera things are a PITA. Two types of cameras and doing extra matrices for headtracking and movements. I guess I just wasn't born for linear algebra. ;-)
Have been at it for 2 days but rotation the camera around a focus point after the camera transform has been calculated just always seem to get an axis off.

I've uploaded an inbetween v0.8.42 exe (I tend to increase version numbers quicker these days, it helps a bit in determining timeframes a bit) at http://www.mediafire.com/file/g5i0mkhzbkcejmh/racer0_8_42exe.7z

Try that for a modified camera 'up' vector calculation for SMD cameras.
It also is modified in that SMD cameras still now use the camera-relative movement (as in v0.8.40) but the Fixed camera type rotates around the CG (not the nullpoint it seems, but the nullpoint internally *is* the CG as the car is loaded). Hm.

Sorry, it still seems to have the same problem once you rotate the camera back to the front of the car. Also follow appears to be broken, when going around a banked curve the camera stays flat.
Could it possibly be a problem with the order that they are done in (rot/trans vs trans/rot) ? I assume they are being done in local-space and not world-space.

You say linear math is a problem, how about quaterions for cameras? Look here....http://www.gamedev.net/topic/625169-how-to-use-a-quaternion-as-a-camera-orientation/

I appreciate the effort. I'll see what else I can find that might help.

Alex Forbin

 

[boomer541]

Thanks Ruud!
I like the cameras in ver 0842!! I tried Tib's great jaguar sedan and the smd cameras work very realistic when going thru a banked curve the view tilts properly. This is the view from the drivers point of view.

If the head movement is working as you want please leave the cameras and go on to other more pressing things.

Thanks also for the moveable info, I made them a bit differnt so they would stand up when starting a race. Being a vertical sign I just added a support.

Thanks for correcting the menu type, I can read it easily now!

Grat job, Ruud, Thanks!

 

[camsinny]

I'm yet to try out this version but i'll copy all my previous content to this and have a play.

Quickly though: Ruud - what do I have to do to get modeler to accept my damn multisub from Max? I've been using max 2010 for years now but every single time I try to import a multisub into modeler it can't seem to split it. Either it'll get half way through and hang or it'll just say "unsupported multisub" and not import properly.

I'll be able to send you a file I guess to test it if you're interested in fixing it. Alternatively I'd love to have an exporter for cars like the RTC plugin you've made for max.

 

[luthobu]

Sorry for interrupting the thread, but I get the same UDP error with .42
but not with .39 even though they use the exact same ini. I put the .39
exe in the .40 folder, and it works without problems. So I am a bit curious
to why the .4X don't work. No biggie though.. no rush either

 

[Some1]

I'm yet to try out this version but i'll copy all my previous content to this and have a play.

Quickly though: Ruud - what do I have to do to get modeler to accept my damn multisub from Max? I've been using max 2010 for years now but every single time I try to import a multisub into modeler it can't seem to split it. Either it'll get half way through and hang or it'll just say "unsupported multisub" and not import properly.

I'll be able to send you a file I guess to test it if you're interested in fixing it. Alternatively I'd love to have an exporter for cars like the RTC plugin you've made for max.

What's wrong with my 3ds max plugin for Racer? I've been using it for quite some time and never again have had the need for Modeler...

 

[camsinny]

What's wrong with my 3ds max plugin for Racer? I've been using it for quite some time and never again have had the need for Modeler...

I can't remember what it was but there was some issue that was basically a dealbreaker...
Also I can never remember where to find the latest download, I have some old versions floating around on an old pc but I don't actually have it on my current PC.

 

[Mr Whippy]

Like your solution to the camera and the other peoples comments can help you fix them so Mr Whippy is happy and also everyone else.

Hehe, don't get me wrong Boomer, I think the new camera movement is annoying and needs some kinda fix so we have the option of the old behaviour, a button toggle or something maybe defined per camera.
For instance I do like the fact that inside the car from drivers POV I can now look up/down and left/right with the numeric keypad, so the behaviour has it's pros and cons as it is preferable to move it like that in that case!


I guess I've finally become used to the idea that Ruud breaks things on the journey to making them better, so accept that things that I've been familiar with for years might suddenly change along the way hehe

Looks like Ruud has sorted a nice fix which is cool any way!


Alex, those Quats confused me for ages but it makes sense if you imagine programming the actual physical gimbal system and the constraint.
It looked like you just have the first value offset by 90deg to the last value so the system can't gimbal lock (mechanically speaking)
I've had to be messing with them a bit with some rigging in 3DS Max recently and I just went with them because they worked but I didn't ever really get why from a programming POV



Ruud, is there any chance you can take a look at the value inputs (not checked the latest exe so you might have fixed it)... the angle value under the camera entry wasn't applied when a car was loaded...?!


Many thanks

Dave

 

[Mr Whippy]

I can't remember what it was but there was some issue that was basically a dealbreaker...
Also I can never remember where to find the latest download, I have some old versions floating around on an old pc but I don't actually have it on my current PC.

I can't remember which the latest version was either.

I remember I thought it was perfect for my track work, along with Cams script for geometry.ini population from current selection! I could update a bunch of stuff in seconds into the track/Racer environment!

For the cars I remember it came down to exporting needing to use multi-sub, or crunching the model into a single mesh just at export time.
To be honest you could write a Maxscript to crunch selection + create multi-sub, and then just un-do after export... so that isn't an issue for my workflow either.


Is the plugin linked/hosted on your site Some1?


Thanks

Dave

 

[Some1]

Is the plugin linked/hosted on your site Some1?

I think not (yet). When I get time I want to take a look at the issues of my exporter and perhaps create a better version.

 

[Mr Whippy]

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.



Loads of potential there to drag as much data from Max to Racer as you can though. I remember years back tinkering with putting dummies at all the car locations for CofG, suspensions, doing calcs to work out lengths to get it sitting in Racer like it did in Max etc and making a car.ini from it (also tried a finite element script to imagine the mesh was a skin of the car mass, but that never went anywhere haha)
That also ended in tears generally as it just gets so in-depth and so many caveats it means it'd be useless in most cases since you'd have to dig in manually to car.ini... or be a programmer of better standard than me


I'd just throw some links up on your site, they are good tools imo...!

RTC is good too but my issue is it tries to do too much for me with renaming items etc, I prefer having ALL info come from Max if possible where I can manage and save it, any intermediary making 'data' up without control isn't ideal really... lossy processes are bad.


Thanks

Dave