26 August 2004

POINTS OF VIEW IN PHYSICS

I was sitting in Starbucks staring at Shabana's "Computational Dynamics" thinking about the implications of one of his statements. It sounded very similar to what also Katz explains in his Low Speed Aereodynamics book and it was, basically something like: "Sometimes, in physic, choosing the right frame of reference could be the difference between a problem with a solution and a problem without.".

I had spent the night before studying until late to find a solution to my transmission/drivetrain code. I wrote something about this a couple of years ago but it got lost into the internet, so, briefly I recap the situation.

In nK the transmission is simulated using a "network" of geared components. The main influence in designing this way came from this:

http://www.bausch-gall.de/powertrn.htm

The possibility of arranging an infinite number of combinations just connecting basic parts together got me excited, so I started. Everything went fine with basic gear nodes, clutches, gear multipliers but the hell broke loose with differentials. At the end of the day, the solution was an "hack" that, de-facto, made impossible to really use the network in a "creative" way: the differential had to assume there was nothing "after" them but an axle with tyre. That wasn't an huge deal, it gave nK the possibility to simulate RWD and FWD no problem with some tricky implementation of different differentials. But the code was REALLY complex and messed up, every time I had to approach some work on the diffs I was scared by the amount of code to "re-learn", I had to do something about this in nKpro.

The first approach was trying to assimilate the differential to a 3D object, actually, a lever with a pivot in the center and inputs coming from the wheels. The idea came from Millikens' RCVD where he makes this example to explain differentials. It was a mess, it didn't work at it was an huge waste of CPU power anyway. Back to square one.

Then I tried to think to a basic constrained lagrangian system to represent the entire geared network, and that got me back into Shabana's tome until late at night. It was a "long shot", to redesign a system like that from scratch using formulas I am not familiar with anymore was going to take me ages, but it had to be done.

But that original statement about the frame of reference kept me thinking and then I asked myself: "are you sure you're analysing the problem from the right point of view?". Being a poor "forward analysis" person, the only possibility to prove it was to sit down and try to code a "different approach".

In nK 0.9.x the transmission network is based on torques. The singular pieces send torques to each other and react to these torques. The trick is to send the "residual torque" to the next stage. Let's have an example:

O1-O2-O3

These are 3 rotating objects connected together, they don't have any multiplier at all so, infact they act as a single object, but, in the network they are _still_ separate. If a torque T was applied on O1 how could I move this torque to the various object to get the correct accelerations and final speeds?

Starting from O1 I calculate what I call the "effective intertia seen by O1", this is done asking the connected objects to report it, it is like going down a tree and accumulating a value. Now, if O1, O2 and O3 had all an intertia of 1, the inertia "seen" by O1 would be 3. So I apply the torque T to this inertia and accelerate O1, right what should I do with O2 and O3, what torque do they receive? They receive the original torque MINUS the torque used to accelerate O1, and the thing goes on throughout the network.

The start of my "different" approach was trying to get away from sending torques around and try to go "up one level" and send accelerations. This has a big advantage, once I have the effective inertia "seen" by the torque "generator" all I have to do is calculate the acceleration and propagate THAT value across the network. When an object receives and acceleration it doesn't have to think about it's intertia and how much torque it's absorbing, but just speed up and pass the very same acceleration value on to the next node.

It worked in 10 minutes and it cut down my code by a good 50%, now, onto the diffs.

I needed another "idea" to solve a problem with diffs. To determinate the state of a diff, ALL the 3 inputs have to be known. Actually, what is really important is to have the 2 "wheels" inputs. In nK 0.9.x the diff was "recording" the torque coming from the left tyre into memory waiting to have the value from the right tyre to actually solve the equation. This approach could be still valid but it would introduce a sort of "waiting" list in the network, and, more important, the system had to send the torques to the diffs in the right order.

What I am doing now instead is a "buffered solver". In a simple way, the differential is deciding how to distribute the accelerations using the information from the "last frame", that is, from it's acceleration buffer. This introduces a tiny delay into the system (as long as one single physics frame, that is, in nK, 3ms) but the numerical drift is acceptable.

Beyond my best expectations I was driving a "custom" 4wd car in nKpro last night and I was thrilled and amazed by how quickly this "issue" was solved. The code is now deadly simple, Open, Torsen and Salisbury diffs were implemented with no hassles in literally few hours and a base for a electronically mapped diff was also made. I still have to think about the implications of uneven torque split diffs, so important in 4wd, but things are looking so good I can't believe it.

GRAPHICS

Back to the report, apart from last 2 days the week was still dedicated to graphics. I've implemented a shadow mapping system, but for open space environment an huge shadow map is needed. I tried up to 1024x1024, but the resulting shadow was still "flickering" a lot. What is nice about shadow maps is that they are indipendent from geometry, all they need is an additional pass to calculate the shadow map, but, they're easy to use and understand. It's a shame they don't work great for directional lights and big spaces.

I am back to lightmaps that looks much prettier even tho they have the problem to be static while with shadow mapping you say; well , the sun is there.. go on, and they come out, including self shadowing!

Probably I will implement Doom3 style stencil shadow volumes even tho they're, I said this before, not really useful with things like trees and fences.

Outrunner is experimenting with normal maps now to add details to object without increasing the load on the polygon count, I can't wait to see some results.

SEPTEMBER

From next week I will move my attention from graphics to physics and multiplayer. Aereodynamics is going to be reworked a lot, and I am also introducing a real McPherson strut suspension and some old style rear suspension geometries as well.

back to you next time..