Is it really so hard to add stuff upon Irrlicht?

If you are a new Irrlicht Engine user, and have a newbie-question, this is the forum for you. You may also post general programming questions here.
wITTus
Posts: 167
Joined: Tue Jun 24, 2008 7:41 pm
Location: Germany

Is it really so hard to add stuff upon Irrlicht?

Post by wITTus »

At first, this is no rant, nor some flame or something like that. I guess that I misunderstood some important principles of the Irrlicht design and simply want some clarification. :wink:

I tried today to implement some very simple LOD feature. Of course I searched the web before I tried to reinvent the wheel, but I didn't found what I searched for so I decided to write it by myself. It was more an exercise for me than something like a real feature.

Actually, I didn't want to write much stuff from scratch... that's why I use Irrlicht. And I actually like this engine. There's much love in it :wink:. But sometimes I'm very frustrated when I intend to implement new stuff.

Like so many people before, I wanted to do some kind of solar system. Now, when I get really far, planets become small and I don't see any reason to render them at full quality. Till now I used a simple call to ISceneManager::addSphereSceneNode().

So this is what I basically tried:

I knew that I had to inherit from ISceneNode, so I did that. I implemented the required stuff and compiled. Unfortunately ISceneNode has no default constructor. And there's nothing like a ISphereSceneNode. How can I profit from the ISceneManager factory then? ISceneNode has a copy constructor... suddenly I had that genius idea:

Code: Select all

class PlanetSceneNode : public ISceneNode
{
        PlanetSceneNode::PlanetSceneNode (ISceneManager* Scene, f32 Radius)
        : ISceneNode(*Scene->addSphereSceneNode(Radius,16))
        {
        }
        virtual ~PlanetSceneNode () {
                UNDEFINED_DTOR_WARNING;
        }

        virtual void render() {
                this->render();
        }

        virtual const aabbox3d<f32>& getBoundingBox() const {
                return this->getBoundingBox();
        }
};
It didn't work and I didn't even try to figure out why, because I knew that it's a stupid rude hack. The virtual member functions are missing. Yep that's it. This means I would have to implement the create-a-sphere-functionality by myself. Ok no problem, I just opened CSphereSceneNode and looked up how it had been done. It was simple enough. Then I thought, OK, nice, I could even store multiple Meshes and quickly switch between them depending on the distance to the camera. But no, again, there was a thing which simply wasn't available for my code which uses the interface: CGeometryCreator. I'm about to come to the conclusion that inheriting from ISceneNode has not much use at all (unless you want to write something which is entirely new).

So each time I think that I've finally found the 'right design' for my class, I get another afterthought why it possibly cannot work. For example, I thought then, OK, whatever, I'll create a few instances with ISceneManager::addSphereSceneNode(), store them in my own class and switch between on render() calls and so on. But this means big overhead, and I would have to inherit from ISceneNode and implement ALL virtual functions anyways. This is would be so much unneeded code.

Very frustrating. It seems that it's a pain in the *** to build UPON existing features of Irrlicht. I would have to modify the engine each time (if I don't want to rewrite big parts of it) and recompile it. But this is utterly nonsense.

It's not the problem for me to actually do the LOD stuff - I would surely get it done somehow. But I'm rather speaking about the problem of building upon Irrlicht without the need of modifying the engine itself. I don't like to change the engine code, I have a bad feeling about it.

So, please help me.
What am I doing wrong here?
What is the 'correct' way to do it?

Thanks for reading!
rogerborg
Admin
Posts: 3590
Joined: Mon Oct 09, 2006 9:36 am
Location: Scotland - gonnae no slag aff mah Engleesh
Contact:

Re: Is it really so hard to add stuff upon Irrlicht?

Post by rogerborg »

You're writing a custom scene node, so the implementation is entirely up to you. You've very welcome to copy-and-paste any bits of the Irrlicht code that you want, to make your job easier.

It would take you, what, 5 minutes to copy CGeometryCreator into your user app? Job done, move on.

Are you suggesting that CGeometryCreator could and should be exposed to user apps through a public API?
Please upload candidate patches to the tracker.
Need help now? IRC to #irrlicht on irc.freenode.net
How To Ask Questions The Smart Way
arras
Posts: 1622
Joined: Mon Apr 05, 2004 8:35 am
Location: Slovakia
Contact:

Post by arras »

I'm about to come to the conclusion that inheriting from ISceneNode has not much use at all
ISceneNode like all classes starting with I provide common interface for whole engine. They like skeleton on to which you add rest of the stuff. Doesn't matter what it is, once it is inherited from ISceneNode you can be sure Engine is gonna employ it in defined way. Like calling onAnimate() each frame for example. Thats why most or in this case all functions are pure virtual and you have to implement them yourself.
wITTus
Posts: 167
Joined: Tue Jun 24, 2008 7:41 pm
Location: Germany

Re: Is it really so hard to add stuff upon Irrlicht?

Post by wITTus »

rogerborg wrote:You're writing a custom scene node, so the implementation is entirely up to you. You've very welcome to copy-and-paste any bits of the Irrlicht code that you want, to make your job easier.

It would take you, what, 5 minutes to copy CGeometryCreator into your user app? Job done, move on.
You can't be serious! This is against any common design philosophy. Why should I copy and paste so much source code if it is already written and compiled? Why using OOP then and why using a library at all?? I don't want to rape Irrlicht, I'd like to extend it...
rogerborg wrote:Are you suggesting that CGeometryCreator could and should be exposed to user apps through a public API?
Absolutely. That's a very good idea.
arras wrote:Like calling onAnimate() each frame for example.
Of course! I already wrote lots of animators for the engine and it works very well. Please don't get me wrong! I really want to use the features provided by Irrlicht. And I use them. But, often, to make them fit my needs, I'm hindered to do so. The problem is, that some of the interfaces are a bit too simplified IMO.

Another example: The cameras.

I tried to build upon ISceneNodeCameraFPS (as it provided the functionality I needed) which was completely pointless, till I realized that it was impossible with the common interface. To extend it, I would have had to copy&paste hundreds of lines of code of the lib source.

The camera architecture has been apparently significantly improved since Irrlicht 1.4. However, I hope you know what I mean so far.
wITTus
Posts: 167
Joined: Tue Jun 24, 2008 7:41 pm
Location: Germany

Post by wITTus »

Hm, on the other hand I just found ISceneManager::addSphereMesh(). This would make the CGeometryCreator probably useless in the public API. Maybe the engine is simply lacking a few more examples...
hybrid
Admin
Posts: 14143
Joined: Wed Apr 19, 2006 9:20 pm
Location: Oldenburg(Oldb), Germany
Contact:

Post by hybrid »

Well, you cannot expect to get an example for every API method we provide. That's a job for the API docs, just browse them here:
http://irrlicht.sourceforge.net/docu/index.html
Inheritance and information hiding won't work at the same time together. The actual implementations of the interfaces provided by Irrlicht are completely hidden, no inheritance possible (except if you add your code to the library as well). Some minor exceptions can be found in the S*.h files in inlucde/. The only publicly available classes are the interfaces, you have to derive from those (and maybe take some code from the C* files from inside the library by copying them into your code).
Katsankat
Posts: 178
Joined: Sun Mar 12, 2006 4:15 am
Contact:

Post by Katsankat »

"you cannot expect to get an example for every API method we provide".
You should.
The doc is a must... But how many times were people forced to search (looong search) in the forum/google... A good API doc is the one of PHP. EVERY page has example code, with syntax highlighting (random example) and this makes an enormous difference in termes of time and quality. Now for the solution, being a full time web development teacher I could help ... If needed.
wITTus
Posts: 167
Joined: Tue Jun 24, 2008 7:41 pm
Location: Germany

Post by wITTus »

Katsankat wrote:
hybrid wrote:you cannot expect to get an example for every API method we provide".
You should.
I don't think so. The API reference is detailed enough IMO. But some more examples would be very helpful to understand the basic design principles of the engine. Last summer I did all tutorials and it lacked clearly a good camera tutorial. I struggled many days around with the engine just to find out that I better shouldn't use the FPS camera because I'm unable to add code to it, but instead calculate movement of my objects and then write an animator which changes the behaviour of a simple camera (- not too sure if this is still the best way with v1.5 though).

The engine lacks some more "how to do useful stuff" tutorials. Indeed, it's nice to be able to load a Q3 map with one call... but that's not very helpful at all. The best tutorial is the CustomSceneNode because it teaches you exactly how to integrate your own code with Irrlicht. Good tutorials like that are the best way to ensure that users will actually use the engine and not only write a wrapper around it...

Besides, a public complete list of scene nodes, created by Irrlicht users would be very cool. :wink:
zillion42
Posts: 324
Joined: Wed Aug 29, 2007 12:32 am
Location: Hamburg, Germany

Post by zillion42 »

wow, if I wouldn't have been bored, I also probably wouldn't have read this thread... looks like my past hour problems and my code...

well anyway as you may or may not know I was doing that irrSolarSystem thing and just the last 3 days, after finishing some other things, I looked into that again and added a few more features... Most importantly I changed the proportion from planet size to orbit diameter to real proportion (it's not impossible !!!) changed almost all other values to real values (I've got a gravity Simulation for the camera, and I think I'll post more details about that soon because that is all super fine) and got annoyed about the addSphereMesh in combination with createMeshWithTangents() method. It's probably Ok for normal spheres but ie. mercury reports boundingbox extent of: 0.048799999...
And I dont know which or why it is after all but now my spheres are one side full lit and other side completly dark.. The small ones are otherwise normal but saturn and jupiter also have hard edges. The normals were always broken even in the old scale, even after importing all thinkable kinds of spheres that cinema4d exports in all thinkable formats: I tried each 3ds, obj, collada, b3d with tetraeder, hexaeder, oktaeder, ikosaeder and c-60 buckyball... and after re-export as obj from maya... looks like the normal map is working kind of less than before, but the lightning problem...
So my first thought and 2 tries were...

Code: Select all

smgr->getMeshManipulator()->recalculateNormals(planetMesh);
and
planet->setMaterialFlag(video::EMF_NORMALIZE_NORMALS, true);
My second thought was playing with light attenuation and radius, for attenuation I have no idea how the values are interpreted... I tried from -1 to 600:

Code: Select all

//add light---------------------------------------------------------------------------------------- 
	scene::ILightSceneNode* light = smgr->addLightSceneNode(0,
		core::vector3df(0,0,0),
		video::SColorf(1.0f,1.0f,1.0f),8000.0f);

	video::SLight ldata = light->getLightData();
	ldata.Attenuation = core::vector3df(100,100,100);
	ldata.AmbientColor = video::SColorf(0.1f,0.1f,0.1f);
	light->setLightData(ldata);

and while looping

light->setRadius((sunDistanceKM/scaleF)*1.2);
didn't work, but I surely haven't tried all yet...

Funny, is I was just today reading the CGeometryCreator.cpp, anyway let's team up for at least a good sphere solution...
And I saw some ultra amazing planetary LOD system for terrains on the planet using libnoise and more or less a cube-sphere... check out irrelite and yass I think it's called, also there is realistic atmospheric scattering as shader solution somewhere out there, lots of things to explore. And what I found yesterday not irrlicht...
http://orbit.medphys.ucl.ac.uk/
but also nice...

time to stop
later

EDIT:
btw in 1.5, just bind target and Rotation... like
bindTargetAndRotatio() <--- I think
and otherwise I think the tutorials are a lot better than what I found for other engines... :shock:
EDIT2:
After reading again I agree and disagree... like rogerborg said you can copy paste bits and pieces from everywhere to your own scene node, or you could simply copy whole modified scene nodes inside the irrlicht source with slightly different names but mainly same implementation... I agree it give a weird feeling and if everyone would be doing it no one would be able to run other ppl's source anymore, without getting their full irrlicht source aswell and recompiling the dll. Thats imo why there are so many irr split groups.
The only time I ever put my fingers on the source was when either irrPhysix or newton wasn't working with some terrain something (forgot) in a method that was already exposed in the api (otherwise i would have never found it) so I simply changed the method slightly and repastet it in the same document .cpp and .h having my own and the old version in the same file, then I called my version instead.. and it was working... to my suprise at that time... It would get extremly difficult, god forbid, if people like me or especially many people would check in stuff like that on the svn. The same method in 20 variations next to each other... how wonderfull, but see it from that point of view... you can't make it right for everyone anyway and the way it is now, it's extremely flexible.
just my 10 cents...
EDIT3:
being able to read is a clear advantage... I thought you were talking about the normal not being able to set rotate on the fps camera directly by setRotation() problem, which is being asked about 1.2 times daily in the forum I guess, but you were actually talking about extending the fps camera class. I was thinking that aswell :) or, again, copying irrlicht code to my own...resistance is futile... is it so difficult to extend and/or lengthy source ? How about again, making your own ? From mouse delta with mouse and rotate interfaces in your standard camera derived class ? well design concept or not, if you really make something serious after all you can still strip irrlicht for all unecessary and make your 'semi own' version... but I think that exactly is already part of the design concept...
rogerborg
Admin
Posts: 3590
Joined: Mon Oct 09, 2006 9:36 am
Location: Scotland - gonnae no slag aff mah Engleesh
Contact:

Post by rogerborg »

While you chaps were talking about what we could collectively do, I've exposed CGeometryCreator (as IGeometryCreator) through ISceneManager::getGeometryCreator(), in SVN 2205 on the trunk. :P
Please upload candidate patches to the tracker.
Need help now? IRC to #irrlicht on irc.freenode.net
How To Ask Questions The Smart Way
Ion Dune
Posts: 453
Joined: Mon Nov 12, 2007 8:29 pm
Location: California, USA
Contact:

Post by Ion Dune »

rogerborg wrote:While you chaps were talking about what we could collectively do, I've exposed CGeometryCreator (as IGeometryCreator) through ISceneManager::getGeometryCreator(), in SVN 2205 on the trunk. :P
I can't get 2205 to compile - seems like the file "IGeometryCreator.h" is missing.
rogerborg
Admin
Posts: 3590
Joined: Mon Oct 09, 2006 9:36 am
Location: Scotland - gonnae no slag aff mah Engleesh
Contact:

Post by rogerborg »

Image

You know, that would have gone so much more smoothly if I hadn't screwed up the SVN commit... ;)

The unit test got missed as well (I could swear I...). I'll get it added tonight, thanks for letting me know.
Please upload candidate patches to the tracker.
Need help now? IRC to #irrlicht on irc.freenode.net
How To Ask Questions The Smart Way
wITTus
Posts: 167
Joined: Tue Jun 24, 2008 7:41 pm
Location: Germany

Post by wITTus »

rogerborg wrote:While you chaps were talking about what we could collectively do, I've exposed CGeometryCreator (as IGeometryCreator) through ISceneManager::getGeometryCreator(), in SVN 2205 on the trunk. :P
Wouldn't it be better to merge the "make a cube stuff" from CCubeSceneNode.h to CGeometryCreator then?

See this thread.
hybrid
Admin
Posts: 14143
Joined: Wed Apr 19, 2006 9:20 pm
Location: Oldenburg(Oldb), Germany
Contact:

Post by hybrid »

wITTus wrote:
rogerborg wrote:While you chaps were talking about what we could collectively do, I've exposed CGeometryCreator (as IGeometryCreator) through ISceneManager::getGeometryCreator(), in SVN 2205 on the trunk. :P
Wouldn't it be better to merge the "make a cube stuff" from CCubeSceneNode.h to CGeometryCreator then?

See this thread.
So you made the necessary patch already? Sorry, seems I've missed it then, could you please give a link?
wITTus
Posts: 167
Joined: Tue Jun 24, 2008 7:41 pm
Location: Germany

Post by wITTus »

Well, no. Because I didn't expect that my idea would've been accepted so fast. But I see, hybrid ist ein Mann der Tat! :D

So I just wrote it

One problem remains, though:

Code: Select all

wittus@hell ~/Projects/irrlicht-svn/trunk/examples/04.Movement $ LC_ALL=C make
Makefile:30: Building...
g++ -I../../include -I/usr/X11R6/include -O3 -ffast-math main.cpp -o ../../bin/Linux/04.Movement -L/usr/X11R6/lib -L../../lib/Linux -lIrrlicht -lGL -lXxf86vm -lXext -lX11
/usr/X11R6/lib/libIrrlicht.a(CSceneManager.o): In function `IGeometryCreator':
/home/wittus/Projects/irrlicht-svn/trunk/source/Irrlicht/../../include/IGeometryCreator.h:25: undefined reference to `vtable for irr::scene::IGeometryCreator'
/usr/X11R6/lib/libIrrlicht.a(CGeometryCreator.o):(.rodata._ZTIN3irr5scene16CGeometryCreatorE[typeinfo for irr::scene::CGeometryCreator]+0x8): undefined reference to `typeinfo for irr::scene::IGeometryCreator'
collect2: ld returned 1 exit status
make: *** [all_linux] Error 1
Post Reply