Setting and getting the name of an actor

Viktor

27-11-2009 06:39:32

Can I do this to set the name of an actor?

myActor = new NxOgre::Box(1, 1, 1);
myActor->setName(NxOgre::String("myActorName"));
myBody = mRendersystem->createBody(myActor ,position,meshFileName);


And how can I get the name back? Is there some method like
myActor->getActorName()

Thanks in advise

betajaen

27-11-2009 09:57:08

Not easily in BloodyMess, Detritus you can.

Names aren't really important in NxOgre, they are used with debugging mostly with the Visual Debugger. If you want to set a name to an Actor/Body then compare against it later i.e. in volume or raycast, there are better and faster solutions.

LucaMoller

28-11-2009 04:07:06

Can you give us any hint about these other solutions?

betajaen

28-11-2009 10:05:12

The most efficient way is just comparing pointers.

mBall == actor

LucaMoller

28-11-2009 19:31:39

Thats not eficient in the situations I was thinking.
In a collision_callback for example, if you want to know what actor is colliding you can write information on its name, like index, player number, etc... You get its name and you come to know many things about it, you can identify the object that physic actor is related and do what you want with it. You wont check its pointer against all physic actors pointers you have to identify what of the actor that one is...

jeremywilms

28-11-2009 22:30:56

Thats not eficient in the situations I was thinking.
In a collision_callback for example, if you want to know what actor is colliding you can write information on its name, like index, player number, etc... You get its name and you come to know many things about it, you can identify the object that physic actor is related and do what you want with it. You wont check its pointer against all physic actors pointers you have to identify what of the actor that one is...


Just thought I should say:

If I were you, I would avoid that design. It won't take too long to index through all the object. The problem with that design, using the name to hold information like the index, is that the index is likely to change(provided you're using a std::vector, or something similar.). Say a developer comes along and decides to insert an object in the that vector. For some reason(there may be one), he decides it should be inserted between 0 and 1, instead of having it append on the top. All your indexes past 1 have now changed. Thus the name would be referencing the wrong object(if it even existed). Say you wanted to erase an entry at a given index, deleting the entry at index 0, will change the index of all the entries past 0.

Information such as the health and player number should be held in the player class, and not in the name of an actor.

If you really want to use that design, I suggest you store a pointer to the player class in the name, and nothing else. Everything else can be acquired through the pointer(i.e player number, etc.). Although I highly suggest you avoid it.

This is something I remember doing a long time ago w\ action-script. Not a pretty sight to see.

LucaMoller

29-11-2009 00:50:53

The index I mentioned is not a vector position.
Its something like you said... For example, for my magic system I've created a magic_manager. This manager is a class that stores lists of pointers of magic objects. Each magic object has a unique index (this index is a int variable it owns). My magic_manager has a method that returns me the magic pointer of the index i've asked for. So when I'm in the collision_callback, I read the actor name and if its like "magic 142", I ask my manager for the pointer of that magic object, like magic_manager->get_magic(142). With the returned pointer I do what I want.
Anyway, we are still using the actors name... isn't there a better way?

jeremywilms

29-11-2009 04:40:27

The index I mentioned is not a vector position.
Its something like you said... For example, for my magic system I've created a magic_manager. This manager is a class that stores lists of pointers of magic objects. Each magic object has a unique index (this index is a int variable it owns). My magic_manager has a method that returns me the magic pointer of the index i've asked for. So when I'm in the collision_callback, I read the actor name and if its like "magic 142", I ask my manager for the pointer of that magic object, like magic_manager->get_magic(142). With the returned pointer I do what I want.
Anyway, we are still using the actors name... isn't there a better way?


So you don't want to index through an array\vector of objects comparing pointers, instead you'll index through an array\vector of magicObjects' comparing each magicObject's id after making a call to each to acquire the ID?

The most efficient way(and the way it is usually done) is to index through a vector\array and compare pointers, the way you're doing it is unsafe, also, consider if you switch to another physics engine(or a new wrapper), you'll have to redesign the system if the new one doesn't have a name for each actor.

betajaen

29-11-2009 10:44:21

What you could do is and what I encourage is to sub-class OGRE3DBody (or what ever Body class your using), and add your user-data to that directly.

To tell your RigidBody apart from the others, is the getClassType() function, which you return a unique number to your class; i.e. 31337. When you encounter RigidBodies in Volumes or Raycast queries, you can use the getClassType() function to compare it to 31337, then if it is: Cast it into your own Body class then access your userdata. It's fast and straight to the point and you don't need names then.

You may need to pre-append "virtual" to line 70 of OGRE3DBody.h for this to work though. Detritus handles this sort of thing way better.

LucaMoller

29-11-2009 23:41:39

What you could do is and what I encourage is to sub-class OGRE3DBody (or what ever Body class your using), and add your user-data to that directly.

To tell your RigidBody apart from the others, is the getClassType() function, which you return a unique number to your class; i.e. 31337. When you encounter RigidBodies in Volumes or Raycast queries, you can use the getClassType() function to compare it to 31337, then if it is: Cast it into your own Body class then access your userdata. It's fast and straight to the point and you don't need names then.

You may need to pre-append "virtual" to line 70 of OGRE3DBody.h for this to work though. Detritus handles this sort of thing way better.


Yes, that sounds much better. :wink:

Viktor

02-12-2009 01:09:54

Thank you betajaen, that's a really pretty way to do that. I was starting to think if storing the pointer to the object in the actor, as a string :?, were the best way to do that.

LucaMoller

02-12-2009 02:38:28

What you could do is and what I encourage is to sub-class OGRE3DBody (or what ever Body class your using), and add your user-data to that directly.

To tell your RigidBody apart from the others, is the getClassType() function, which you return a unique number to your class; i.e. 31337. When you encounter RigidBodies in Volumes or Raycast queries, you can use the getClassType() function to compare it to 31337, then if it is: Cast it into your own Body class then access your userdata. It's fast and straight to the point and you don't need names then.

You may need to pre-append "virtual" to line 70 of OGRE3DBody.h for this to work though. Detritus handles this sort of thing way better.


I was thinking about associating many actors with one object, and, at first sight, thats a problem with the method you suggested since the information about the object would be in the sub-class of one specific actor. So I came up with the idea of storing a pointer to the object in the subclass instead of the objects variables and methods. So, for each diferent object that is related with actors you would have a sub-class of actor that would store a pointer to that type object and the same virtual function Betajaen sugested (you would do the cast the same way and get the pointer for the object you wanted after it). Doing it this way you can have many actors that refer to the same object. :wink: