Ahoy. A few months ago, I completed my "3D engine" which basically sets up lighting, can load and animate models from my own format (converted from MS3D) and handle basic rotation. Since then, I've been stuck in a well of thinking. Where... next? I've identified the next step as some kind of world-model interaction system - or at least a system that makes it possible. Seeing as my mathematical prowess is lacking, I've tried to avoid anything that risks breaking my internal calculator. My current idea is to have a coordinates-esque system, where the player model is known to be loaded at *,*,* - and all movements will be calculated and the coordinates altered accordingly. Before which, the would-be coordinates (where the player is going) would be checked against some kind of boolean table to see whether they're allowed to go there. This covers the issue of them walking through walls/objects, but it seems very -- for want of a better word -- icky. It also leaves out the business of raising/lowering the model when they walk up and down steps. I've no idea what to be looking into for this. Gravity engines? Collision detection? I'm scared. I'm an amazing programmer (if I do say so myself) - I just can't handle math. It literally takes me a minute to work out 5*6. To roughly summarize: - What would I need to research for stopping players walking through other models? - What would I need to research for raising/lowering the model when the ground level changes? - Are there any other potentially useful tutorials or guides that may relate to keeping track of a "world" and the players/NPC's/etc in it? Any and all help will be appreciated.

Quote:
Where... next?

Write a game. Until you do, you'll have no idea if your "engine" is actually useful or not, and as you do, you'll have a much better idea of the features you need to add to your engine codebase to make it useful.

If you try to simply assemble a bunch of "engine-esque" technologies in isolation, without a firm need (the game), there is an absurdly high chance you will end up with a hodgepodge of tech that looks nice on paper, but in practice does not integrate well and requires massive refactoring to actually be helpful in creating a game.

Thanks for the feedback so far. ;)

Gave the scenegraph links a read over & they've given me some food for thought. The technique seems to be more relevant to large maps which I don't think I'll be experimenting with any time soon, but I'm sure a time will come in the future.

@ jpetrie: I'm yet to write a game, but I believe that what I have done so far is useful. What I have is a seperate header file with 3 classes (one for each file format - static model, animated model & multiple animation model) and the relevant functions to load, draw/animate and rotate their specific model. Can't really say that it could be rendered useless because it's not yet complex enough to become distant to the possible cause. I do however understand that the more stuff becomes piled on top of it, the more useless it could become for whatever I may decide to use it for e.g. making it suitable for FPS and then wanting to make an RPG.

@ dmatter: I'd already established that a boolean table would be a hog, but I figured it'd be acceptable given what I intend to do. My current sights are set on an RPG & I know that the maps won't be that large... with the possible exception of one or two. I also have a fear that the code behind collision detection and response may be more intense (at least on the CPU) than is necessary. It stands to reason that a constant calculation of "model pushing down on floor" would be more demanding than one-off calculations after movement - unless the detection/response could also be done strictly after movement?

I have read one or two collision detection articles, but I've never picked up anything that seems relevant to detecting when a model has intruded the space of another model, funnily enough. It all seems to rant on about building complex physics engines which come across as overkill - at least for what I'll be needing it for, anyway.

Do fill me in. ;)

Quote:
@ jpetrie: I'm yet to write a game, but I believe that what I have done so far is useful. What I have is a seperate header file with 3 classes (one for each file format - static model, animated model & multiple animation model) and the relevant functions to load, draw/animate and rotate their specific model. Can't really say that it could be rendered useless because it's not yet complex enough to become distant to the possible cause. I do however understand that the more stuff becomes piled on top of it, the more useless it could become for whatever I may decide to use it for e.g. making it suitable for FPS and then wanting to make an RPG.

Already useless! ;)

Well, not really, and not for the reasons I was initially describing. I do still recommend you start building some kind of actual game with the tech as soon as possible, though, even if its small and simple. You'll be surprised how much it reveals about the usability of your tech.

Now, that said, your model classes are broken. You don't need three, you need one. What's a static mesh? A mesh with no associated animations. What's an animated mesh? A mesh with one associated animation. What's a multiple-animation mesh? A mesh with more than one associated animation.

You can get away with exactly one mesh class; the animations bound to that mesh are values of mesh properties, not properties themselves. Multiple mesh classes in the form you've got will become brittle and unmaintainable moving forward. There are three points of extensibility that cannot be swapped easily for each other (because of the rigid nature of the type system in C++), and they all are very similar. Inheritance would even be overkill here.

I'd be interesting in you clarifying how it's already useless, jpetrie. Not quite seeing how a model loader/animat0r/etc is useless in a 3D game... which requires models that can be loaded and animated.

The reason for 3 classes is because I didn't want the code to have to detect which format is being used. For example, if I know that the map is just going to be a concrete floor and a brick wall with a hole in it, I just select the class for the static models and then that'll handle it. If I had one class, it'd have to detect whether it's static and it'd have functions and allocated data that's useless to the cause. I guess it's hard to grasp my method without seeing what's being done.

@ dmatter: Thanks for filling a few more blanks. ;) I'll continue hunting for articles and such like when I'm not ready to pass out.

Quote:
I'd be interesting in you clarifying how it's already useless, jpetrie. Not quite seeing how a model loader/animat0r/etc is useless in a 3D game... which requires models that can be loaded and animated.

Er... did the smiley face and "well, not really..." sentence not clarify that I wasn't entirely serious with that comment? There are, as I said, problems with having three different model classes, however.

Quote:
The reason for 3 classes is because I didn't want the code to have to detect which format is being used. For example, if I know that the map is just going to be a concrete floor and a brick wall with a hole in it, I just select the class for the static models and then that'll handle it. If I had one class, it'd have to detect whether it's static and it'd have functions and allocated data that's useless to the cause. I guess it's hard to grasp my method without seeing what's being done.

No, I see what you're doing. You're doing it inefficiently -- and you've mentioned something else that is a potential serious flaw in your design. But I will address that later.

First, the whole issue with "detecting the format" should be a moot point. You should have a singular format for model data in additional to a singular class. I assume you have model and animation data tightly coupled together(*) in your file format. So a model file might look like this:

(number of vertices)(number of indices)(big list of vertices)(big list of indices)(number of animations)(big list of animation data)

A "static model" has a 0 for the number of animations, and thus the loader won't read any animation data. Likewise, the model class stores this zero, and so when told to Update(), it tries to update its current animation, realizes that it has no animations, and does nothing.

Splitting up your model classes into three different, district types is just giving you duplication for the sake of duplication, increasing the number of points you have to to monitor in maintaining your code, and decreasing the flexibility of your code (because you have to treat each location where a model is required as a decision -- is this model going to ever need to animate, because if you make the wrong choice now it requires a code change. If you make it so that all models might be animated, but some models are loaded from data files that don't have animation, you tie expansion to data rather than code, as well as remove a bunch of duplicated code and overall streamlining your product. This "extra work" you seem to be concerned about for detecting "if the model has is animated" is trivial - if(numAnimations == 0) and other similar boilerplate.

Okay, now the second issue I mentioned I noticed. You're not going to like this, because on the surface it's going to sound like I'm countering my own advice above. But here we go. Your level/map data should not be a model. It should have very similar stuff - perhaps you can reuse underlying geometry buffer objects, or something. But treating levels or maps as "large pieces of geometry" is very inefficient. The needs of a model, that is, some kind of displayable actor or character, are vastly different from those of a level, and it is poor design to comingle them (failure of the single responsibility principal). Levels, for example, should be stored in way that is efficient for visibility checks and collision, usually in some kind of spatial hierarchy of sorts. This is often because you rarely render the entire level at one time, or even perform processing on the entire level at once. You work with visible subsets, or something similar.

But a model doesn't need the ability to be sliced up into an octree for efficient partitioning -- a model you're either going to draw, or not. Even those they are ultimately composed of similar fundamentals (geometry), they have wildly different interface characteristics and requirements, and similarly wildly different extra data (levels, as you pointed out, probably don't ever contain animation, but they might contain an extra set of specialized geometry for navigation or collision, et cetera).

(*) A third point is that I find this coupled (model and animation) to be distasteful and limiting as well. Animations can easily be used to drive multiple models, so the animation should not be a part of the model data, but a separate entity that is later associated with the model(s) it drives. This only makes sense for skeletal animations, however, as vertex-blended animations (being by nature tightly coupled to the vertex data they animate) don't have as strong a need for separation.

I understand your 2nd point. Taking into account that maps wouldn't be solid models, there'd really be no need for a static format/loader/drawer, cutting the classes down to 2. I can also see the sense in molding the formats into one, having the less complex formats the same as the more complex formats but without the data they're intended to hold. I suppose the overhead in the files wouldn't be that great.

Now... I'm left with further confusion about worlds/maps. Confused mainly about the specific differences between two things which are basically made of the same minerals, but... in different ways? How would you build a non-random map without storing its information in a file? That's my definition of model. I'm not college educated, so exact meanings of terms evade me.