It’s a collision scene graph that acts as a bridge to handle polygonal 3D collision environment detection.
Move collision scene graph nodes around (based off your implied/related game entities) and update their transforms/(optional bounding boxes) accordingly to match. You can also re-parent the nodes, remove them, or add new ones, etc. . This allows you to easily shift/stream-in objects if needed for different play setups.
EllipsoidCollider class to do collision/movement/destination queries on collision scene graph.
Raycaster class to do raycasting queries on collision scene graph.
Create your own customised collision-checkers by creating your own IRaycastImpl or ITCollidable implementations to best suit the type of 3D environment you are using. Whether it’s a KDTree, BSPTree, QuadTree, bounding volume hierachy, etc. the possibilities are endless.
What features does the package support when integrating the engine to Playcanvas?
collision-scene.js script to help build the collision engine’s scene graph which matches Playcanvas scene and any collision components/scripts/tagged nodes found within Playanva’s scene graph. Bounding boxes are generated over the geometry, and are expanded hierachically for ancestor nodes for optimal broadphase collision query traversal.
All collision primitives from Playcanvas. (sphere, capsule, box, cylinder) and collision meshes supported.
staticCollisionMesh.js script to help filter out meshInstances from a Model asset that you do not wish to be included in collision detections, (and also optionally for regular Playcanvas’ AmmoJS physics).
Low memory footprint and highly scalable. All geometries/collidable implementations of collision primitives and Model assets are cached/re-used throughout the entire collision scene for similar Models/collision primitive types. (In fact, I think Playcanvas did not cache Model assets for AmmoJS triMeshes, i think.) . You can repeat 10 times of the same Castle mesh across different transforms (positions/rotations/scales, etc.), and it will return the same collision geometry/implementation instance (usually a BVHTree) across the gameworld.
For Beta: (all done)
Proper attribute options for collision-scene.js script.
Object Bounding Volume Hierachy generation option for collision-scene.js script to generate OBject Bounding VOlume hierachy at that location instead of follow the scene graph hierachy of Playcanvas Collision/collisionBoundNode tagged) entities. I’m currently using code from Oimo Physic’s DBVT (dynaimc bounding volume tree) structure to handle the tree generation of objects in the scene. This will later be expanded to support hierchical frustum culling as well and a proper API to easily move objects about in the tree and update it. (from the Playcanvas entity references)
Would clean up and provide some examples for end users: Example QPhysics script component for quick plug and play usage of common collision/movement query behaviours of Quake-style player movement/projectiles.
BVHTree Hierachy generation option for collision-scene.js script to generate a single BVHTree polygon soup object from all playcanvas collision entities to test against, instead of a scene graph.
Currently, the convention requires you to have a collision-scene.js script as the first “root” element to house all other nested collision entities. ( I’d have to later see how this can be configurable…) You also need the haxe.js and bvh-tree.js files from the global s folder and have those files loaded first in Script Loading Order.
There is a 2nd generation method option you can use in collision-scene.js that will generate its own bounding volume hierarchy instead of the default playcanvas scene graph structure. If using the default (first) option , and you wish for certain entity nodes to act as sub-hierarchical bounding volume parent containers in the collision scene, you must explicitly tag such entities as “collisionBoundNode”. See Warehouse QPhysics example on how it works.
For use of altern.Raycaster and altern.EllipsoidCollider within Playcanvas, refer to the orbit-camera script and CharacterDemo scripts.
The doc is actually not entirely correct for constructor. For altern.EllipsoidCollider constructor, 4th parameter is “threshold” and is for the minimal highest precision significant world sized unit for simulating movement that courts as “movement”. 5th parameter boolean is whether you wish to enable collision events or not. ( defaulted to false but for the case of the player controller working in conjunction with other codes to apply gravity and such, I had to use collisionEvents to check for normals of collision surfaces touched during calculateDestination() … to determine if character is on ground or not, prior to disposing/recycling them off back to pool with dispose function.
Hi, this is a very interesting approach to embed raycasting directly into PlayCanvas hierarchy. I could really make use of this, I ported the ioquake3/idtech3 engine to WebAssembly and I still use the BSP tracing for player movement. However, that is quite undynamic, when one “brush model” is changed, the complete map needs a recompile to .bsp and a reload.
I would like to test this, but I’m unsure about the license. MIT or BSD license e.g. would be very nice. Could you apply some license to this?
The license would mainly be Mozilla Public License, v. 2.0 . But i added more to the main git haxe repository based off the used libraries BVH-Tree and OimoPhysics Dynamic Bounding Volume Tree. (For an old legacy 2D demo of how OimoPhysics’ Dynamic Bounding Volume Tree broadphase works , here’s one in Flash: http://fl.corge.net/c/jA37 .)
Playcanvas hierachy with tagged nodes may/may not be used. There are 2 options in collision-scene.js generation methods.
Playcanvas Hierachy Tagged Nodes (uses current playcanvas scene graph of entities with collision-related scripts/components, or tagged with collisionBoundNode)
Dynamic Bounding Volume Tree (if the Playcanvas scene hierachy distribution of entities is not ideal for hierachical collision detection, uses this instead to let the script create a suitable hierachy for you)
BSP/KD/Quad/Oc trees has it’s advantages in raycasting performance because you can actually raycast the shortest distance node first ( due to split planes) and early exit out unlike bounding volume trees. But often, most modern games nowadays find this slight advantage unnecessary and bounding volume tree setups are more common/flexible (especially anyway if you do need to raycast across all intersections and not just the closest). Bsps also have bad reputation of unwanted/unavoidable geometry splits, requiring hint brushes and such for optimisation but may store/process more tris due to splits.
Under orbit-camera, did you turn on the raycastDistance checkbox? It should work automatically with the default collision scene if that’s the case.
If you need to “filter out” certain objects and not have them raycasted, you can tag those entities with noRaycast and it’ll not block the ray.
Likewise, entities can be tagged with noCollide to disable collision against ellipsoid.
But it looks like you have your trees baked in together with your Model entity… so it’s hard to seperate difference cases for that. Unless you resort to 2 duplicate entities (with different tags, one with noCollide and one with noRaycast) containing their own staticBodyModel script references to filter out the necessary meshInstance elements (via regex meshInstance names) for raycasting vs colliding respectively. staticBodyModel script reference can be found on Warehouse model in: https://playcanvas.com/editor/scene/635389
Take note that the tags only apply at initialization time. Applying/removing them during runtime has no effect whatsoever.
Below: the not so well-featured (no crowd/dynamic-obstacles/navmesh-generation), but worth porting to Playcanvas engine if possible… (actually, it should be ported over to altern Haxe code and simply use some generic altern.Geometry (or generic interface with .vertices/.indices getters) as a cross-platform vertices+indices geometry base that isn’t tied to any engine/platform. Sigh…) https://github.com/donmccurdy/three-pathfinding https://github.com/wanadev/babylon-navigation-mesh
Also, with navmesh, it’s possible to forego collision detection and just run movement script to constraint movement within navmesh as well.