View RSS Feed

Aperion

Step one complete, now for step two

Rate this Entry
by
Aperion
, 02-08-13 at 05:26 AM (18570 Views)
This is a follow up post to my previous one about refactoring and my plan forward.

I have completed the first item in my list
Way Forward (aka the plan)
  1. Replace slidenode code with outside drive-train code - Completed
  2. Refactor current wheel calculation - in progress
  3. Rewrite current drive-train to make use of new code
  4. Add new drive train features


Here is what I wrote about the next step here:
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.
I am kind of gathering my thoughts on how to approach this step, and how to explain it. There are essentially two "worlds" I'll be dealing with, a beam world and a drive-train world. the beam world is the one we are familiar with, point masses held together by springs in a 3D space. The drive-train world is made of point masses held together by springs in a 1D space. So where nodes have an [x,y,z] coordinates drive-train components simply have an angle. Essentially the drive-train world is the beam world with different dimensions and units.

So what the next step needs is translating from 1D to 3D and back. The angle in the drivetrain world will correspond to the angle offset each node is from it's original position, the hard part is how do you account for the wheel being at any odd angle? Possibly even upside down. Come to think of it, I remember now what my solution was, this is actually why I write these posts, to help me think.

What we know is each nodes initial starting position and the current position of the axle nodes and each wheel node. If we find the rotation required to translate the axle to it's original postion we can then apply that transformation to the current wheel node position. Then use the translated current wheel node position, the center axle and the initial node position we can calculate the current angle difference from the initial position. This can then be used to calculate difference between where the node is supposed to be based on the drive-train world, and where it actually is.

I did write a tiny program just to test this out:
Code:
#include <iostream>
#include <OGRE/Ogre.h>

int main()
{

	Ogre::Vector3 pn1(1, 0, 0);
	Ogre::Vector3 pn3(1, 0, 1);
	
	Ogre::Vector3 n2(0, 0, 0);
	Ogre::Vector3 n1(0, 1, 0);
	Ogre::Vector3 n3(-1, 1, 1);
	Ogre::Quaternion rot;

	 // move nodes to origin...
	n1 -= n2;
	n3 -= n2;
	
	// get rotation
	rot = n1.getRotationTo(pn1.normalisedCopy());
	
	// move spoke to origin for rotation
	n3 -= n1;
	n3 = rot * n3;
	
	std::cout << Ogre::Degree((pn3 - pn1).angleBetween(n3));
	return 0;
}
We'll see how logn this takes to get done. night night.
Categories
Development

Comments

  1. Kitteh's Avatar
    WOW. Incredible work. It's nice to know that some devs have not given up on ror.
  2. DODGE charger's Avatar
    Actually 0 devs have given up on RoR. It's just a busy time in people's life right now, I assume.

    But this is still amazing, I can't wait to see it at work! Would this make damaging your drivetrain easier to implement?
  3. masfilip's Avatar
    Nice to see that you can cope your big plans. Good luck!
  4. brother_david's Avatar
    Quote Originally Posted by Kitteh
    WOW. Incredible work. It's nice to know that some devs have not given up on ror.
    Agrees, sounds awesome
  5. raiderfan's Avatar
    I think ror is just on hold while they work on beamng and get it finished luckly Aperion is stilll here so we might not have to wait two years for ror .40.
  6. Aperion's Avatar
    Quote Originally Posted by DODGE charger
    Would this make damaging your drivetrain easier to implement?
    Not this step, but the next step yes, much easier, trivial even, as all of the logic is already there. There are two possibilities, that drive-train components break on their own when too much torque is applied, and/or breaks when a beam breaks. for the later an association with beams would need to be made, the rest is in place.

    Quote Originally Posted by raiderfan
    we might not have to wait two years for ror .40.
    I'm kind of doing my own thing, working on what I want to work on. I'm not familiar with what is supposed to be in 0.40.

    Besides, given that BeamNG is not cross-platform I am not really interested in it. And I spend more time coding for RoR than I do playing it, so I'm more interested in RoR at this time.
    Updated 02-08-13 at 09:24 PM by Aperion
  7. raiderfan's Avatar
    The changes your making are probably bigger and better then the stuff in .40 the only new thing i seen was the new terrain and auto trans update.

    This definitely sounds awesome though.
  8. woozy's Avatar
    Glad to see you working on this... and having progress is very good if only for your own motivation

    Thanks!
  9. DODGE charger's Avatar
    Quote Originally Posted by Aperion
    Not this step, but the next step yes, much easier, trivial even, as all of the logic is already there. There are two possibilities, that drive-train components break on their own when too much torque is applied, and/or breaks when a beam breaks. for the later an association with beams would need to be made, the rest is in place.
    Okay, when that comes, it will be the start of a revolution.
  10. Gouranga's Avatar
    By treating a wheel as a single object/cylinder you mean just the rotation part, or that the whole wheel won't be made of nodes and beams any more?
    Would it be possible to make reaction torque act at correct position?
  11. Aperion's Avatar
    Quote Originally Posted by Gouranga
    By treating a wheel as a single object/cylinder you mean just the rotation part, or that the whole wheel won't be made of nodes and beams any more?
    Would it be possible to make reaction torque act at correct position?
    Just the rotation part, they will still be made of nodes, but not really beams. Interacting with the cylinder will be done with nodes. The reason I started with the slidenodes in this project is because they are very similiar in concept. instead of a beam, we have an angle about an axis that determines where the node should be. Then a "beam" of sorts is created to apply forces to move the node to where it should be. The only difference between this and slide nodes is how the position is calculated. One uses a line between two points in space, another uses a radius, axis, and angle offset.

    I am not 100% set in stone that doing away with all the beams of the wheel is the way to go. But that is something that I think will need to be refined with user input once it is useable.
  12. atv_123's Avatar
    Now since you are using slide node calculations (sort of) for the wheel nodes on a cylindrical face, I am assuming that the nodes are almost going to be reacting to the cylinder's surface (the entire surface) as a rail? So in other words, with no forces acting on a particular node, it would have the freedom to go pretty much anywhere on the surface of the cylinder almost like it was riding a rail, except the whole surface of the cylinder is now, if unrolled, a 2 dimensional rail, and when rolled, essentially a 3 dimensional rail for which the node con move about. Then some added calculations come into play and keep all the nodes in their respective places to correctly form a wheel.
    This is how it sounds like it is going to work? (to me at least)

    Also, would it be possible to add more nodes width wise to the wheel? Perhaps to better aid in more realistic distribution of weight for traction and better reactions with the ground. Also leading up to my next question.

    If so then is this cylindrical entity just calculated by the program or is it something that we can define by an extremely simple mesh?
    For instance, if I want a motorcycle wheel I go into blender, make a torus, export it, define it as the node guide in the wheel section, define width of the wheel in meters, then define how many nodes I want the wheel to be comprised of width wise... for this sake I will say 6 nodes. Then the wheel calculations will see the mesh I have supplied and apply the necessary calculations to have the nodes follow that structure for a round wheel unlike all the square wheels we have on here now.

    None of this may be right, but it is just what I was thinking at the time.
  13. bonami2's Avatar
    great work!!!
  14. EJD's Avatar
    This stuff sounds incredible, are you still working on it at this point? Just curious

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