Racer v0.8.14 is out

[Ruud]

Is it Friday? Yes, so v0.8.14 is here.
Get it at http://www.racer.nl/dl_beta_win.htm

Changes:

• Shaders fixed for ATI cards again, so it should run again on that. No shadowmap filtering though; the ATI path doesn't support for-loops, nor PCF for depth filtering. Cg shaders are compiled with '-DATI' when running an ATI card (#ifdef ATI).
• Tracked & Modeler recompiled for new fmodex.dll
• Modeler/DOFFix's model optimize now also try to optimize submaterials (Multisub materials where only 1 submaterial is really used). Needed for Swiss Stroll's .dof files.
• CSM now uses PCF correctly (nVidia only, ATI doesn't seem to support free PCF)
• Flares reworked a bit regarding visibility, which was with respect to the camera direction, now a view vector from camera->flare. Billboarding keeps normal and direction, to avoid wide flares (like for a 3rd brakelight) to rotate wrt the underlying brakelight geometry.
• All shaders now render into 1 render target (RT). This had an effect on bloom though, so the bloom brightness pass was modified (in data/renderer/fullscreen_shaders_hdr/bloom_bright_f.cg).This also fixes problems with blending materials, although the shaders will all need to output the base texture's alpha to work correctly when blending.
• AI didn't reset correctly with Shift-R (it would try to start driving immediately)
• AI throttle playing before the start is improved
• Fixed standard_bump*.cg shadow generation, which was non-existant
• Added 'graph step' variables: susp0.piston_velocity, damper_force, arb_force and length to visualize damper behavior.
• Sky shaders now 'stick' the Z coordinate to the far plane. This alleviates the need for an internal very far projection matrix, so no projection matrix switching takes place while rendering the scene.
• Using 2 layers for sky shaders with both layers set to 'depthfunc=always' didn't work correctly and was drawn in 2 passes instead of 1. Fixed (and used in Carlswood_NT).
• Added shader 'cast_shadow' global option. If set to 1, any geometry with this shader is skipped during the shadow generation phase (so it won't cast a shadow in the final render).

 

[AMGfan(BPM)]

Im glad that alpha channel bug is now fixed ( I mean around the car)

Now, just wondering about 2 bugs:

1- Why the beams is too soft?? We can't set up it to more brigher, like halogen or Xenon lamps. It is weird since we can't see anything on the road at night drive.

2- When I set up the time to 21:00, it get sky darker (the darkest time to set up). But the sky gets red, and clear. And then when I put 2200, it get more clear than 21:00 and the reality is the opposite. And more than 2200 it gets more clear. It would be better with dark sky like real one at 22p.m., and less reflections around the car.

 

[luthobu]

@amgfan: boomer posted some solution to the sky problem here. About the lights.. I get good lighting
on Badlands Revisited with CG and your 325i. On Gizmo's the light is almost invisible. So it could be
a shader / texture issue?

 

[AMGfan(BPM)]

@amgfan: boomer posted some solution to the sky problem here. About the lights.. I get good lighting
on Badlands Revisited with CG and your 325i. On Gizmo's the light is almost invisible. So it could be
a shader / texture issue?

I dont know, using lambo @ carlswood on my racer 0808, the beams are fine and good.
In the newer versions (specially cg), the projected light are too weak! Maybe for a 29`s ford T it can supply, but I hope Ruud can find a solution for it!

 

[luthobu]

Figured out the headlight issue. Find the texture for the headlights,
increase brightness and contrast, and if you wish, use glow (if you
have) to smooth it. Worked on the Cuda..

 

[boomer541]

To increse the headlight intensity I adjust the "projected_textures_f.cg" file.

The line: const float diffuseLighting=0.6;

It's set at 0.6 and 0.9 works better, or a value that you like.

Ruud changed it a few versions ago from 1.1.

 

[Mr Whippy]

The light intensity should scale with the TOD, or inversely, the TOD should scale much more strongly, and the headlight light intensity stay fixed...

Problem right now is neither do anything properly hehe

Lights and skies can look good in isolation if you set the numbers for a fixed time, just the TOD stuff isn't perfect yet... TOD curves ftw imo

Dave

 

[AMGfan(BPM)]

To increse the headlight intensity I adjust the "projected_textures_f.cg" file.

The line: const float diffuseLighting=0.6;

It's set at 0.6 and 0.9 works better, or a value that you like.

Ruud changed it a few versions ago from 1.1.

Thanks Mate, it worked! (@1.6)

Please Ruud, change default value to 1.0 or more. 0.6 is too weak, nobody can drive at night using this.

 

[Mr Whippy]

Thanks Mate, it worked! (@1.6)

Please Ruud, change default value to 1.0 or more. 0.6 is too weak, nobody can drive at night using this.

Haha, it's not the absolute value that is the problem. Set it to 1.6, and in the day time it will look like a nuclear bomb is going off on the horizon!

The value simply needs to scale (lookup from a non-dimensional value in the TOD curves we (hopefully) will get), so in the darker scenes they are more intense (flares and light map), and in the light daytime scenes they scale down in intensity.

Hmmmm

Dave

 

[AMGfan(BPM)]

Haha, it's not the absolute value that is the problem. Set it to 1.6, and in the day time it will look like a nuclear bomb is going off on the horizon!

The value simply needs to scale (lookup from a non-dimensional value in the TOD curves we (hopefully) will get), so in the darker scenes they are more intense (flares and light map), and in the light daytime scenes they scale down in intensity.

Hmmmm

Dave

INDEED FOR SURE!

Nuclear bomb was nice, it is seemed! lol

 

[Ruud]

Just the standard_tree_v/f doesn't seem to be working now, my grass planes appear to be lit depending on their facing normal, with one side a different illumination level to the non-culled side... is that to do with the normal, or something in the culling process?

I've modified std_tree for v0.8.15, and also added a standard_grass_v/f. They need slightly different normal calculations for shadowing & lighting, so in the future use the grass shader for grass, and the tree shader for trees.

 

[Some1]

Well, I'm currently updating Factory Test Track to CG, and I'm using standard_transparent_f.cg for trees and grass. I have re-exported all the trees and grass from Max with 'up normals' and they are quite nicely lit. Only problem is that the trees and grass tend to have self-shadowing which looks occasionally weird.

We can remove stuff from shadow pass by specifying "cast_shadow" global shader option. However, sometimes, it would be nice to only have certain objects cast shadows. Would it be possible to add an option in geometry.ini for objects to cast shadows.

Some goes perhaps for receiving shadows?

In rFactor, you can specify ShadowReceiver and ShadowCaster options for single objects btw.

Also, I noticed some FPS boost, if I only allowed objects that 'have a height' to cast shadows. This means, that for example, roads, grasses and other flat surfaces don't usually need to be rendered in the shadow pass. However, this created a problem with TOD, that when the sun was set, it actually shone through the ground from below. But if we get TOD curves, I'm sure we can fix this by zeroing out the sun specular between the sunset-sunrise.

 

[luthobu]

"v0.8.14 has been released. [...] It fixes ATI support again and blending issues."
ATI support is good, blending not.. blendfunc only gives me transparency..

EDIT: forget it.. I did it backwards.. or something..

 

[Mr Whippy]

Well, I'm currently updating Factory Test Track to CG, and I'm using standard_transparent_f.cg for trees and grass. I have re-exported all the trees and grass from Max with 'up normals' and they are quite nicely lit. Only problem is that the trees and grass tend to have self-shadowing which looks occasionally weird.

We can remove stuff from shadow pass by specifying "cast_shadow" global shader option. However, sometimes, it would be nice to only have certain objects cast shadows. Would it be possible to add an option in geometry.ini for objects to cast shadows.

Some goes perhaps for receiving shadows?

In rFactor, you can specify ShadowReceiver and ShadowCaster options for single objects btw.

Also, I noticed some FPS boost, if I only allowed objects that 'have a height' to cast shadows. This means, that for example, roads, grasses and other flat surfaces don't usually need to be rendered in the shadow pass. However, this created a problem with TOD, that when the sun was set, it actually shone through the ground from below. But if we get TOD curves, I'm sure we can fix this by zeroing out the sun specular between the sunset-sunrise.

Some nice ideas there.

An alternative might be to simply have two materials of all those materials that you want to cast shadows or not, then just hand out the materials appropriately that way.

However, a flag in geometry.ini would also be nice. I'm not sure which method is more elegant really... both have pros and cons I guess


As for sunset/sunrise, yeah, turning the diffuse power and specular (specular currently tied to diffuse in TOD?) off below the horizon, while still having the nice 'over the horizon' effects from the sun spot itself glowing up the sky despite the sun itself not giving off light in our scenes


Dave

 

[Ruud]

From what I remember, Ruud said a dome is ideal, since the verts are used for something, rather than a 5 sided box (ie, a cube with no bottom)

I prefer the cube method with a more efficient UVW layout personally, since you can improve the pixel count and get a sharper sky for the same max texture size (4096x4096)

However, I'm thinking now that using a dome with no texture is best, then have the clouds textured onto polygonal planes, and thus have much nicer detail in them... not tested it yet, but it'd get those really nice quality clouds like GT5... right now even a 4096x1024 hemisphere texture is far from enough pixels to have a really nice looking sky it seems

The dome vertices are used to calculate a few of the atmosphere things, which are interpolated per vertex. Other influences are done per-fragment, and they combine up to the final atmosphere color. A cube might be possible, as long as it's tesselated.

We did a few cloud shaders some time ago where you shot a line through each vertex, giving a theoretical texture coordinate, as if you planar-map a cloud texture onto any object (no matter what the object looks like in 3D). That was nice, and you could do moving clouds (even on a sky cube!). Might be good to revive.

 

[Ruud]

A summary of issues/bugs I have found in beta 14:
- I can't really change the brightness of the light flares. They are always a little transparent even if the alpha is all-white? If I want bright flares I have to add one more flare at the same location.
- Setting the ambient/diffuse in special.ini doesn't affect the lighting if TOD is activated. They are just the initial settings. WE NEED CUSTOM TOD CURVES (or whatever way of defining the lighting at a specific time of day)!
- The shadow frustum doesn't follow SMD cameras. If the car has a fixed chase cam, the frustum is following the direction of the camera, but if the car has a SMD chase cam, then the frustum is fixed at some direction and often a lower res shadow split dist is too close to the camera.
- Shader "dyn_standard_bump_speca_f.cg" doesn't receive shadow.
- CSM: Blending between cascades would be nice.

- I've seen that flare issue, but it seems gone, so I couldn't reproduce anymore. Must be some OpenGL state that isn't set correctly, hm.
- TOD vars will be externalized (there's quite a lot of them)
- dyn_standard_bump_speca_f.cg is fixed in 0.8.15
- CSM: I'm still not sure whether to step to include shadows directly while rendering triangles was a good one, seems to still have some side effects and Z issues. Hm.

 

[FiftyOrange]

- TOD vars will be externalized

Thanks!

 

[gtpdzbiz]

- I've seen that flare issue, but it seems gone, so I couldn't reproduce anymore. Must be some OpenGL state that isn't set correctly, hm.
- TOD vars will be externalized (there's quite a lot of them)
- dyn_standard_bump_speca_f.cg is fixed in 0.8.15
- CSM: I'm still not sure whether to step to include shadows directly while rendering triangles was a good one, seems to still have some side effects and Z issues. Hm.

The CSM frustum seems a bit tricky here, for fixed chase cam, it should follow the car most of the time. However, some track-cam with fixed or animated position may want the frusum follow the camera.

The filter will magnify the Z-issues to some extend, but it can be handled by decrease the split distance(for split 1 and 2) and decrease the size of filter(split 3). Most of them can be cover up by high frequency textures, but it's difficult to completely get rid of them.(in fact, many big title games are also suffer form this issue, but they managed to dismissed it as the textures and post effects makes it insignificant).

Another issue with the graphic engine is the auto-exposure adjustment, which was always broken. The new GT5 demo's exposure adjustment is staggering, specially on the day-night transition rally track. It should really be done entirely on the GPU so it won't stall the pipeline.

 

[Ruud]

Well, I'm currently updating Factory Test Track to CG, and I'm using standard_transparent_f.cg for trees and grass. I have re-exported all the trees and grass from Max with 'up normals' and they are quite nicely lit. Only problem is that the trees and grass tend to have self-shadowing which looks occasionally weird.

We can remove stuff from shadow pass by specifying "cast_shadow" global shader option. However, sometimes, it would be nice to only have certain objects cast shadows. Would it be possible to add an option in geometry.ini for objects to cast shadows.

Some goes perhaps for receiving shadows?

In rFactor, you can specify ShadowReceiver and ShadowCaster options for single objects btw.

Also, I noticed some FPS boost, if I only allowed objects that 'have a height' to cast shadows. This means, that for example, roads, grasses and other flat surfaces don't usually need to be rendered in the shadow pass. However, this created a problem with TOD, that when the sun was set, it actually shone through the ground from below. But if we get TOD curves, I'm sure we can fix this by zeroing out the sun specular between the sunset-sunrise.

Turning off shadow receiving isn't really too easy, although, hm, requires modifying all shaders again to include a 'shadowFactor'. Hm.

Not drawing objects that don't need to cast shadow would indeed help. Most road objects won't need to throw a shadow indeed. I've updated Carlswood a bit to give all 'low' objects 'cast_shadow=0'.

 

[Ruud]

I'm still fairly certain that reflections are being added incorrectly.

Since it's not sunny here I can't get some decent imagery, but I will do (fixed camera settings so ignoring exposure), and prove that it looks wrong

I did a test at some point and the cubemap sides of the envmap all had their own lighting intensity it seemed. Using a sphere for a car body might reveal that (so you can see seams where the cubemap sides are).

I've listed a few points I'd like to see fixed/added for v0.9. It's at http://racer.nl/bugs.htm#features
I need to keep that list relatively small so that v0.9 will ever see the light of day (pun intended ).

 

[2o6]

Did the shader system change entirely? My glass is transparent, but everything else looks bad.