• Advertisement
Sign in to follow this  

Unity Component Entity Model Without RTTI

This topic is 2225 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm writing my own component entity model in C++. At the moment, it is somewhat similar to the framework used for Unity Scripting (particularly in C# with templates). Since I'm still in the early phases of the project, I just used type info to handle the type based retrieval of components like so:


template<class T> T * getComponent() {
for (int i = 0; i < componentList.size(); ++i) {
if (typeid(*componentList) == typeid(T)) {
return componentList;
}
}
return NULL;
}


However, RTTI (along with exceptions) is typically best left disabled in frameworks and engines if possible. What would you recommend for a minimalist way to get this functionality for components only? I'm willing (and hoping) to use the preprocessor to declare classes and assign them a "type id" kept inside the components themselves. The tricky issue is that this must also support subclasses. So if I call getComponent on a base class it must also return a subclass if it is found.

Is a 32 bit type id determined at compile time my best option here? Any tips from people who have implemented the thing themselves?

Share this post


Link to post
Share on other sites
Advertisement
What I have typically seen is that there is a unique numeric value assigned to each family of components. You can assign this value either by doing it at compile-time in your code or by using some factory/class registration mechanism that handles the assignment at run-time.

Share this post


Link to post
Share on other sites

#define ADD_RTTI(BASE_TYPE, ID) public: enum { kTypeId = ID; }; bool isDerivedFrom(uint32_t nodeType) const { return nodeType == kTypeId ? true : BASE_TYPE :: isDerivedFrom(nodeType); }

class Base
{
public:

enum { kTypeId = 0; }

virtual bool isDerivedFrom(uint32_t nodeType) const { return nodeType == kTypeId; }

template<typename T>
T* asType()
{
return isDerivedFrom( T::kTypeId ) ? (T*)this: 0;
}
template<typename T>
const T* asType() const
{
return isDerivedFrom( T::kTypeId ) ? (const T*)this: 0;
}
};

class Foo : public Base
{
ADD_RTTI(Base, 1);
};

class Bar : public Foo
{
ADD_RTTI(Foo, 2);
};
void rttiTestBar(Base* obj)
{
Bar* bar = obj1->asType<Bar>();
if(bar )
{
std::cout << "obj is Bar\n";
}
else
{
std::cout << "obj is not Bar\n";
}
}
void rttiTestFoo(Base* obj)
{
Foo* foo = obj1->asType<Foo>();
if( foo )
{
std::cout << "obj is Foo\n";
}
else
{
std::cout << "obj is not Foo\n";
}
}
int main()
{
Base* obj1 = new Foo();
Base* obj2 = new Bar();
rttiTestFoo(obj1);
rttiTestBar(obj1);
rttiTestFoo(obj2);
rttiTestBar(obj2);
delete obj1;
delete obj2;
return 0;
}

Share this post


Link to post
Share on other sites
I use this solution:


inline unsigned int new_id()
{
static unsigned int previous_id = 0;

++previous_id;
return previous_id;
}

template< class Type >
class id_container
{
public:
const static unsigned int value;
};
template< class Type >
const unsigned int id_container< Type >::value = new_id();

template< class Type >
unsigned int type_id()
{
return id_container< Type >::value;
}


Keep in mind though that this won't work across dll boundaries, and you should make the new_id() function thread safe if you want to use type_id in mutliple threads.

Share this post


Link to post
Share on other sites
Simliar to GorbGorb's solution:

Code:

template < typename T >
inline unsigned int GetRTTI()
{
static char s_rtti;
return &s_rtti;
}


Pro:
One of the quickest implementations ever. Don't have to write much at all.
Fast comparisons.
Low memory overhead

Con:
RTTI values are not absolute and will vary with memory layout. Tracking bugs between different code executions may be difficult.
May want more info other than a memaddress.

Share this post


Link to post
Share on other sites

class TypeId {
public:
virtual unsigned getTypeId() const = 0;

template<class Type>
bool isInstanceOf() const {
return getTypeId() == Type::getClassTypeId();
}
};

template<class Type, class GUID>
class AcquireTypeId : public virtual TypeId {
public:
unsigned getTypeId() const {
return GUID;
}

static unsigned getClassTypeId() {
return GUID;
}
};

//
// Elsewhere!
//

class Component : public virtual TypeId {
/* Stuff */
};

class SpecificComponent
: public Component
, public AcquireTypeId<SpecificComponent, 0xF5B30CDF> {
};


Advantages:
+ Identifiers are static
+ No macros
+ Virtual inheritance allows for components to be written in script

Disadvantages:
- Unable to determine parent-child relationships
- Virtual inheritance
- No macros and no names; just a bunch of numbers
o V-table lookup required

Though my design can be improved by embedding the type-info with the object; thus avoiding the virtual inheritance and v-table lookup...

Share this post


Link to post
Share on other sites
This is my implementation of your entity class:


template< class Type >
void destruct_function( void *obj_mem )
{
static_cast< Type* >( obj_mem )->~Type();
}

class entity
{
public:
~entity()
{
for( auto it = components.begin() ; it != components.end() ; ++it )
( *it->first )( it->second );
}
template< class Type >
Type *query()
{
auto it = components.find( &destruct_function< Type > );
if( it != components.end() )
return static_cast< Type* >( it->second );
else
return 0;
}
private:
std::map< void (*)( void * ) , void * > components;
};

Share this post


Link to post
Share on other sites
Just for some food for thought: it's entirely possible to implement a component/entity system without even providing a "get child component by type" function whatsoever wink.gif -- getting a component by type is just one way that you can choose use a component/entity system, with it's own robustness/predictability/maintenance pros/cons.

Share this post


Link to post
Share on other sites

Just for some food for thought: it's entirely possible to implement a component/entity system without even providing a "get child component by type" function whatsoever wink.gif -- getting a component by type is just one way that you can choose use a component/entity system, with it's own robustness/predictability/maintenance pros/cons.

Would you mind clarifying on that point? Would you instead get a component by instance id? Is what you're suggesting use tables in someway?

Share this post


Link to post
Share on other sites

Would you mind clarifying on that point? Would you instead get a component by instance id? Is what you're suggesting use tables in someway?


You could have lists that consist of all the components of a particular type for all the entities that have that component. Then you would ask that list "Give me the component for entity id=1234".

So with that way, the entities don't actually store the components - instead all the components of one type are stored together. I think this is what the Artemis framework does.

Since most logic would generally iterate over all components of one type, rather than all components of one entity, that kind of memory layout is more favorable for reducing cache misses.

Share this post


Link to post
Share on other sites
[quote name='Hodgman' timestamp='1324860026' post='4897366']Just for some food for thought: it's entirely possible to implement a component/entity system without even providing a "get child component by type" function whatsoever wink.gif -- getting a component by type is just one way that you can choose use a component/entity system, with it's own robustness/predictability/maintenance pros/cons.
Would you mind clarifying on that point? Would you instead get a component by instance id? Is what you're suggesting use tables in someway?[/quote]It depends on what your use-cases are for the "[font=courier new,courier,monospace]GetComponent<T>()[/font]" function, but I'll use an example to illustrate what I assume to be some common use cases:
* We're writing a "rocket launcher" component.
* When firing, it searches it calls [font=courier new,courier,monospace]parent->GetComponent<Transform>()[/font] in order to know where to spawn the rocket from.
* Rockets have a chance of mis-firing, which does damage to the holder - when this happens, it calls [font=courier new,courier,monospace]parent->GetComponent<Health>()[/font] to know where to apply the damage.

The user of the system is now happy that when they add a rocket launcher to an entity, it magically knows from where it should fire, and where it should apply "mis-fire" damage.

In my opinion, the above magic is exactly what makes this design a completely awful piece of architecture -- it makes the software engineering part of my brain feel dirty for hiding known dependencies away under an abstraction in order to achieve spooky action at a distance, which is never a good thing when it comes to being able to reason about the state and interactions in your program.
It also has the problem of enforcing the there can only be one philosophy onto the user -- each entity can only have one transform and one health component -- which may seem like a trivial burden at the time of writing, but at some point your users will find a reason for there to be two of something, and will be forced to construct ungracious work-arounds involving several entities cooperating to function as one "entity".

All of these engineering taboos can be easily avoided if the rocket launcher is simply told in advance which health/transform components it is going to be interacting with, instead of acquiring them by magic (type). This could simply be done by giving the rocket launcher component some properties that the user can set, which contain the names of the linked components.

Another example of how you can connect them is during construction, e.g. in the "entity is a vector<component*>" abstraction, you could write something like this:
Transform* transform = new Transform();
Health* health = new Health();
entity->Add( transform );
entity->Add( health );
entity->Add( new RocketLauncher(transform, health) );

N.B. these ideas also translate over to the "entity is an int, and systems are a map<int,T>" abstraction.

Share this post


Link to post
Share on other sites

All of these engineering taboos can be easily avoided if the rocket launcher is simply told in advance which health/transform components it is going to be interacting with, instead of acquiring them by magic (type). This could simply be done by giving the rocket launcher component some properties that the user can set, which contain the names of the linked components.
Seconded.

Share this post


Link to post
Share on other sites
Seems like the rocket launcher would best be modeled as its own entity in a child-parent relationship with the other - it seems odd to me to have a RocketLauncher component. That would like having a Sword component that you add to an NPC entity.

And I'm trying to think of a scenario where the "there can only be one" problem isn't better dealt with by having separate entities. An entity with two transforms doesn't really make sense. I don't have that much experience in this area, so perhaps I haven't thought it through enough?

Share this post


Link to post
Share on other sites

Seems like the rocket launcher would best be modeled as its own entity in a child-parent relationship with the other - it seems odd to me to have a RocketLauncher component. That would like having a Sword component that you add to an NPC entity.

And I'm trying to think of a scenario where the "there can only be one" problem isn't better dealt with by having separate entities. An entity with two transforms doesn't really make sense. I don't have that much experience in this area, so perhaps I haven't thought it through enough?


That is how I have seen it often modelled in the past. Typically the rocket launcher entity contains a component called "EquippedBy" or "UsedBy" that holds a reference to the using entity when equipped. So when the rocket launcher's fire logic is invoked, if it misfires or properly fires, you know both the entity to apply the misfire damage to as well as the location of where the shot originates.

The benefit of it being treated as a separate entity is that if you ever wish to model this launcher in a preview frame or want to animate it being dropped in favor of another weapon, you can do so by simply dropping the equipped by component from the entity. The rocket continues to hold onto it's mesh and other components as a free standing entity in the game world. Additionally when you want to animate death sequences and animate the dropping of the gun when the player dies, you can easily do so by again removing a single component from the weapon entity.

Share this post


Link to post
Share on other sites

Seems like the rocket launcher would best be modeled as its own entity in a child-parent relationship with the other - it seems odd to me to have a RocketLauncher component. That would like having a Sword component that you add to an NPC entity.
The underlying point about hidden dependencies being bad engineering practice remains, regardless of the actual example content...
Actually, you can even ignore the "there can only be one" advice, and the point about dependencies still remains.
And I'm trying to think of a scenario where the "there can only be one" problem isn't better dealt with by having separate entities. An entity with two transforms doesn't really make sense.[/quote]It's the same as the Singleton pattern. At the time you assume that "there can only be one" isn't going to get in the way, even though there's actually no requirement for you to implement that constraint. Adding a constraint that isn't required isn't often a good idea - all it's going to do is box future work into a constrained framework for no reason, other than laziness in the present... but if you think using singletons is a good design... ;p ;)

As for multiple transforms - I'm working on a sports game at the moment where each player is made up of over 50 transforms. Different parts of the code need to connect to different ones - the "look at" component connects to the head, the "catch"/"ball" components want to connect to the hands, the AI wants to connect to the feet, player-interaction actions want to connect different parts of different players together...
You could alternatively implement this by having each player own a "root transform" (which is a transform struct) and a "transform hierarchy" (which is an array of transform structs), or by treating skeletons as a special case that shouldn't be handled the same as other transforms, but then I've got to implement several extra components (and a whole bunch of special case logic) instead of just using the existing, simple, system.

This all also depends on what an entity means to you. If an entity is a single "prop", that you can easily instantiate, then yeah anything you want to be able to spawn by itself in one go should be an entity.
But what about when I want to spawn a monster holding a rocket, or a car with 4 wheels? Suddenly I've got to create two or five entities in order to create my one logical "prop" --- so you work around this by adding another concept of "templates" or "pre-fabs", which are collections of entities that you can spawn together in one go. Ok, problem solved, no big deal, right?
However, you can also solve this with a smaller framework if you don't implement the "there can only be one" constraint, and you also say that "entity is a component". If you do this, then you've got all the same benefits you had before (there's nothing you could've made before that you can't make now), you're violating less engineering principles, and you get your "pre-fab" system for free (a designer can make a "rocket monster" entity, which is made up of a "monster" entity and a "rocket" entity, with their internal components pre-linked to each other - when the monster dies, you can keep the rocket entity around).

Share this post


Link to post
Share on other sites

As for multiple transforms - I'm working on a sports game at the moment where each player is made up of over 50 transforms. Different parts of the code need to connect to different ones - the "look at" component connects to the head, the "catch"/"ball" components want to connect to the hands, the AI wants to connect to the feet, player-interaction actions want to connect different parts of different players together...
You could alternatively implement this by having each player own a "root transform" (which is a transform struct) and a "transform hierarchy" (which is an array of transform structs), or by treating skeletons as a special case that shouldn't be handled the same as other transforms, but then I've got to implement several extra components (and a whole bunch of special case logic) instead of just using the existing, simple, system.


It sounds like you are using Components = data + logic, right? (As opposed to Component = data, and Systems = logic).


However, you can also solve this with a smaller framework if you don't implement the "there can only be one" constraint, and you also say that "entity is a component". If you do this, then you've got all the same benefits you had before (there's nothing you could've made before that you can't make now), you're violating less engineering principles, and you get your "pre-fab" system for free (a designer can make a "rocket monster" entity, which is made up of a "monster" entity and a "rocket" entity, with their internal components pre-linked to each other - when the monster dies, you can keep the rocket entity around).


How does the rocket component know the monster died and the links to its health/transform component are no longer valid? What code is responsible for possibly wiring up the rocket component to another entity? Won't that code need to somehow find specific Health and Transform components for that new entity? (In which case you have the same "hidden" dependencies as you would have if the rocket was a separate entity that had a changeable parent whose Health and Transforms properties it requested - only you had to write extra code).

I'm just not yet convinced this simplifies anything.

Share this post


Link to post
Share on other sites
It sounds like you are using Components = data + logic, right? (As opposed to Component = data, and Systems = logic).
Transforms and "look at's" are just data, and the "look at system" uses both those pools of data to modify some transforms.

How does the rocket component know the monster died and the links to its health/transform component are no longer valid?[/quote]The easiest is for the rocket's links to it's "holder"/"user" to be weak links (in UML terms: an aggregation/uses link, not a composition/owns link) - when the monster is destroyed, the links are automatically broken / known to be invalid upon inspection. This is a common problem/solution in all entity systems, whether they're one-component-type-per-entity, other component-based, or even old-school-inheritance based...

You could have the rocket entity automatically transition into a 'dropped' state when it's owner link is broken, or alternatively, when creating the monster, you could manually connect it's OnDeath event source up to the rockets Drop event target. This manual connection would be made by the designer of the RocketMonster, at the same time as they were connecting the rocket's "owner" property to the monster.

What code is responsible for possibly wiring up the rocket component to another entity? Won't that code need to somehow find specific Health and Transform components for that new entity? (In which case you have the same "hidden" dependencies as you would have if the rocket was a separate entity that had a changeable parent whose Health and Transforms properties it requested - only you had to write extra code).[/quote]The point is that any links are not coded and automatic; the designer who authors the rocket monster creates the connections as data.

e.g. a quick description of the RocketMonster in Lua could look like:function CreateMonster(pools) return {
Transform = pools.transforms:Create(),
Model = pools.models:Create("monster.model"),
AI = pools.monsterAI:Create(),
onConstructed = function(e)
e.AI.location = e.Transform
e.Model.transform = e.Transform
end
} end

function CreateRocketMonster(pools) return {
Monster = CreateMonster(pools),
Rocket = CreateRocket(pools),
onConstructed = function(e)
e.Rocket.user = e.Monster
e.Monster.AI.OnDeath:Add( function(e) e.Rocket:drop() end )
end
} end
Ideally, you wouldn't have your designers writing Lua data manually though, so imagine instead that this is the output of their entity designer GUI, after they've created a "monster" entity made up of a transform/model/ai component, with the AI location linked to the transform and the model having a default path, and after they've then created a "rocket monster" entity made up of a rocket and monster entity, and with the rocket's user linked to the monster and the monster's AI component's on-death even linked to the rocket's drop event.

Share this post


Link to post
Share on other sites

However, you can also solve this with a smaller framework if you don't implement the "there can only be one" constraint, and you also say that "entity is a component". If you do this, then you've got all the same benefits you had before (there's nothing you could've made before that you can't make now), you're violating less engineering principles, and you get your "pre-fab" system for free (a designer can make a "rocket monster" entity, which is made up of a "monster" entity and a "rocket" entity, with their internal components pre-linked to each other - when the monster dies, you can keep the rocket entity around).
[/quote]

I understand this concept, but I'm struggling to understand how it translates into more complicated situations. Are the entities themselves independent, linked only by specific components? How would you go about creating an articulate physics model with this method? Say, a vehicle. Would each wheel of the vehicle be an entity with a physics component, connected to the base by an entity for the joint? Would the parent entity "own" the child entities or would they simply link the physics components together? It's cases like these that get me all confused.

Would you mind explaining how you would implement a more complicated example with say, a car or tank?

Share this post


Link to post
Share on other sites
I thought more about this, and here's how I understand it to work. Please comment/correct as you see fit:


class IComponent {
public:
// Not sure what to put in here. Maybe type information? I thought we were trying to get rid of that altogether though.
};
class Entity : public IComponent {
public:
AttachComponent( IComponent *comp );
DetachComponent( IComponent *comp );
};

class Transform : public IComponent {
...
};

class RigidBody : public IComponent {
...
};

class Joint : public IComponent {
...
};

// Create a car
class Car : public Entity {
public:
...
Create();
};

Car::Create(Vec3 pos)
{
// Create transform.
Transform *t = new Transform();
t->SetIdentity();
t->Translate( pos );
AttachComponent(t);

// Create car base
RigidBody *base = new RigidBody(t, ...);
AttachComponent(base);

// Create car wheels
RigidBody *wheels[4];
wheels[0] = new RigidBody(...);
wheels[1] = new RigidBody(...);
wheels[2] = new RigidBody(...);
wheels[3] = new RigidBody(...);
for( i=0; i<4; i++ )
AttachComponent(wheels);

// Create joints connecting the wheels to the car
Joint *joints[4];
Joint[0] = new Joint(wheels[0], base, ...);
Joint[1] = new Joint(wheels[1], base, ...);
Joint[2] = new Joint(wheels[2], base, ...);
Joint[3] = new Joint(wheels[3], base, ...);
for( i=0; i<4; i++ )
AttachComponent(joint);
}


The joints could then be destroyed and the wheels removed from the car entity, and they would still be free to bounce around the world.
Is that close?

Share this post


Link to post
Share on other sites
Would each joint still be an entity though? I guess I see your point. There is no reason to attach components to each other if you don't have a reliable way to query for a specific type (or would want to). The car still needs to have some level of ownership of the joints though, otherwise they get created and then lost in the void. How would you destroy them later? Are you suggesting that the car entity just keep specific references to what it needs rather than use some generic attachment mechanism?

Share this post


Link to post
Share on other sites
Yes, pretty much.

When you create a joint you pass it the two transforms it requires. When you create the car, you would pass it a list of associated joints, because the car needs to keep track of joints, and destroy them when it too is destroyed (given that both the wheels and the chassis will likely survive the destruction of the car itself)

Share this post


Link to post
Share on other sites
Would recommend then the car itself not create the joints, but instead merely be assigned them by whatever function creates the car? It seems to me that the car should be responsible for creating the joints and maintaining them. Otherwise the system creating the car has to worry about internal details. Do you see a benefit to doing it the former way?

Share this post


Link to post
Share on other sites
it depends how much flexibility you are going for.

I would say that a car is any entity with 'Wheel's, a 'WheeledVehicle' behaviour, and a 'VehicleController' attached. What makes it specifically a 'Car', is that it is produced by a 'CarFactory' function, that incidentally sets up an 'OnDestruct' handler to destroy the joints.

(the joints have nothing to do with the Car-as-entity, they have to do with the Car-as-wheeled-vehicle, and as such, I don't see that the Car entity needs to know or care about them)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
  • Advertisement
  • Popular Tags

  • Advertisement
  • Popular Now

  • Similar Content

    • By GytisDev
      Hello,
      without going into any details I am looking for any articles or blogs or advice about city building and RTS games in general. I tried to search for these on my own, but would like to see your input also. I want to make a very simple version of a game like Banished or Kingdoms and Castles,  where I would be able to place like two types of buildings, make farms and cut trees for resources while controlling a single worker. I have some problem understanding how these games works in the back-end: how various data can be stored about the map and objects, how grids works, implementing work system (like a little cube (human) walks to a tree and cuts it) and so on. I am also pretty confident in my programming capabilities for such a game. Sorry if I make any mistakes, English is not my native language.
      Thank you in advance.
    • By Ovicior
      Hey,
      So I'm currently working on a rogue-like top-down game that features melee combat. Getting basic weapon stats like power, weight, and range is not a problem. I am, however, having a problem with coming up with a flexible and dynamic system to allow me to quickly create unique effects for the weapons. I want to essentially create a sort of API that is called when appropriate and gives whatever information is necessary (For example, I could opt to use methods called OnPlayerHit() or IfPlayerBleeding() to implement behavior for each weapon). The issue is, I've never actually made a system as flexible as this.
      My current idea is to make a base abstract weapon class, and then have calls to all the methods when appropriate in there (OnPlayerHit() would be called whenever the player's health is subtracted from, for example). This would involve creating a sub-class for every weapon type and overriding each method to make sure the behavior works appropriately. This does not feel very efficient or clean at all. I was thinking of using interfaces to allow for the implementation of whatever "event" is needed (such as having an interface for OnPlayerAttack(), which would force the creation of a method that is called whenever the player attacks something).
       
      Here's a couple unique weapon ideas I have:
      Explosion sword: Create explosion in attack direction.
      Cold sword: Chance to freeze enemies when they are hit.
      Electric sword: On attack, electricity chains damage to nearby enemies.
       
      I'm basically trying to create a sort of API that'll allow me to easily inherit from a base weapon class and add additional behaviors somehow. One thing to know is that I'm on Unity, and swapping the weapon object's weapon component whenever the weapon changes is not at all a good idea. I need some way to contain all this varying data in one Unity component that can contain a Weapon field to hold all this data. Any ideas?
       
      I'm currently considering having a WeaponController class that can contain a Weapon class, which calls all the methods I use to create unique effects in the weapon (Such as OnPlayerAttack()) when appropriate.
    • By Vu Chi Thien
      Hi fellow game devs,
      First, I would like to apologize for the wall of text.
      As you may notice I have been digging in vehicle simulation for some times now through my clutch question posts. And thanks to the generous help of you guys, especially @CombatWombat I have finished my clutch model (Really CombatWombat you deserve much more than a post upvote, I would buy you a drink if I could ha ha). 
      Now the final piece in my vehicle physic model is the differential. For now I have an open-differential model working quite well by just outputting torque 50-50 to left and right wheel. Now I would like to implement a Limited Slip Differential. I have very limited knowledge about LSD, and what I know about LSD is through readings on racer.nl documentation, watching Youtube videos, and playing around with games like Assetto Corsa and Project Cars. So this is what I understand so far:
      - The LSD acts like an open-diff when there is no torque from engine applied to the input shaft of the diff. However, in clutch-type LSD there is still an amount of binding between the left and right wheel due to preload spring.
      - When there is torque to the input shaft (on power and off power in 2 ways LSD), in ramp LSD, the ramp will push the clutch patch together, creating binding force. The amount of binding force depends on the amount of clutch patch and ramp angle, so the diff will not completely locked up and there is still difference in wheel speed between left and right wheel, but when the locking force is enough the diff will lock.
      - There also something I'm not sure is the amount of torque ratio based on road resistance torque (rolling resistance I guess)., but since I cannot extract rolling resistance from the tire model I'm using (Unity wheelCollider), I think I would not use this approach. Instead I'm going to use the speed difference in left and right wheel, similar to torsen diff. Below is my rough model with the clutch type LSD:
      speedDiff = leftWheelSpeed - rightWheelSpeed; //torque to differential input shaft. //first treat the diff as an open diff with equal torque to both wheels inputTorque = gearBoxTorque * 0.5f; //then modify torque to each wheel based on wheel speed difference //the difference in torque depends on speed difference, throttleInput (on/off power) //amount of locking force wanted at different amount of speed difference, //and preload force //torque to left wheel leftWheelTorque = inputTorque - (speedDiff * preLoadForce + lockingForce * throttleInput); //torque to right wheel rightWheelTorque = inputTorque + (speedDiff * preLoadForce + lockingForce * throttleInput); I'm putting throttle input in because from what I've read the amount of locking also depends on the amount of throttle input (harder throttle -> higher  torque input -> stronger locking). The model is nowhere near good, so please jump in and correct me.
      Also I have a few questions:
      - In torsen/geared LSD, is it correct that the diff actually never lock but only split torque based on bias ratio, which also based on speed difference between wheels? And does the bias only happen when the speed difference reaches the ratio (say 2:1 or 3:1) and below that it will act like an open diff, which basically like an open diff with an if statement to switch state?
      - Is it correct that the amount of locking force in clutch LSD depends on amount of input torque? If so, what is the threshold of the input torque to "activate" the diff (start splitting torque)? How can I get the amount of torque bias ratio (in wheelTorque = inputTorque * biasRatio) based on the speed difference or rolling resistance at wheel?
      - Is the speed at the input shaft of the diff always equals to the average speed of 2 wheels ie (left + right) / 2?
      Please help me out with this. I haven't found any topic about this yet on gamedev, and this is my final piece of the puzzle. Thank you guys very very much.
    • By Estra
      Memory Trees is a PC game and Life+Farming simulation game. Harvest Moon and Rune Factory , the game will be quite big. I believe that this will take a long time to finish
      Looking for
      Programmer
      1 experience using Unity/C++
      2 have a portfolio of Programmer
      3 like RPG game ( Rune rune factory / zelda series / FF series )
      4 Have responsibility + Time Management
      and friendly easy working with others Programmer willing to use Skype for communication with team please E-mail me if you're interested
      Split %: Revenue share. We can discuss. Fully Funded servers and contents
      and friendly easy working with others willing to use Skype for communication with team please E-mail me if you're interested
      we can talk more detail in Estherfanworld@gmail.com Don't comment here
      Thank you so much for reading
      More about our game
      Memory Trees : forget me not

      Thank you so much for reading
      Ps.Please make sure that you have unity skill and Have responsibility + Time Management,
      because If not it will waste time not one but both of us
       

  • Advertisement