View RSS Feed

Aperion

Refactoring slidenodes, drivetrain, and framework

Rate this Entry
by
Aperion
, 01-28-13 at 10:53 PM (18832 Views)
Since I've been doing some coding I thought I'd share what I'm working on. First and foremost my goal right now is to rework the drive-train code, this includes the tires. But I am sort of taking a round about approach to this which includes some pretty heavy refactoring. I've written a lot of concept code in the past for a new drive-train but never put it to use. I also wrote it in a reusable manner and am expanding this design.

History
The drive-train code I did write works on it's own, it just needed to be integrated into RoR. The new drive train code is built on the same principle as RoR, nodes and beams. Instead of nodes and beam in a 3 dimensional space we have nodes and beams in a 1 dimensional space. replace position with angle, velocity with moment, and force with torque and you have the same equations. This is where I started.

So I am basically building a parallel "world" for the drive train that works similar to nodes and beams. My starting point was going to be the wheels, since they essentially act like the gate way between the node/beam world and the drive-train world. My approach here is to simulate a drive-train wheel object which is nothing more than an an angle, then calculate where the nodes should be positioned based on that angle. While I was working on this, I realized that this is drive-train same concept I'm using for slide nodes: calculate where a node should be, calculate beam-like forces from where the node is, and where the node should be and distribute forces appropriately. So I started hacking away at some concept that I could use for both when I dawned on me that I had already written this code a long time ago for the drive train.

Theory
So here is a bit about my theory behind the drive-train code, and what will most likely be used in many many more places than the drive-train. As I've worked in the BeamForcesEuler routine I've realized that it boils down to two actions, updating the forces that act on a node, and updating the nodes position. I call them sources, and sinks; sources generate/calculate the forces based on the environment and are applied to the sinks, the sinks take the forces and decide what to do with them. In RoR terms sources are beams, engine, wings, commands, collisions, etc, etc, and sinks are nodes.

One of the cool ideas I will be able to introduce with this new idea is per-node integrators, I feel this will be handy because some weight/spring combinations are not stable but would be if a different integration method is used.

Way Forward (aka the plan)
  1. Replace slidenode code with outside drive-train code
  2. Refactor current wheel calculation
  3. Rewrite current drive-train to make use of new code
  4. Add new drive train features


Replace slidenode code with outside drive-train code
I'm doing this first because it's an existing system so I will be able to just test out the new code against existing slide node behavior to tell if it is working. This will be the biggest change all other items will make use of the concepts implemented here.

Refactoring this code will also have the added benefit of slide node damping since it's already built into the code I will be integrating.

Refactor current wheel calculation
Current wheels aren't very reliable, we average the speed of each node to calculate the rotation of the wheel, this is subject to fluctuation. Instead I will have one object that represents the wheel as a whole, it acts more like a traditional tire model in a game where it's simply a cylinder. This is very similar to slidenodes is that there is an ideal state, and a state the wheels actually are at.

I'm expecting this to help solve a few issues RoR currently faces such as vehicles slipping down a slop when they should be braked. Also under this approach folding wheels should be a thing of the past.

Rewrite current drive-train to make use of new code
Make sure the current drive train code works and behaves as is with the new wheel model, and make use of new code to perform drive train calculations. The current code is a bit of a mess and there is a bug where the first two axles are locked together but none others, this should solve that problem.

Add new drive train features
Multiple engines, torque converters, clutches, lockers, limited slip, multiple gear boxes, transfer-case, brakes, etc

My goal here is to model any and all kinds of different power, be it a traditional engine and 4 wheels, a parallel hybrid with two different engine types, or a helicopter with one engine powering two different rotors. Or who knows what. I want to flip over a car, spin one wheel with the mouse and watch the other wheel spin in the opposite direction when using an open diff. the best part IMO is that I've already got some of this working. I've test locked, open, and LS diffs. I've tested with one power source, and I've tested with two power sources.

And Beyond!
I plan on using this framework throughout RoR, hoping to achieve better performance, multiprocessor support, more organized, and easier to alter.

I'm excited

My work and progress is viewable here: http://sourceforge.net/u/aperion/rig...0fd7a443/tree/
What I will be using for much of my refactoring is here: http://sourceforge.net/u/aperion/rig...ics/framework/
Categories
Development

Comments

  1. atv_123's Avatar
    This sounds as though it will be absolutely epic! Finally we will be able to simulate transfer cases properly along with a nice proper wheel model!

    Now along with this new code I would assume that you are going to completely revamp the engine calculations as well? If so will there be a new engine section in the tuck file along with a new engine option section? I suppose it isn't really needed, but to take advantage of these new features it would probably need it, especially if there will be the possibility of multiple engines in a vehicle.

    Also, in the wheel model you are speaking of, will you have to make an entirely new friction system to work with the new wheel model or do you think that the Node friction calculations that Estama implemented all that while ago will cooperate with it?

    I am so excited to see all of this in action and can't wait to start messing with it!
  2. Davded's Avatar
    Certainly will improve RoR greatly. I like to sound of the new wheel model, and everything else! Good Job!
  3. DODGE charger's Avatar
    This is shaping up to be the biggest potential update in some time, I'm glad to hear you started coding. If the systems are going to be completely reworked, including syntax, I'll be excited to learn some new things for the first time in... forever, it seems.
  4. Aperion's Avatar
    Quote Originally Posted by atv_123
    This sounds as though it will be absolutely epic! Finally we will be able to simulate transfer cases properly along with a nice proper wheel model!

    Now along with this new code I would assume that you are going to completely revamp the engine calculations as well? If so will there be a new engine section in the tuck file along with a new engine option section? I suppose it isn't really needed, but to take advantage of these new features it would probably need it, especially if there will be the possibility of multiple engines in a vehicle.
    Revamping the engine calcs is one thing I would like to do. Although it will probably happen later rather than sooner.

    Quote Originally Posted by atv_123
    Also, in the wheel model you are speaking of, will you have to make an entirely new friction system to work with the new wheel model or do you think that the Node friction calculations that Estama implemented all that while ago will cooperate with it?
    It will use the existing friction system, wheels will be nodes and beams still in a sense. The nodes will still be present but the beams will be handled behind the scene. it will be done the same way slide nodes are handled, which is why I decided to refactor them using this new system first.

    Quote Originally Posted by atv_123
    I am so excited to see all of this in action and can't wait to start messing with it!
    Thanks I enjoying seeing the enthusiasm

    I have a few charts from a couple years ago when I first started the new drivetrain code. They were primarily how I checked if the code was producing the right values. There were a few things I looked for, how was force distributed between dt nodes, and what was their velocity. I wanted to make sure that locked axled always rotated at the same velocity, and open diffs would rotate in the opposite velocity is the engine was off and one of the wheels rotated. I'll try to dig those up soon.
  5. raiderfan's Avatar
    hopefully we'll see a good power train and hope it doesn't get abandon.

    This will be nice also to put life back in the community because work on ror has stopped i think for beamng as of right now.
    Updated 01-31-13 at 03:37 AM by raiderfan
  6. zipppy's Avatar
    I can't wait to see this in action, how long do you feel it will it take for you to implement it completely?

    it should be nice to have an actual working drivetrain in game, along with a new tire model which is round(er).
  7. Aperion's Avatar
    Quote Originally Posted by zipppy
    I can't wait to see this in action, how long do you feel it will it take for you to implement it completely?
    Honestly I can't say. I'm mostly done with the first step which is reworking slidenodes and I've probably been working on it for a month or so. Don't give up hope, but don't hold your breath either

    Quote Originally Posted by zipppy
    it should be nice to have an actual working drivetrain in game, along with a new tire model which is round(er).
    Don't jump to conclusions and get your hopes up. I doubt you'll get rounder wheels, but I am expecting that wheels will be more predictable and stable from a coding stand point. It should make "features" like the slope brake obsolete.
  8. atv_123's Avatar
    Don't jump to conclusions and get your hopes up. I doubt you'll get rounder wheels, but I am expecting that wheels will be more predictable and stable from a coding stand point. It should make "features" like the slope brake obsolete.
    So if you are making them with slide nodes in a way... does that mean that the wheel will almost have like... a beam frame that is non contactable with the ground for the nodes to slide around and act as a wheel? If so then this could also be used for track propulsion in an odd, sort of related, kind of way?
  9. cguy777's Avatar
    This idea is actually very similar to what my game does. I don't know if you know any ODE code, but this class puts an engine in its own, separate world. http://sourceforge.net/p/off-road/co...ad/Engine2.cpp
  10. raiderfan's Avatar
    Quote Originally Posted by cguy777
    This idea is actually very similar to what my game does. I don't know if you know any ODE code, but this class puts an engine in its own, separate world. http://sourceforge.net/p/off-road/co...ad/Engine2.cpp
    Sounds pretty cool
    Updated 02-01-13 at 10:22 PM by raiderfan
  11. Kitteh's Avatar
    Great!
  12. bonami2's Avatar
    1 thing i love you lol

    And manual transmission really working please i dont understand why i have more power on 1 gear auto than first gear manual loll
  13. masfilip's Avatar
    This sounds beautiful, I really want this!!! Thank you!

Trackbacks

Total Trackbacks 0
Trackback URL:


About Rigs of Rods

    Rigs of Rods is a unique soft body physics simulator.


Some Tools


Partners

SourceForge.net

Follow us

Twitter youtube Facebook RSS Feed


impressum