Questions about mesh loading and general object handling.

[Unwise owl]

I am about to start programming an isometric perspective strategy game. Judging from the capabilities of Irrlicht I find it a suitable engine for my needs. I do got some initial questions though:

1. I figured I need to create my own mesh loader in order to create "animated" meshs with one keyframe from my own heightmap format. This is so I can then use an octree to render it efficiently (no more fancy algorithm is needed since only a very limited area of the terrain is visible at once, due to the isometric perspective, and even a quadtree would have been suitable). In this matter though I have bumped into a wall because of the documentation's exclusion of private members among different classes. The descriptions of public methods are not of much use when I plan to supersede an irrlicht base class. Therefore I need some general guidlines about what base class members that I should read up on in the source code, prior to my attempt to make an implementation of the IMeshLoader. I've tried to view it already, but it is really hard to keep track of which member is inherited by what class etc.

2. This question is less specific. When you use Irrlicht, how much do you rely on the actual engine objects for your game logic code? Do you use it to a very large extent, or do you just use the engine for little more than model loading, collision detection and rendering? For example in my strategy game there will be buildings (duh). Should I derive them from scene nodes and use the scene node as the object itself, or should I just use the scene node as some kind of mirror only used for rendering? I have these wonderings mainly because with my previous experiences all game related that has been very separated from the rendering related stuff (which has its positive and negative sides). In Irrlicht there seems a lot of futures there already that are built-in, but many of them do not appear to be very suitable for a strategy game and instead mainly usable for first person shooters or adventure games.

I am sorry if my questions were a bit consusing; it is night here in Sweden and I am tired. Hopefully someone can give me a bit of information on these issues.

[Tyn]

1. The members aren't private, they are protected. You could extend the base class with a derived class that includes a function to get access to the protected variables and functions. Example:

The IsVisible bool is a protected attribute. To get at it you need to call a function to return the attribute:

Code: Select all

		virtual bool isVisible()
		{
			return IsVisible;
		}

2. You can do either. I think what you are getting at is that if necessary, could you code half your game and then switch engines without too much code change. Using a struct, you can add a pointer to the scene node object. Then you can add whatever other attributes you need and only call the scene node when you need it. You could also derive your own class to store this information in, your choice.

It's pretty open, you can only use Irrlicht for basic rendering and scene nodes ( stuff like animation and movement, handling of cameras ) and use exterior physics engines. Or you could use all the features that Irrlicht offers. There's plenty of tutorials around to implement stuff like ODE and Newton physics engines.

[Unwise owl]

When I said private I meant protected.

I was more asking for advice on what specific Irrlicht source code to read up on and what classes are important to grasp a good knowledge of in order to inherit and supersede the IMeshLoader successfully.

Nevertheless, thank you for your reply. Keep 'em coming.