Connect node with custom class? (ISceneNode User data)

[hybrid]

pointers are not int on 64bit machines Things like this will prohibit the inclusion for an indefinite time...

[sudi]

You could do the following:

Code: Select all

class CSceneCollector : public irr::scene::ISceneNodeAnimator
{
      public:
      CSceneCollector(void) : UserData(NULL){}
      ~CSceneCollector(void){if (UserData)UserData->drop();
      void  animateNode (ISceneNode *node, u32 timeMs){}
      ISceneNodeAnimator *  createClone (ISceneNode *node, ISceneManager *newManager=0)
      {
            CSceneCollector* anim = new CSceneCollector;
            anim->setUserData(UserData);
            node->addAnimator(anim);
            anim->drop();
      }
      ESCENE_NODE_ANIMATOR_TYPE  getType () const
      {
            return NODE_USER_DATA_ANIMATOR; //some unused anim number
      }
      Unit* getUserData(void){return UserData;}
      void setUserData(Unit* data)
      {
            if (data == UserData)
                  return;
            if (UserData)
                  UserData->drop();
            UserData = data;
            if (UserData)
                  UserData->grab();
      }
protected:
      Unit* UserData;
};

in your collsion code:

Code: Select all

//when creating Your Node
CSceneCollector* anim = new CSceneCollector;
anim->setUserData(YOUR_UNIT);
Node->addAnimator(anim);
anim->drop();
...
//later in your collision code
.....
//found sceneNode Node
irr::core::list<ISceneNodeAnimator*> animators = Node->getAnimators();
//check if node has userdata
Unit* UserData = NULL;
irr::core::list<ISceneNodeAnimator*>::ConstIterator it = animators.begin();
while (it != animators.end())
{
      if ((*it)->getType() == NODE_USER_DATA_ANIMATOR)
      {
            UserData = ((CSceneCollector*)(*it))->getUserData();
            break;
      }
      it++;
}
if (UserData != NULL)
{
      //do ur magic
}
....

EDIT: sry only read the first page obviously u already found a good way

[Darktib]

Hum yes its a good idea. Moreover I don't use animator, so I could just have to retrieve the only animator I could set to nodes...

For me, it could be a very good compromise, but I think if you use a lot of animator you always have to do a search...

[sudi]

well u could always set ur userdata animator first. then u can cancel the search after the first animator. which is retrived by begin()

[Strong99]

but searching 10 animators is less work than 500 scenenodes

[Dan911]

I think irrlicht needs built in userdata, i mean in latest Irredit there is even a tab for it, but it says coming soon.

[sudi]

Idon't think that it is a good idea to a void* UserData pointer into a ISceneNode. Isn't there this new CollisionCallbackClass? Maybe that can be used to retrive Your userdata.

[Darktib]

For collisions, but for picking ? Or for other stuff ?

[sudi]

Isn't picking done by the CollisionManager???well so a good time for the CollisionCallback::rayHit....well and what is there besides that?

[Darktib]

Problem : picking is for select entities...
Callback or not, I think only a void* in the scene node or in an animator will provide decent performances.

[sudi]

a void* in an animator doesn't make sense at all...and in a scenenode hmm.
Its a graphics engine not a game engine. You should keep all game related stuff out of irrlicht itself.

[Darktib]

That's I am doing...
But if you have 2500 scene node in the scene, and you picked a scene node, a search won't be efficient...

[sudi]

ähh then use my animator approach

[Dan911]

but irrlicht isnt just a rendering engine sudi, it contains collision detection, pre made user cameras, along with other things that arent usually in a rendering engine. I think adding user-date is a great idea, and those who do not want to use it don have to .

[Dorth]

oh ffs
Just use a std::map, one side the pointer to your node as the key and the pointer to your data as, well, your data. Simple, small and fast. End of story.

-EDIT-
P.S.: Dan911: The fact Irrlicht is taking so much time on secondary stuff like collision which it doesn't do well enough because it isn't a proper physic engine nor contain one is a problem in itself. It takes time away from the prior focus of Irrlicht, aka, to be a powerful and simple graphic engine on a wide range of system. A good number of people (I'd wager the majority) replace/use on top a custom library/their own system as soon as they start a serious project. There might be some exception, but I'd wager it's still not the norm. So please, while I won't actively march against those features in Irrlicht, can they stop being brought in debates as arguments to bring even more? Unless the definition of goals of Irr is changed, this is not it.