Hello again everyone and thank you for your time.
I'm in the process of creating a new type of scene node and need a couple of things cleared up.
First off, while looking at the ITerrainSceneNode for example there are two classes used to create that scene node:
Interface - ITerrainSceneNode
Implementation - CTerrainSceneNode
The Interface is just a class derived from ISceneNode full of a bunch of virtual function prototypes.
However the Implementation is a class derived from ITerrainSceneNode and has the actual code for the scene node.
I don't understand why these are split like this and why it's necessary, couldn't the Interface/Implementation be combined into one class?
Second, what steps need to be taken to get the new scene node type 'registered' with the scene manager so I can call
smgr->addMyNewSceneNode() ?
Thank you all very much for your time, your help is much appreciated!
Creating A New Type Of Scene Node
Creating A New Type Of Scene Node
Dream Big Or Go Home.
Help Me Help You.
Help Me Help You.
Re: Creating A New Type Of Scene Node
Seperating the interface from the implementation is just good OO-style. First it allows hiding the ugly implementation details from the user. And the less code the user has to look at the easier is the library to use. Then it makes it easier keeping an interface intact. We can mess around in the internal interfaces more or less like we want and you still can call the public interfaces the same way without caring. Also it's actually not so trivial to have a dll which exports the real classes (unless you do it boost-style and put everything into headers you have a harder time using variable-types which have templates like irrArray, etc). Disadvantage is obviously that you can't derive from the implementation classes. But you have 2 ways around that - first is to create an object of the original type and keep a pointer to that in your class and call the functions throught that. Second way is - Irrlicht is opensource - so you can simply copy the implementations!
There are 2 answers about your second point. It depends if you need serialization or not. If you don't need that then you don't need the scenemanager to handle your class. You can create your class-object with new and add it to the scenegraph by setting a parent for the object.
If you do need serialization then you have to write a factory for your nodes. Derive from ISceneNodeFactory and add your own factory to ISceneManager with ISceneManager::registerSceneNodeFactory.
There are 2 answers about your second point. It depends if you need serialization or not. If you don't need that then you don't need the scenemanager to handle your class. You can create your class-object with new and add it to the scenegraph by setting a parent for the object.
If you do need serialization then you have to write a factory for your nodes. Derive from ISceneNodeFactory and add your own factory to ISceneManager with ISceneManager::registerSceneNodeFactory.
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Re: Creating A New Type Of Scene Node
Thank you very much! It makes complete sense now.
Lastly, If I was trying to put this into my local copy of Irrlicht & recompiling it to add my new scene nodes in, is there a 'special file' where all the default scene node factories are registered with the scene manager? Or then how are the default nodes attached so the programmer can call smgr->addMeshSceneNode() etc..
Thank you again.
EDIT: In the Interface files, next to the virtual function prototypes, there is something I've never seen before
Sometimes it's const, sometimes it's not. Can you help me understand what this does and why it's here?
Lastly, If I was trying to put this into my local copy of Irrlicht & recompiling it to add my new scene nodes in, is there a 'special file' where all the default scene node factories are registered with the scene manager? Or then how are the default nodes attached so the programmer can call smgr->addMeshSceneNode() etc..
Thank you again.
EDIT: In the Interface files, next to the virtual function prototypes, there is something I've never seen before
Code: Select all
const _IRR_OVERRIDE_
Dream Big Or Go Home.
Help Me Help You.
Help Me Help You.
Re: Creating A New Type Of Scene Node
Maybe i am a little stupid right now (still recovering from a cold), but i don't grasp two things:
1: Also it's actually not so trivial to have a dll which exports the real classes ...
and
2: Disadvantage is obviously that you can't derive from the implementation classes.
1: Also it's actually not so trivial to have a dll which exports the real classes ...
and
2: Disadvantage is obviously that you can't derive from the implementation classes.
Re: Creating A New Type Of Scene Node
@kklouzal: _IRR_OVERRIDE_ is a define for the new c++11 override keyword. It just adds a check that bascially tells the compiler to complain if we mess up overriding a base function. It says: This function is not just any virtual function but it's one where we override the virtual function of a base-class. The reason we have a define instead of just using "override" is that not all compilers we support have that keyword yet.
So you don't need that - it just helps to catch errors. For example when you overload a function and forget "const" but the base function _is_ const then you would create a new function instead of overloading the existing one which might lead to all kind of interesting bugs until you figure it out.
@AReichl: Something I just run into last week (r4791 of trunk didn't compile on Windows for example because I messed that up). I suppose it's because __declspec(dllexport) to export classes needs to know class-sizes. Which is more tricky once templates are involved. Although I can't really tell you why it still makes problems when I already tell the compiler which type it should use for the template. So maybe it's really another reason - I'm not deep enough into who compilers work there to really figure out the reason. But anyway - exporting classes that have member-variables which are using template classes like irr::string or irr::array should be avoided.
2. You can no longer derived for example from CGUIButton (or any other implementation class), but only from IGUIButton. It's just something you wish you could do once in a while if all you want to do is change 1-2 lines in a function or so.
So you don't need that - it just helps to catch errors. For example when you overload a function and forget "const" but the base function _is_ const then you would create a new function instead of overloading the existing one which might lead to all kind of interesting bugs until you figure it out.
@AReichl: Something I just run into last week (r4791 of trunk didn't compile on Windows for example because I messed that up). I suppose it's because __declspec(dllexport) to export classes needs to know class-sizes. Which is more tricky once templates are involved. Although I can't really tell you why it still makes problems when I already tell the compiler which type it should use for the template. So maybe it's really another reason - I'm not deep enough into who compilers work there to really figure out the reason. But anyway - exporting classes that have member-variables which are using template classes like irr::string or irr::array should be avoided.
2. You can no longer derived for example from CGUIButton (or any other implementation class), but only from IGUIButton. It's just something you wish you could do once in a while if all you want to do is change 1-2 lines in a function or so.
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Re: Creating A New Type Of Scene Node
2. You can no longer derive for example from CGUIButton (or any other implementation class), but only from IGUIButton.
Still don't totally get it. I can do
class MyGUIButton : public CGUIButton or maybe irr::gui::CGUIButton
{
...
}
Of course i have to provide the (virtual) functions, but that's the idea of an interface.
Still don't totally get it. I can do
class MyGUIButton : public CGUIButton or maybe irr::gui::CGUIButton
{
...
}
Of course i have to provide the (virtual) functions, but that's the idea of an interface.
Re: Creating A New Type Of Scene Node
You can do that in the engine, but not in application code. You only have access to the public interfaces of the engine.
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Re: Creating A New Type Of Scene Node
I still don't FULLY understand.
There is this nice project called "SpaceCombat" and the developer is doing just that.
for example
class CCitySceneNode : public CMeshSceneNode (from Irrlicht)
class CGUINoise : public CGUIImage (from Irrlicht)
class CSkyBoxSceneNode2 : public CSkyBoxSceneNode (from Irrlicht)
and some more.
Ok - i have to admit, it only works if Irrlicht is a static library (and some tricks to get it running) but it seems to work.
I also have created a small test project with ClassA in a library and ClassB : public ClassA in my main program and it linked fine.
There is this nice project called "SpaceCombat" and the developer is doing just that.
for example
class CCitySceneNode : public CMeshSceneNode (from Irrlicht)
class CGUINoise : public CGUIImage (from Irrlicht)
class CSkyBoxSceneNode2 : public CSkyBoxSceneNode (from Irrlicht)
and some more.
Ok - i have to admit, it only works if Irrlicht is a static library (and some tricks to get it running) but it seems to work.
I also have created a small test project with ClassA in a library and ClassB : public ClassA in my main program and it linked fine.