3D Engine & Transforms

Quote:

Original post by Opwiz 1. How do you represent transforms? Do you use 4x4 matrix or 3x3 matrix/quaternion + vector? Do you wrap this in a "Transform" class?

i've used scene graphs where internal nodes (not leafs) store a "transform" type that effects the node's children, this transform type wraps a 4-by-4 matrix, the 4-by-4 matrix is a primitive type it's the transfom type that has knowleadge of setting up say a rotation matrix.

I'm going to implement mine with a quaternion & position vector.

Quote:

Original post by Opwiz 2. Do you have different data structures for the transformation hierarchy and spatial organization of scene objects? Does your scene graph handle any of this?

a scene graph is a spatial organization of scene objects granted it's minimal spatial information but it still is, you must mean a spatial data structure for geometry such as an octree.

scene graphs are mainly used as a transformation hierarchy and a kind of bounding volume hierarchy (BVH) rolled into one, all nodes have a bounding volume, internal node types can store transformations, leaf nodes can be geometry or reference geometry.

Spatial data structures contains geometry nothing more there-for a scene graph is a higher level entity than say a BSP tree, and the whole BSP tree could be with-in a single leaf node encoding geometry.

Quote:

Original post by Opwiz 3. Do you handle scene object transformation in a way that minimizes the number of transform updates needed? (e.g. by updating & propagating transforms in a certain order)

If i understood you correctly then normally the renderer only takes a particular path in the tree when objects are with-in the view frustum this is where the bounding volume comes into it, for trivial rejection of objects not with-in view so you don't need to concatenate all transforms in the tree.

Quote:

a scene graph is a spatial organization of scene objects granted it's minimal spatial information but it still is, you must mean a spatial data structure for geometry such as an octree.

Yes, you're right.

Quote:

scene graphs are mainly used as a transformation hierarchy and a kind of bounding volume hierarchy (BVH) rolled into one, all nodes have a bounding volume, internal node types can store transformations, leaf nodes can be geometry or reference geometry.

This is what I mainly having trouble understanding (and many others as I see it). If you have some sort of spatial structure (i.e. an octree) then having a scene graph with BVH seems rather redundant. As I see it you could implement a scene graph with a BVH or implement a spatial datastructure (which probably will be some sort of BVH) and some sort of transformation hierarchy.

Quote:

Original post by Opwiz This is what I mainly having trouble understanding (and many others as I see it). If you have some sort of spatial structure (i.e. an octree) then having a scene graph with BVH seems rather redundant.

Not really because there going to be used for different things and there on different levels, besides its not going to be a "scene graph with a BVH" for one the scene graph will actually "be the" BVH but like i said before its not really a BVH its kind of like it, your just takening advantage of the recursive compositional nature of a n-ary tree which a scene graph normally tends to be so you can do trivial frustum culling otherwise you'll end-up visiting every node in the tree when you don't need to, it was never mean't for something like detailed collisions dectection on its own, its inefficent.

Remember thou a scene graph is more than just a transform hierarchy and/or BVH, you have other things like textures, behaviours, shaders, even audio attributes etc. The whole point is you have a unified interface of all these different kinds of things.

spatial data structures just care about geometry nothing else but there better for other things.

Quote:

Original post by Opwiz As I see it you could implement a scene graph with a BVH or implement a spatial datastructure (which probably will be some sort of BVH) and some sort of transformation hierarchy.

If you have one scene graph implemenated with a particular spatial data structure say an octree its gonna be restrictive, its like saying my hand has to have 7 fingers + 1 thumb or even worse one hand with 4 fingers + 1 thumb + 3 invisible/empty fingers i know its a bad example but you see what i'm saying?

the main scene graph should be an n-ary tree but you wont to be efficient so you augment your scene graph such that you permit sharing of leaf nodes then you can have more than one scene graph for different tasks, you still have your main n-ary tree which has transformation hierarchy + fake BVH but another say that is an octree and so on, you'll need to keep them in sync of course

[Edited by - snk_kid on October 7, 2004 5:32:31 PM]