Jump to content
  • Advertisement
Sign in to follow this  
Caesar

a few question about 3d theory

This topic is 4860 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

hello, I've been working on my first 3d engine for a few days. I have a few unanswered questions in my mind, thanks for your help. I tried consulting the irrlicht source but for these, I got no good enough answer (plus it's not that easy to read and understand, it's quite huge). 1) I store my geometry (triangle lists) in vertex & index buffers. Shall I keep a separate copy in RAM for collision detection (I just want stuff like ray/triangle intersection for simple walking, bullets etc, don't want any specialized api) and octrees? 2) Is the D3DXRotationAxis function working with quaternions (I know quaternions should do rotation about an arbitrary axis, so seems similar)? I mean, can I use this function without fearing the gimbal lock? 3) I've done a simple graph to manage my scene so that I can attach various nodes to other nodes so that for example a driver in a car get transformed along with the car. I'm not sure about the way to go about the transformations though. Shall I do a few matrices that would manage translation, rotation and scaling independently and define a order in which these transforms are done (one can add a orbital matrix that would rotate after all other transofrms are done). Or shall I let the user manipulate the object space matrix (each node has one, by multiplying these along the graph, I get world space for each node for rendering) himself/herself? 4) If I ever wanted terrain rendering, how would I go around ie. splitting it octrees? 5) for bounding boxes... is it better to give up AABBs and rotate them along with the object they enclose or is it better to scale them so that they fit (rotate the original AABB, create a AABB for the rotated "AA"BB) 6) I don't feel like implementing skeletons, but I was thinking I could do some sort of keyframing. The interpolated frame from two meshes (I mean both meshes have the same number of vertices and faces and the vertices get interpolated (again ad. question 1). But I'm not sure it's gonna have good results.... I assume a similar technique must exists, can you give me some keyword? thanks, I know it was a bit long, but it helps a lot.

Share this post


Link to post
Share on other sites
Advertisement
Hi,
I'll try to answer a few of your questions, I don't pretend to be an expert, but here's what I think:

1. Yes, you REALLY don't want to read the content of your VBs & IBs when doing collision/intersection detection. But then, you will often want a low polygon version of the mesh that is displayed to simplify expensive computations. You may also want to pre-process all the collidable geometry (even if it belong to different object, but keeping and ID if you need it) and put it all together in an octree or some other subdivision algorithm.

2. Never used the function, but I would think so... Always depends on how you do/store your rotations.

3. If you have node hierarchy in your graph, then it doesn't matter all that much. I like having a matrix stack on which you push/pop object's matrices when going down/up the hierarchy.

4. There are a few techniques for terrain, but I'm not really familiar with them. The only thing I can tell you is that modern GPUs like to have batches with many triangles, so if you split up the terrain too much, you will lose in terms of performances because of the increased amount of draw calls.

5. Depends on what you are using the bounding boxes for. If you bounding box test is done to prevent expensive computations then go with OBB, but if you don't care much about false positive, then AABB or spheres are good.

6. Keyframe animation can work, it was used in many games a few years ago. The problem is that you will need a lot of data for complex models with a lot of animations. With skeletal animation, you only need to store the mesh once in the default/bind pose and you only need to store the bones translation/rotation for any animation you want to add.

Share this post


Link to post
Share on other sites
hello,
thanks for the reply! It helped A LOT. Just for this one question, I still feel like I need a clarification

3) I wasn't talking about matrix stacks for the hierarchy, but about how to keep the transformation for each of the items (objects/nodes) in the hierarchy. I know it's up to me to make such decision, but I'm not sure so that's why I ask.

If I make several separate matrices (or just variables that would be parameters for matrices), one for rotation, one for translation etc, then if the programmer wants the object to orbit around [0,0,0] at the distance of x, he can easily do so using an "orbit" matrix that would be used after rotation and translation. No need to translate back etc. Or is it better to give him full access to one single object space matrix and let him do whatever he wants to. How do you do it?

Share this post


Link to post
Share on other sites
Well, I don't think there's a good or bad answer, it's really up to you. I think it is easier to have a pre-determined set of transforms and if the user wants to do something more complex, he can use the hierarchy to do so. Say you only allow scaling, rotation, then translation and the user wants his object to rotate around a given point in space. He can attach the object to some empty/invisible node located at that pivot point and rotate that node, that's why I mentionned hierarchy and matrix stacks.

Share this post


Link to post
Share on other sites
1) Collision geometry is usually different than rendering geometry, both in the actual geometry and the way it is organized.

2) Gimbal lock is a result of using Euler angles. If you don't use Euler angles, you will be ok.

3) A scene graph is more than just a container.

4) Terrain rendering is a big topic.

5) If you are going to rotate the AABB, turning it into an OBB, you should just start with an OBB. It means a little more set up time, but you will get better results.

6) "morph target"

Share this post


Link to post
Share on other sites
Quote:
3) A scene graph is more than just a container.

I use it to manage the transformations. Children are affected by their parent's transformation. Or do you mean something else?
Quote:
1) Collision geometry is usually different than rendering geometry, both in the actual geometry and the way it is organized.

I can understand the difference in organization, but what do you change about the geometry? I mean, for accurate collision detection, you need the exact geometry? Or am I wrong?

thanks for reply

Share this post


Link to post
Share on other sites
Quote:
Original post by Caesar
Quote:
3) A scene graph is more than just a container.

I use it to manage the transformations. Children are affected by their parent's transformation. Or do you mean something else?

I didn't quite understand your explanation/question, but it seemed like the user manages the transformations in the scene graph. That was the source of my (rather ambiguous) comment.

Quote:
Original post by Caesar
Quote:
1) Collision geometry is usually different than rendering geometry, both in the actual geometry and the way it is organized.

I can understand the difference in organization, but what do you change about the geometry? I mean, for accurate collision detection, you need the exact geometry? Or am I wrong?

It depends on how accurate you want your collision detection to be. Checking for collision between two objects with 1000 faces each can be quite expensive. Using a simplified collision geometry might be just as effective and much faster. Either way, the organization is what will make the difference in the end.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!