Racer v0.8.38 released

[Ruud]

Racer v0.8.38 is now available at http://www.mediafire.com/file/a9z1omd6rmhzymb/racer0.8.38b.7z

Enjoy!
Ruud

Changelist:
- Look_up/look_down controls added for to make TrackIR devices possible.
That makes head tracking possible, although currently a bit crude.
- In your controller file you can add global.up_down_velocity to set up/down look velocity (default=250)
- In your controller file you can add global.up_down_look_max to set the max up/down look angle (default=45)
- Removed energy conserving diffuse/specular lighting for version 0.9.
- Auto exposure turned back on. It can cause dips in framerate on some systems (every second, a grab is mipmapped to obtain the scene brightness).
- Added shader .mipmap_bias for the global shader and optionally for separate layers.
- Added cubemap mipmapping to all reflection shaders for environment mapping.
Requires a good graphics card; otherwise, turn off envmap.generate_mipmaps (set to 0).
- Fixed keep_aspect (dials/views.ini) for multi-monitor setups.
- Setting up graphics settings and starting a race would crash.
- Added dev.collisions setting to globally turn off collision checking.
- Wireframe mode gave bad texturing for the rest of the graphics.
- Trackcam FOV clamped to zoom range indicated by the camera
- Newton solver parameters reverted in the hopes of fixing now & then hangups (10-200 seconds each, after several hours of play)
- Car camera offset seems back working; the FIXED camera type should now work correctly again.
- Shadowmapping in car camera mode focuses on the car, even if the camera from/to positions are some distance away from the car.
- Reverted back to FMod 4.30 (was v4.36) since some people had volume problems at startup.
- Differential power_ratio warnings were mistakenly given for non-LSD type diffs.

 

[aadilf1]

downloading... will tell you when it's done...

Polish Roads 110fps to ____

Carlswood 180fps to ____

 

[Mr Whippy]

I have a 275GTX, I think... is that an 8 series or newer?

Cheers

Dave

 

[Mr Whippy]

PS, anyone looking to do multiplayer, Cosmo and I had difficulty until I changed this setting in racer.ini

allow_remote=1

I have no idea if that changed things, but after numerous tries each it seemed to make the difference of things working vs not working.

Has anyone else had any success just doing a game over the internet?

Apart from the hosting/joining issues once in game it was fast, lag free and fun!

Just a shame the lobby isn't working and stuff as the actual in-game play over the internet is great... well it always has been really... just needs that extra degree of work to make it a bit more robust and it'd be perfect

Just need to finish up my car/track combo now hehe... even with some free time there never seems to be free time for Racer tracks


Dave

 

[DavidI]

I have a 275GTX, I think... is that an 8 series or newer?

Cheers

Dave

Yes, its newer than an 8600 &8800 GT

 

[boomer541]

Checkin out a car that I'm updating along with some existing cars and ran into the following.

Ran car on Carlswood, checked key 1-0 cameras, looked good. Ran same car on several other tracks, checked key 1-0 cameras and... Oh no! 1 or more cameras changed position!

Could this be another bug?

 

[Cosmo°]

Maybe those cameras are world-fixed and simply have any of follow.pitch/roll/yaw set to zero on purpose?

 

[boomer541]

Thanks Cosmo, I'll check that out.

 

[Alex Forbin]

Checkin out a car that I'm updating along with some existing cars and ran into the following.

Ran car on Carlswood, checked key 1-0 cameras, looked good. Ran same car on several other tracks, checked key 1-0 cameras and... Oh no! 1 or more cameras changed position!

Could this be another bug?

No bug, Ruud moved the camera ref position a few versions back.

Alex Forbin

 

[boomer541]

Ruud moved the camera ref position? Did he change the ref position for each of the keys?

That doesn't make sense as I'm using one car on several tracks and a camera changes to a diferent position on the differnt tracks.

If the ref pos for each camera changed from a previous version shouldn't the camera appear in the same position no matter what track the car is run on? Just give it a try and see what happens!

 

[Cosmo°]

boomer: Did you check out if the offending cameras have follow disabled for one or more axis? Most vehicles will have both fixed and "free" cameras assigned, some of which are useful for driving, others more suited for screencapture. In the case of "free" cameras, they are actually fixed to the track orientation instead of the cars.

The reference point for the camera was either changed from cg position to nullpoint or vice versa - you can avoid such issues if you position the body mesh file so it's origin coincides with the CoG, though Otherwise, simply take the offsets you set for cg.x/y/z and apply them to your camera positions.
However, I don't believe this is the problem you're describing, since you say that the camera positions differ between tracks - they wouldn't do that if only the offset had changed (relative to the reference point).



All: I'd like to point out that from recent conversations with Ruud, it came to light that inboard brakes have been disabled for several years now, so don't be surprised if the old formula cars, 80's Alfas and H1 Hummers of this virtual world no longer work the way they're supposed to

The other important thing I would like to bring attention to has to do with the definition of weight distribution in Racer - I opened a thread for this topic over here: http://www.racedepartment.com/forum/posts/1121109/

 

[Alex Forbin]

Ruud moved the camera ref position? Did he change the ref position for each of the keys?

That doesn't make sense as I'm using one car on several tracks and a camera changes to a diferent position on the differnt tracks.

If the ref pos for each camera changed from a previous version shouldn't the camera appear in the same position no matter what track the car is run on? Just give it a try and see what happens!

Somehow I missed that they were different on each track. Are these SMD cameras?

Alex Forbin

 

[boomer541]

These are fixed cameras. I'm not sure just what a "free" camera code looks like.

I tried the default lambo on both carlswood and roggel tracks and noted that the only key camera that changes position is key-0, bug?

Version 0.08.36 changed the camera reference point from null point to cg which is part of the problem I'm having. This vhange causes the camera view to rotate if the cg is not at the null point. Been wondering about that for a long time! V0.0838 was suposed to fix the problem but didn't as the lambo does have the cg and null at the same place and that is what Ruud probably tested with.

As all dimensions are referenced to the cars null point moving the mesh so the null point is at the cg will cause everyting attached to be offset from where they are supposed to be (haven't tried it but it sounds logical). Cameras need to be referanced to the null point. imho.

An example of fixed camera code that works would be helpful if any one has such code.

Sorry to be such a crab but it makes driving difficult when the view rotates all over the place.

 

[Cosmo°]

Thanks for giving that example - the cameras for the default Lambo were actually part of my contribution to the default Lambo's refresh
If you take a look at the camera section and the highlighted parts, things should be clearer:

edit: it seems I can't change the colour of the font inside the code boxes, but you can find the "follow" sections anyway.

camera8
{
  fov=30
  model=0
  name=side
  wheels=1
  angle
  {
    x=13.5
    y=270
    z=0
  }
  follow
  {
    pitch=1
    roll=1
    yaw=1
  }
  offset
  {
    x=0.3
    y=0
    z=-12
  }
}

camera9
{
  fov=20
  model=0
  name=free
  wheels=1
  angle
  {
    x=25
    y=20
    z=0
  }
  follow
  {
    pitch=1
    roll=1
    yaw=0
  }
  offset
  {
    x=0
    y=0.2
    z=-15
  }
}

As you can see on camera8, all three axis are set to follow and so the camera is completely fixed to the vehicle.
Camera9 being the offending one for you, has the yaw axis set to not follow the vehicle - it will remain fixed to the world coordinates for rotations of the vehicle around it's own y-axis. I called it "free" in the code as well.
A completely free camera would have pitch=0, roll=0 and yaw=0 - entirely fixed to the world and only following the vehicle's camera offset point. Since the orientation of tracks and starting grids can differ, the angle of the free camera towards the vehicle initially varies between tracks - sometimes you might find it starts out over the left side, sometimes from straight ahead and so on.

If you compare the camera angles and types I set in my car.ini files, you can probably spot the pattern. There's always a number of cameras dedicated for driving (cockpit, bonnet, bumper, chase types), some are useful for me during development (straight side-on) and the remaining four cameras are intended to show of the vehicle's specific lines, features and movements during replays - free cameras are part of that, but of course entirely optional

 

[boomer541]

That explians a lot, Thanks Cosmo!

I did some research on racer nl and got the following info:
You need a static reference point from which all other points in the car are defined. - from racer.nl this point is the nullpoint.

I remembered this in the racer.ini file;
Move CG to match nullpoint? Needed to fix CG problems (set to 1). Default=1; 0 is for backward compatibility.
move_cg=1
makes Qlog error:
[racer/352] dbg_car.move_cg=0; this is buggy when cg.xyz!=0, but left in here for optional compatibility with older cars
This was done for a reason I have forgotten what for. I set it = 0.
Has no change to lambo problem on carlswood or roggel. Fixes rotating key 0-1 cameras.

Found reason - from Racer documentation - Car Nullpoints:
The CG
Try to start out with a CG near or exactly at (0,0,0). It will simplify things to have offsets being positive to one side, and neg. to the other side. The CG is specified relative to the nullpoint (0.0.0.); starting from v0.8.27 this CG is correctly transformed so that cars really rotate around the CG. Before that, it rotated around the nullpoint, which was not bad when the NP was close to the CG, but got worse when the CG moved futher from the NP.

So move_cg was set = 1 to rotate car round the CG, = 0 to rotate round the NP

Of 20 cars only the lambo and Raphael's Buggati have cg.xyz=0.

Real bummer that needs to have car rotate round CG and camera 0-9 rotate round NP which is the reference point for cameras.

 

[Cosmo°]

It's a bit messy indeed, with nullpoint and CoG getting mixed up over the past years. At least the documentation is still right in this aspect though - it's a good idea to centre the body mesh around the CoG, so you can keep cg.x/y/z at zero.

Incidentally and just to clear it up, cg.xyz!=0 means "is not" zero in programming lingo, the exclamation mark being the negator. As such the second to last line in your post should go the other way round

 

[QuadCoreMax]

Onyx Onyx Onyx coming fast at us !!!
http://www.racer.nl/tutorial/onyx.htm

I guess it's an abbreviation for 'On Linux'....style scripting.
Was wondering the types...where's the custom objects (cars, cams (TKC, TC), movables, destroyables, terrain...) we can use ?

Too bad for Python, since it's 1 of worldwide most compact & powerful language nowadays...+ it's a Dutch guy like you
At least, you get rid of that $ sign when declaring variables in Onyx....cool !

As Ruud has created 'infinite tracks', I'm able to python/cga procedurally script infinite tracks that generates to infinity in CE....
The ik ? I wouldn't know right now, how to merge those 2 amazing ideas in Racer.

Too much exciting stuff these days...my spirit get lost in another Universe, ROFL.

 

[boomer541]

With all the camera comments I find that if pitch, roll and yaw all = 1 in the car.ini file then the camera view won't change for different tracks.

Haven't figured out if cg moves to null point or nullpoint moves to cg with move_cg=1 in racer.ini file as the camera will rotate around a point and not stay in one place.

I think I have solved that problem. For cars with cg offset and not = 0,0,0 and the camera some distance away from the car its not a major problem if there is some movement of the camera. When the cg is offset some distance and the camera rotating I tried the "free" camera code as indicated on the car cameras page on racer.nl WITH the maxdist=0 and I get NO rotating camera.

The offsets for the free camera code is a bit off from the old fixed camera offsets but appears to be ajustable to get a stable camera that doen't rotate when using a cockpit view for example.

If others agree I can post this info in the update for 0.9 thread. Its really hard to move the mesh to make the nullpoint=cg with out almost completely redoing a car. I think my method is a bit easier to accomplish.

 

[Cosmo°]

You're describing two different things boomer - one is a normal feature that has been around for ages, the other is a bug related to the ongoing CoG confusion.

Cameras "changing position" on different tracks is the wanted feature. The cameras that disable follow for pitch/roll/yaw stay in the same place on all tracks, it's actually the car that moves in those cases. In contrast, if follow.pitch/roll/yaw are all set to one, the camera is "fixed" to the car and will always point on the same direction relative to the car.
You can use both types of cameras depending on the desired effect - obviously car-fixed cameras are more useful for driving, track-fixed cameras offer more cinematic appeal.

The other thing you describe is old style (static) cameras on vehicles which use cg.xyz!=0 - there is a bug where these cameras will not stay pointed in the right direction as you move around in the car. As you noticed, if you replace the static cameras with SMD cameras, the bug disappears. SMD cameras are the type that doesn't use angle and offset, but rather offset and offset_to, as well as the source and destination info to determine where the camera sits, where it points and how it behaves (springing, damping).

 

[SwiftPL]

http://picturepush.com/public/8078424

As you can see, 6 or more wheels are possible. (Screenshot by elektryk572 from Polish Racer Forum). Here you can see how to do it. http://www.racer-polska.pl/index.php?topic=2854.msg62730;boardseen#new Just translate it.

 

[Mr Whippy]

As you noticed, if you replace the static cameras with SMD cameras, the bug disappears. SMD cameras are the type that doesn't use angle and offset, but rather offset and offset_to, as well as the source and destination info to determine where the camera sits, where it points and how it behaves (springing, damping).

I want SMD but also with angle and offset, then we can do some clever things with them...

Instead SMD just do some things better but some things worse, meaning they are not really a replacement for the old cameras, just something different... much like the two types of track cameras

Dave