Ill try to make this short and sweet because my time is way too short thanks to teachers at school...grr..another all-nighter! Ive been thinking about the design of my 2d rpg which for this discussion lets just say its isometric..but definitely 2d space. So, i was thinking about how 3d engines work as far as objects are concerned. So, for my example, lets say i have the following classes (general): ITEMS CHARACTER(player, npc, animal) FOLLAGE(rocks, trees) AMMO(arrows, boulders) ***this one im not sure about..was thinking it could be a specialized CHARACTER or its own class, unless anyone has a suggestion)** So, i have these distinct class objects. How would these be stored for a 3D environment? Would you just have like an array for each type, sort them, and then run through each class array and draw them. Or Is there a better way? The classes are different so its not good to try to make a be-all-end-all class to encompass each one. I guess im confused on how objects work so well in a 3d enviroment populated and interacting together in harmony...ack, i hate being confused. Visit my planet: Planet John Capt. James Tiberious Kirk -- hmm, didnt know ole Capn was a tiberia fan.

First, I would seperate the concept of an object''s role or significance in the world from the fact that it is an object which needs to be rendered. ITEMS and AMMO are likely no different as far as a renderer is concerned; they both can be moved around.

When you enter the world of 3d, you confront the massive problem of culling. Culling is the removal of objects from further processing as soon as it is determined they do not reside in the picture. Culling for dynamic objects is often different than culling of static objects. In addition to culling, there is the important technique of simplification.

Culling methods usually employ bounding volumes, octrees, and bsp trees. Simplification methods usually employ polygon reduction and textures in place of actual surface geometry.

This is not a simple subject, and is going to require a great deal of reading and learning on your part.

I appreciate your response but i think your (not on purpose) tip-toeing around the question i ask.

quote:

---

First, I would seperate the concept of an object's role or significance in the world from the fact that it is an object which needs to be rendered. ITEMS and AMMO are likely no different as far as a renderer is concerned; they both can be moved around.

---

This, as i stated, was part of my confusion in understanding what the difference is between 2d and 3d enviroments. For 2d, and in my example, maybe some type of layers and of course 2d surfaces are drawn.
In a game like my example, you could have, like i said, arrays for each object type and call the draw() routine on the list for all in screen space. Of course im leaving out stuff like sorting them, but this is the general idea.

So, now in 3d, I take it it is something like raytracing, drawing surfaces which face the camera, and as you say, using binary space partioning to exclude objects out of sight.

But are the objects stored similarly to my 2d example, each type in an array of that object type?

YOu suggest seperating the roles of the object from its rendering...


Visit my planet: Planet John
Capt. James Tiberious Kirk -- hmm, didnt know ole Capn was a tiberia fan.

Edited by - GalaxyQuest on March 12, 2001 5:26:11 AM

The details how the things is displayed does and should not affect the high level classes. You need to add variables for the dimension but nothing more. A CHARACTER is a CHARACTER in both 2D and 3D.

If you are talking about 3D with hardware support and some API like OpenGL is it not difficult. You can leave all of the culling, sorting, excluding objects, ... to the API/hardware. If you have a big world can you add some simple distance test. Even with old cards should that be more than enough.

I would not leave culling to the hardware. It just isn''t capable. I would leave clipping to the hardware though.

The reason I mention culling is because it changes the way objects are presented to the renderer. They are not necessarily presented as an array. For example, a BSP tree is a binary tree, and an octree contains linked lists of objects for each node of the octree.

The main idea is to make the good API/hardware do all the work and use a brute force approach. No fancy data structures like BSP trees or similar just some simple arrays or lists. A distance test to skip far away objects or use a low poly model.

This would be extremly easy to implement and certainly the way to do it if the speed is good enough.

bishop_pass, your advices is probably good if one wants/needs something more efficent but it would be much harder to implement.

Actually, bishop brought up a good point. For example, my terrain engine gave me a constant 15 FPS (at 1600x1200x32 on a Radeon DDR) with no culling, because even the object behind the camera were "rendered" by D3D. So right now I''m working on functions to determined if a piece of terrain is in view. Maybe a GOOD API would do that. How about you go do that, Anonymous Poster (BTW, get a name!) Only rendering what is in front of the camera brought my FPS into the range of 15 FPS (when you DO see the whole world) to 25-40 FPS (in normal view mode). And I''m still working on a better algorithm to that. So it IS important.

And why would you want to design something inefficient? Brute force is easy. Culling is where the real fun comes in

------------------------
CRAZY_DUSIK* pCrazyDuSiK;
pCrazyDuSiK->EatMicroshaft(MS_MUNCH_BILL_GATES | MS_CHEW_BILL_GATES);

Ok, so culling the objects is what you guys want me to talk about. I will use it i guess to understand it in terms of my example.

If i have 2 different types of objects ITEM, CHARACTER each having different class structures. In my 2d example, i used 2 different arrays, one for items, one for characters.

Now i want to go 3d with these same 2 object classes. HOW are they stored as you say in your examples...bsp trees. Because the classes are differnt, do i now need 2 bsp trees to sort through what objects are visable? (more generally, n number of bsp trees for n number of object classes)

*ALSO, are these same bsp trees used for when i need to check collision detection, like searching through the ITEM bsp and the CHARACER bsp for any close by objects?



Visit my planet: Planet John
Capt. James Tiberious Kirk -- hmm, didnt know ole Capn was a tiberia fan.

dusik, someone did make a good view frustum culling tutorial and if you are comfortable with OpenGL can it perhaps help. Search the NeHe forum or the web.

Sure, view frustum culling is important and so are a lot of other stuff but if you can should I at least try to avoid the more complcated data structures.

They all have their restrictons, BSP trees for example is only for the static world. That means you must probably complement with some other data types. Splitting up the world in static/dynamic parts and so on...

You have to do a lot of sorting and other stuff if you want to build something fancy. The other way is to use just some simple basic tests and instead make the world little simpler. Using high poly models in a reasonable way.

I know most wants to do something really impressing but it is a lot easier to actually finish something with the brutal force approach.

>If i have 2 different types of objects ITEM, CHARACTER each
>having different class structures. In my 2d example, i used 2 >different arrays, one for items, one for characters.

>Now i want to go 3d with these same 2 object classes. HOW are
>they stored as you say in your examples
Ok, I''''ll have a bash at this since everyone else is focused on that culling thing which I have no idea about.

Surely you can store them as you like? Your item and character classes will probably be based on a CGameObject class or something (which holds basic properties and methods for objects in the game). Depending on exactly what each object needs to do, you could probably get away with a single array of pointers to these class objects.

Use more arrays for different types of object if you like. I can''t imagine this would complicate writing a BSP and Culling routines.

Er... hope that helps a little.