I wonder why turning on precisecollisions has to slow down object building and take (a lot) more memory? All the data needed to check for a collision already exists. I made my own raycast that checks all the triangles in the terrain mesh (it could be optimized, but is fast enough for playing with, but if you try to calculate water depth with it on every vertex… it is very slooow since it brute forces all the triangles). It works for raycasting from sky to determine elevation, and for mouseray casting. I tried using the built in ray casting but was getting the bounding box (even with precisecollisions set to true) and it dramatically slowed scene building and increased memory use by 50%. I feel like I will miss functionality not using the built in raycasting, but not sure what that might be for now. Does the stock system perform faster by making its extra data?
Here are some mouseray casts to drop markers… They are all perfectly on the ground so you don’t see the full 3d cross shape. Next I will use this to deform the terrain, which will be very fast compared to my earlier prototype since the new terrain is based on the water mesh and deforms instantly (just updates the Y as needed in the vertex list).
Toggling the PreciseCollisions to true is doing some work (and consuming memory) exactly because it is not doing the “brute force (iterate over every triangle)” approach
When PreciseCollisions is active, we construct a spatial tree called “octree” and use this to resolve collisions with routines like World.RayCast. This is what allows to resolve collisions fast.
See the octree documentation in our “old engine internals docs” for how it works :
Heed the warning on Engine internals documentation | Castle Game Engine : This is old engine documentation, it talks a lot about engine internals, and it doesn’t talk about many engine features in version >= 3.
( Note to anyone reading: PreciseCollision, as documented here is part of our “13. Old system for collisions and gravity” that we eventually plan to deprecate and then remove. Doing everything using the proper physics engine is the future, and we work towards it. When using “proper physics engine” (Kraft, to be precise) you would use e.g. World.PhysicsRayCast. Under the hood, Kraft also prepares it’s own spatial structure, and does its own optimizations, so it’s also not doing “brute force”, at some cost of initialization and memory. )
Since I put the triangles into the mesh in order, I can hone in on the triangles by their index. But brute force serves my immediate needs. I tried the physics approach, but also found it heavy and time consuming to apply to all the terrain. But maybe if I just put it on the max LOD tiles since you don’t click on far away tiles, that would be ok.
I haven’t checked the kraft integration, but does it uses the same mesh data as CGE, or CGE has to prepare another copy of the same mesh for kraft? Edit: Of course I am asking for the best scenario i.e. the mesh is constructed from either TTriangleSetNode or TIndexedTriangleSetNode.
Kraft (and I guess most other physics engines in the future, like PhysX, will be like this too) has its own mesh definition with own types. It doesn’t reuse any CGE data.
We build a mesh on Kraft side using a rather trivial and likely unoptimal code: castle-engine/src/transform/castletransform_physics.inc at master · castle-engine/castle-engine · GitHub . It is possible this building speed could be optimized, though I’m not sure whether Kraft API TKraftMesh exposes something for this, except using TKraftMesh.LoadFromStream – but then it would have to preprocessed first with TKraftMesh.SaveToStream from the same Kraft version.
So, from what I see:
there’s room to speedup the “physics engine mesh” building time. At least preprocessing mesh with TKraftMesh.SaveToStream + TKraftMesh.LoadFromStream.
I don’t see a room to improve memory usage of “physics engine mesh”. Physics engine, like Kraft and likely all others, do and will have their own idea for mesh memory layout in memory. CGE needs its own idea to render it efficiently. Well, both CGE and physics structures can likely both be optimized :), but I don’t think we will be able to share them, to always make CGE and physics engine use the same.
And in general, one could use mesh colliders with more “coarse” data, so mesh data for physics may be different. Actually I see Kraft has TKraftMesh.Decimate, I will definitely check it out, how much it can optimize the mesh.
