3d space visibility and collision geometry for shell of level
by Ezra · in Torque X 2D · 12/11/2008 (2:15 pm) · 3 replies
Hi, I'm wondering if anyone could give me details about how Torque X will benefit me when it comes to handling these two common requirements in any modern 3d game, the handling of visibility (through stuff like octrees combined with manually made sectors encapsulating different areas of a level, which would create the potential for visibility from one sector to another, doorways and hallways leading to rooms for example, etc) and also handling collision for the environment's static shell geometry, which is usually some form of low poly simplified geometry, basically for determining how the Player's collision capsule interacts with the environment along with other small rigid-body enabled items like boxes, or other enemies and their collision capsule/box..
I'm also wondering about the content creation process for something like an interior space, would it simply involve having a mesh of the visible static shell geometry, and then another mesh for the invisible simplified geometry used for collisions with the environment?
Even any potential ideas for how this might work or be implemented in TX could be helpful.. just basically eager to start working with 3D in TX and all my 3d experience comes from FPS level design type stuff, so I'm wondering a lot about it
I'm also wondering about the content creation process for something like an interior space, would it simply involve having a mesh of the visible static shell geometry, and then another mesh for the invisible simplified geometry used for collisions with the environment?
Even any potential ideas for how this might work or be implemented in TX could be helpful.. just basically eager to start working with 3D in TX and all my 3d experience comes from FPS level design type stuff, so I'm wondering a lot about it
About the author
Recent Threads
#2
Also noticed a CollisionMeshShape which sounds like what I'd need... I'm assuming though. If it is what I think it is, I wouldn't want to use it with high detail geometry, but instead for basic level hulls and check against objects which use box or sphere shapes..
12/12/2008 (6:14 pm)
Seems like good news, I just looked in the updated documentation released earlier today and found information of a KD Tree implementation so that makes me happy, that alone won't do visibility checks, but that can be the basis of coding my own visibility checks using it.. something I haven't done but I'm sure I could figure out to suit my needs.Also noticed a CollisionMeshShape which sounds like what I'd need... I'm assuming though. If it is what I think it is, I wouldn't want to use it with high detail geometry, but instead for basic level hulls and check against objects which use box or sphere shapes..
#3
For instance, I just implemented a quadtree-based Terrain class that uses quadtrees not only for visibility culling but also for physics, and it's working quite well within the TorqueX framework and was relatively easy to incorporate.
So really, it's nice to have something already present which can be used, but it's even nicer to know that you can extend the system without running into fragile class hierarchies which break at the slightest change :)
As for the CollisionMeshShape, you will *definitely* want to use it with either low-poly static geometry or simplified collision meshes. The kd-tree implementation used by the CollisionMeshShape has an absolutely insane front-loading time, and the more complex the geometry the worse it is, and you don't want your player to have to wait five minutes while the level/game loads.
The kd-tree is exceptional when it comes to fast ray picking, collision detection, and nearest-neighbor queries, but there's a price to be paid for it :)
12/13/2008 (4:45 pm)
While TX does contain a kd-tree implementation, it's really not much trouble at all to create your own quadtree, octree, loose octree, or any other kind of spacial subdivision structures.For instance, I just implemented a quadtree-based Terrain class that uses quadtrees not only for visibility culling but also for physics, and it's working quite well within the TorqueX framework and was relatively easy to incorporate.
So really, it's nice to have something already present which can be used, but it's even nicer to know that you can extend the system without running into fragile class hierarchies which break at the slightest change :)
As for the CollisionMeshShape, you will *definitely* want to use it with either low-poly static geometry or simplified collision meshes. The kd-tree implementation used by the CollisionMeshShape has an absolutely insane front-loading time, and the more complex the geometry the worse it is, and you don't want your player to have to wait five minutes while the level/game loads.
The kd-tree is exceptional when it comes to fast ray picking, collision detection, and nearest-neighbor queries, but there's a price to be paid for it :)
Torque Owner Ivan Alduan
For interiors try T3DStaticGeometryComponent, but I think the mesh it generates automatically for collision detection is the same that you provide, and there isn't information the way it handle all the tris internally so we didn't know anything about optimization.