Better Wheel Blur through Bumpmapping

[Stereo]

I was fiddling around with editing the normals on a model to help the light play off a spinning wheel. It picks up the specular fine, but it's a pain to work with and apparently can't be done in Blender.

So I looked through how bumpmaps work, and made one that's physically impossible as a flat surface, to produce the effect I wanted.

This texture, used as a bumpmap, represents a 45 degree slope at every point on the plane.

Interestingly, the way this texture is rotated changes the direction of the slope. The way it is now, or a 180 degree rotation, are clockwise/counterclockwise slopes around the centre. Rotating it 90 degrees in either direction produces inward/outward slopes. Other angles end up somewhere in between.

This, for example, is the counterclockwise slope. Since it's angled toward the light at the top right, it's brighter, and it's dimmer on the bottom left since it's facing away from the light. The object it's mapped to is flat - the "point" at the centre is entirely a result of the texture.

This is useful, because on a blurred wheel, you effectively have the angled parts of the spokes spreading out into a flat surface, that reflects as if it were at an angle. (I note that brushed metal can also have reflections like this, so maybe this has other applications).

In order to use the effect ingame, I split the wheel into a few layers. The first is plain and simple - flat surfaces. The tire and outer rim of the wheel, as well as the face of the spokes, are flat.

A radial blur in the GIMP produces the texture.

Slightly behind that (at roughly the average depth of the sides of the spokes) is the interesting layer. It's mapped to another circular flat surface.

(this one might be hard to see on the forum, since it's light gray and mostly transparent)
This is a picture of the clockwise-facing polygons of the wheel, flattened out to face the viewer more directly (mostly a matter of making them wider), and blurred similarly to the previous image. This layer gets the bumpmapping from earlier applied - there are actually a pair of these, one clockwise and one counterclockwise, representing the corresponding sides of the spokes. When they catch the light, as in the earlier image of the composite wheel, they light up at an angle from the surface's normals, so you get the proper lighting on the spokes even though they're mapped to a flat object.

Behind these would be the brakes, axle, etc.. - which I didn't model.

The shaders are pretty easy - standard_f/v for the regular surfaces, bump_f/v for the angled ones. I haven't tried with reflections but I expect they would work.

I hope this makes sense, and is useful to someone.

(and then there was more)
To produce the radial gradient, there are 4 compass colours - +red, +green, -red, -green.
Since the bumpmap is expected to be normalized, step 1 is to decide the angle you want (eg. 45 degrees). Take sin/cosine of that angle -> .707/.707. Assuming 0 degrees to be normal (and 90 at a right angle to that), blue is cos and red/green are sin.
rgb triplets for the 4 points are:
+red: (128+128*sin(a), 128, 128+128*cos(a)) = (219, 128, 219)
+green: (128, 128+128*sin(a), 128+128*cos(a)) = (128, 219, 219)
-red: (128-128*sin(a), 128, 128+128*cos(a)) = (36, 128, 219)
-green: (128, 128-128*sin(a), 128+128*cos(a)) = (128, 36, 219)
Once you have these you can just make a gradient with them in that order, counterclockwise. For example, in the image above, I have +red pointing down, then +green pointing right, -red pointing up, -green pointing left.
If you switch them (clockwise) you end up with conflicting directions, and ingame the specular will rotate twice as fast as the wheel, instead of staying still. Easy to fix though, just mirror the texture (if your object is mapped mirrored, you'd need to do this in reverse to compensate, horizontal mirror works fine).
The direction of +red determines what angle to the surface the normals take (I think it's down - clockwise, right - inward, up - counterclockwise, left - outward but I'm not sure).


It's probably possible to combine the transparency of the various spoke parts with the "flat" bumpmap colour (128, 128, 255) to produce a composite bumpmap that handles more than one surface (and would give a single reflection at any point on the wheel instead of blending them ingame) but I don't know whether that's a good idea.


I also had a question. What are the blur models (and corresponding speed to switch) called in car.ini? I couldn't find any reference to it on racer.nl.

 

[Some1]

The pre-csm blur = accumulation buffer method?

Anyway, motion blur is, in my opinion, quite important in a racing game. It helps to perceive the speed much better. However, the blur has to be done right and it must not be overdone.

I'm pretty sure, GT5 has some kind of real time blur and the wheels look quite good both while driving and in replay. Plus, the PS3 is not even that powerful compared to the PC-s nowadays.

Still, the current solution of using multiple models for blur is also okay, althought quite a lot of work. I think, rFactor has a little better solution for wheel blur - it does not switch the models, but switches the texture instead. So, you can make an overlay on the wheel spokes, which becomes visible when the wheel rotational speed is increased and make the spokes disappear in the same time.

 

[Mr Whippy]

I just think a return of the full screen blur we had working nicely is all we need. I'm not sure which version it was, but it shipped in a pre-csm release working as standard iirc. It looked great too. I had an old video on my iPhone and the wheel blur and ground blur look great, while the car itself looks nice and sharp and solid!

Iirc, back then the cost was relatively low. But when CSM hit initially, it chugged. Maybe it can be re-introduced relatively easily again with a better method?!


I'm all for fancy things like texture blurs, but then how does the wheel spokes that are polygonal disappear? At that point models perhaps become a better solution again...?!


Still, as you said, the nice full screen blur adds so much to realism all over, that it'd be better to just let something do that entirely and catch wheel blur in it's scope, than have to fiddle with shaders/models for wheels and all that, which ultimately never transition really nicely or look perfect.
The old pre-csm fullscreen blur however, made any polygonal wheels look really really damn good all on it's own without ANY user tinkering/authoring etc...

Hmmm

Dave

 

[gtpdzbiz]

When I look at GT5's replay, it looks like they use polygonal spoke when the wheels are idle. When it starts spinning, it instantly changed to cylinder spokes with a special shader. It looks like the shader combines some special Anisotropic lighting model with multi-texture swapping based on rotation velocity.

 

[QuadCoreMax]

gtpdzbiz + Some1

+1

That's what I saw when modding Shift...quite interesting to analyze their work !
It's true, it would better & easier just to swap textures, I guess somehow we can build it with custom shaders.

 

[Some1]

It's true, it would better & easier just to swap textures, I guess somehow we can build it with custom shaders.

Actually, this is an idea! I think all we'd need is a variable of the wheel's rotation speed in the shader. From there, we could perhaps create a shader which uses this rotation speed variable to determine which texture to use currently.

We would need to create a texture atlas - a single texture containing multiple wheel textures blurred at different speeds and the in the shader lookup the texture to use for a speed range.

We could also do nice blending so the transition from one texture to another would be smooth...

 

[QuadCoreMax]

+1 Some1

I'm actually finishing reading the official Cg docs, so hope to be able to create something soon...
Feel free to project your Cg code, so we can brainstorm together & somehow begin to build new shaders.

 

[Some1]

+1 Some1

I'm actually finishing reading the official Cg docs, so hope to be able to create something soon...
Feel free to project your Cg code, so we can brainstorm together & somehow begin to build new shaders.

Well, unless we get the wheel rotation speed variable in shaders, there isn't much we can come up with...

 

[Mr Whippy]

Just my 2p.

Sounds heavy duty.

As said, this was all done really nicely and automagically with motion blur.

I'm not sure why GT5 use the 3d > 2d spokes when they start moving, possibly because most of the time if you are moving then you can save 12 cars x 4 wheels x 1000 polygons? ~ 100k polygons?


As per the texture. Atlasing and moving the focus would work, but then we have 4x more texture than is perhaps necessary too... x maybe 6 cars, that gets expensive, especially if we want the zero blur static texture to have loads of detail it'll be a 1024x1024 even with the tyre sidewall and tread mapped in there too!


Maybe scene blur is harder to do now since the cost of CSM is so high we can't take another big effect hit for realtime use? I'm not sure... a question more for Ruud/Mitch I guess...

I just think specific and formalised authoring techniques for wheel blur seem quite heavy duty for people to follow. Ie, do we say that the blur models are 0rad/s, 2rad/s, 5rad/s and then 10rad/s speeds? Who chooses them? What settings are they in Photoshop? Will everyone have photoshop, or will the shader need inputs for the speeds/blend points due to authors deciding on different speeds/thresholds?


We ultimately have this power with models right now, and it works. You can atlast from the same texture with this method too. It works nicely as well. And it gives authors more power. We can also turn it off easily if full screen blur arrives, by commenting out the models for blur. Shader specials would be harder to stop working.

Also, would shadow casting work nicely through the blurred semi-transparrent plane over the wheel? I believe not. It'll either be solid (no shadow, just ambient only light), or full transparrent (fully lit), which might look bad.


Also, for me, authoring wheel blur models seems more intuitive and easy than specially named materials and setup shaders, and split wheel objects so that the spokes disappear at the right point but the rim remains etc... GT5 and Shift etc have some nasty issues with the 2d plane polygons not mating nicely with the higher poly density rim exterior... TDU2 has this really badly!



All imo. Use the existing models method, or just wait for full screen motion blur to return. A totally new method now, with lots of potential downsides and no real benefits (that I can see vs model method), seems a waste of time!?


Hmmmm

Dave

 

[Some1]

Just my 2p.

Sounds heavy duty.

As said, this was all done really nicely and automagically with motion blur.

I'm not sure why GT5 use the 3d > 2d spokes when they start moving, possibly because most of the time if you are moving then you can save 12 cars x 4 wheels x 1000 polygons? ~ 100k polygons?


As per the texture. Atlasing and moving the focus would work, but then we have 4x more texture than is perhaps necessary too... x maybe 6 cars, that gets expensive, especially if we want the zero blur static texture to have loads of detail it'll be a 1024x1024 even with the tyre sidewall and tread mapped in there too!

Well, actually, it wouldn't be that bad. I mean, quite rarely, you have a full 1024x1024 map for a tire sidewall and oher for the wheel. The detail differences with 512x512 textures is small. Besides, if you have 512x512 texture for the wheel, adding another 3 of blurred ones would make it a 1024x1024 or 2048x512.

All imo. Use the existing models method, or just wait for full screen motion blur to return. A totally new method now, with lots of potential downsides and no real benefits (that I can see vs model method), seems a waste of time!?

Well, all this model management becomes pretty crazy, once you have 3 levels of detail and you want to have 4 levels of blur per wheel - 3x4x4=36 wheel models per car?! (Okay, it would probably be less than that, if you made less blur models for lower detail wheels, but still...). Keep in mind that a wheel model also takes memory.

Compromises must be made, and frankly, giving the user too much control is not a good thing, imo. rFactor just dictates that you can have 3 textures for a blurred wheel and each texture is switched at some specific speed (don't even know the exact numbers here). And guess what - 90% of the time, it is enough for me. I don't have to worry that, maybe, I should've added one more blur level or that the blur switch speeds that I specified are wrong etc. So, less stress on me, the modder. I just don't want to decide/specify every little bit and piece all the time.

Well, anyway, we have the multiple model solution and I guess it is good enough for most of us and Ruud, so I don't think it is going anywhere and I don't think there will be any improvements in that deptartment very soon either. Although, somekind of blending between the 'blurrings' would be nice...

For screenshots (in a kinda photo-mode thing), I think it would be possible to render the scene 1000 times over 500 milliseconds of past simulation time and then blend the frames to form one truly motion blurred screenshot. I've done this offline - rendering one second of replay (in Racer) into an uncompressed AVI at 1000fps, then extracted the frames with VirtualDub and combined them in Photoshop.

 

[camsinny]

If the motion blur I think you're talking about is the one you in fact are talking about then it already is available. in your renderer.motion_blur (IIRC) set blur alpha to 0.8 or something. Higher means more blur.
It would be nice however if there was some way of tweaking that per-shader: i.e. your wheels shader tree would include a blur=X amount where the default is 1 (so if it's not defined it's normal behaviour) but a value above 1 will exaggerate the blur; cause let's be honest - racer isn't a physically accurate lighting/shading model (although it does have klux etc. it's by no means physically accurate) we can fudge the thing to look right...

Anyway, play with that blur_alpha or whatever it is amount, i'm sure you'll end up with a value you're happy with. Had a mate over the other night and was messing around with racer...he used to be pretty into it but has moved on - he commented how well the sense of speed is replicated using my blur settings.
Note though: it's framerate dependent, so certain cars and tracks affect it detrimentally.

 

[Some1]

If the motion blur I think you're talking about is the one you in fact are talking about then it already is available. in your renderer.motion_blur (IIRC) set blur alpha to 0.8 or something. Higher means more blur.
It would be nice however if there was some way of tweaking that per-shader: i.e. your wheels shader tree would include a blur=X amount where the default is 1 (so if it's not defined it's normal behaviour) but a value above 1 will exaggerate the blur; cause let's be honest - racer isn't a physically accurate lighting/shading model (although it does have klux etc. it's by no means physically accurate) we can fudge the thing to look right...

Anyway, play with that blur_alpha or whatever it is amount, i'm sure you'll end up with a value you're happy with. Had a mate over the other night and was messing around with racer...he used to be pretty into it but has moved on - he commented how well the sense of speed is replicated using my blur settings.
Note though: it's framerate dependent, so certain cars and tracks affect it detrimentally.

This motion blur is almost good for moving objects, not rotating objects. It basically just takes the few last frames blurs them together. This is not enough for rotating objects like wheels. For those, you'd need really crazily high FPS to produce nice results.

The only solution that was ideal for both moving and rotating objects, was the one that used OpenGL accumulation buffers, but that method was slow as hell to produce nice results.

Also, what most games nowadays do for motion blur, sort of post processing filters that Racer also has (but broken somehwhat) and they basically track the velocity and direction of each pixel and then do a blur. Again, for moving objects, this is ideal, but for rotating objects, not so much.

Even NFS Shift uses either wheel models or rFactor approach for wheel blur, and we're talking about an AAA title here (as in "have mountains of money and lots of geniuses").

 

[camsinny]

Isn't that basically the same method as the accum. Buffers though? (isn't it essentially layering frames on top? Are there some docs somewhere I can read? It's 2am and I'm too lazy to google )

 

[Mr Whippy]

Personally, I don't really use Racer that much to watch wheels going round close up

It's nice to consider it however. I just watch TDU2 videos and am repulsed by their naff wheels. The textures don't even look centred, and seem to flicker as if there is a gradient over the texture and it's moving around and around. Ughhh. Then the silly polygon face over the higher polygon wheel rim itself are low-polygon and don't mate with the outside nicely. They are flat where real wheels dish in quite alot in some cases... they just look horrible.


Cam, the blur I'm talking about was more refined than the alpha output per frame over the next method (which is just blending frames)...

I've forgotten which release it was, but any vanilla download of Racer just before CSM was put in, will run with that motion blur... it's REALLY damn good. I remember when it was added we were all very impressed how we wouldn't need wheel blur models anymore, since it did such a fantastic job of blurring.

It really was an un-obtrusive and very nice quality blur that added realism and took little away from rendering accuracy.

The only downside was when you paused it to take a screenshot, the blur wasn't in it because it must have been done as a dynamic thing... thats why I used to take stills from videos hehe...


I think worrying about wheels is a waste of Ruuds and others time at this stage.

LOD wheels is important, BUT, how often has anyone made an LOD model for a wheel for Racer ever anyway...



Main issues for me.

Hassle to author.

Can't pass intermediate levels of shadow, so either get fully lit or only ambient.

Don't look good at steeper angles without extra polygons (starts to not be a saving then)

No parallax mapping means spokes take on the appearance of being zero thickness at steeper angles, which hurts realism.



Proper screen motion blur as we had in pre-csm versions alleviated ALL these issues. It was essentially perfect in all conditions. Shadow, blurring with the underlying glowing brakes. Solid models (ie, no split at the rim edge and the 2d textured face)...


Why fudge what you can do properly?

Dave

 

[Some1]

Proper screen motion blur as we had in pre-csm versions alleviated ALL these issues. It was essentially perfect in all conditions. Shadow, blurring with the underlying glowing brakes. Solid models (ie, no split at the rim edge and the 2d textured face)...

I think you are forgetting something or mis-remembering things, as currently I haven't seen proper motion blur in any game that could dynamically do wheel blurring (as in radial blur?) with reasonably good FPS.

Most commonly used method currently is the post processing blur, which looks nice for moving objects but makes fast rotating objects such as wheels look funny.

Perhaps we can find out which Racer version you are talking about and double check things?

 

[Stereo]

For a while Racer had the post-process blur set up, but it wasn't working quite right. Did look nice on the track, but it blurred the car as well, even when the camera was held steady on it.

This is from 0.8.5 - activated using velocity_map=1 and fs_filter1 = motionblur.cg (or something like that).

As post-processing it runs really nicely... I get similar framerates whether I use it or not. Just a matter of tweaking the velocity map render so the car was being drawn at the right relative speed, I think.

 

[Some1]

For a while Racer had the post-process blur set up, but it wasn't working quite right. Did look nice on the track, but it blurred the car as well, even when the camera was held steady on it.

This is from 0.8.5 - activated using velocity_map=1 and fs_filter1 = motionblur.cg (or something like that).

As post-processing it runs really nicely... I get similar framerates whether I use it or not. Just a matter of tweaking the velocity map render so the car was being drawn at the right relative speed, I think.

Yes, but this exact method does not work for wheels, which require a lot finer radial blur!

 

[QuadCoreMax]

Well, unless we get the wheel rotation speed variable in shaders, there isn't much we can come up with...

With shaders variables (dt / eyePosW / heat / time / prevModelViewProj etc..) I suppose you could listen to the vertices interpolation position over time & apply some blur into a custom shader when certain vertices velocities are reached. The blur would be a simple post-process/after-effect applied per-fragment with a procedural equation (2D tourus) ? or simpler, blended with a blur texture sampler. With heat, we could simulate another effect on the brakes material mapped to a custom shader...

Really need to go deeper & practice more Cg...

http://racer.nl/reference/gpushader.htm
http://http.developer.nvidia.com/CgTutorial/cg_tutorial_chapter01.html

 

[Stereo]

Yes, but this exact method does not work for wheels, which require a lot finer radial blur!

I still haven't looked into exactly how it works, but what about modifying this method so instead of blurring in straight lines, it was blurring around the radius of circles (needs 3 values: x,y offset to the centre of the circle, and radians to indicate blur distance)? As the centre of the circle goes off to infinity, it approximates a straight line, and for wheels, you just put it around the centre of the local motion. Would work perfectly on a round wheel, and still be a lot better than straight lines on an ellipse. Or if you want to complicate things slightly, implement it with circles in 3D, so you get perfect wheel blurring by angling the circle to line up with the axle. Then you could also use degenerate circles for straight line blurring.

It will be tricky to implement the renderer of the velocity map, but it would still result in a post-processing blur, that just needs some simple circle geometry to determine where to grab pixels from. If Racer is applying a rotation matrix to each object, and the camera, between frames, you could just steal this, add in translation, and work it out.



The ideal blur of course is to be rendering at 300+ fps and accumulating consecutive frames to give 60fps with natural blur. In reality blur is just an artifact of each "frame" being a continuous exposure, the faster a camera shutter the less it'll blur.

 

[Some1]

I still haven't looked into exactly how it works, but what about modifying this method so instead of blurring in straight lines, it was blurring around the radius of circles (needs 3 values: x,y offset to the centre of the circle, and radians to indicate blur distance)? As the centre of the circle goes off to infinity, it approximates a straight line, and for wheels, you just put it around the centre of the local motion. Would work perfectly on a round wheel, and still be a lot better than straight lines on an ellipse. Or if you want to complicate things slightly, implement it with circles in 3D, so you get perfect wheel blurring by angling the circle to line up with the axle. Then you could also use degenerate circles for straight line blurring.

It be tricky to implement the renderer of the velocity map, but it would still result in a post-processing blur, that just needs some simple circle geometry to determine where to grab pixels from.

Well, I think this is pretty tricky or even impossible, otherwise big AAA titles such as NFS Shift and DIRT would be using it....

The ideal blur of course is to be rendering at 300+ fps and accumulating consecutive frames to give 60fps with natural blur. In reality blur is just an artifact of each "frame" being a continuous exposure, the faster a camera shutter the less it'll blur.

I've seen videos (TopGear for example), where some scenes are filmed with a camera that had very fast shutter speed, giving almost no blur at all... the wheels looked very unnatural, as they seemed to be not rotating at all

 

[Stereo]

Yeah, I don't have the knowledge to implement it myself, so I can't say for certain how worthwhile it is. It's not perfect - anything visible behind the wheels (brake calipers for example) would blur as if it's rotating. So maybe it was too much effort with not enough payoff. I could mock it up with a few screenshots, writing the "velocity map" by hand and testing the blur shader on it also by hand. And maybe the effect's just not worth sticking into the pipeline a more complicated pass to make the velocity map.

I think most game consumers don't spend their time criticizing the blur of the wheels, or even thinking about it... blur models provide a good compromise, the only thing they're missing (in Racer) is a shader that can blend between blur models smoothly, so you don't suddenly jump around.

I've spent far too much time studying critically 3d models. I know what flaws look like, and I've spent a lot of time comparing to the real world... sometimes you just have to accept the limitations of a game. I still think glass shader needs a fix for 090f, but my attempts at rewriting them were foiled with depth render issues that I don't know how to fix. In simple scenes where you can't see those problems, Racer looks very real to me.