Please add support for Castle Engine

[lvdpower]

Hi. Could you make support for phisic editor for the Castle Engine? (https://castle-engine.io) I wrote to author of Castle Game Engine (my message " Is it possible to use a physics editor (I bought this one) in CGE ?" and he answered "The PhysicsEditor needs a "loader" code on the engine side ( https://github.com/CodeAndWeb/PhysicsEditor-Loaders ). The current loaders do not support Castle Game Engine. If you'd like to see support for it, you can ask PhysicsEditor author, or submit a feature request to our engine -- https://github.com/castle-engine/castle-engine/issues . But personally I have to admit I'm not sure when/if I would be able to deal with this. I'm busy with lots of CGE-related tasks :) But maybe some other CGE developer, and/or the PhysicsEditor author, would be interested to contribute the necessary loader. I would naturally help." Thank you! Timur

[michaliskambi]

Hello! I'm the author + lead developer of Castle Game Engine.

As I mentioned in my email, If there's interest in implementing this loader (from anyone -- PhysicsEditor or any Castle Game Engine developer) I am happy to provide some guidance. Here it is :)

• Our physics support is described in https://castle-engine.io/physics .

• I understand that the outcome of reading PhysicsEditor files in an engine is essentially a "mesh collider".

• I understand that the file generated by PhysicsEditor is PLIST, a special case of XML, common in Apple and Cocos environments.

• For CGE, this means that a loader could be implemented as a class like TCastleColliderFromPhysicsEditor, descending from our existing TCastleMeshCollider. The TCastleColliderFromPhysicsEditor class could have a URL field (everything in CGE is an URL) that loads the PhysicsEditor file, and sets the TCastleMeshCollider.Mesh property to the internal TCastleScene instance with points read from the PLIST file.

• Here's a sketch of the implementation: https://gist.github.com/michaliskambi/067414b28ab3b14ea4c19e072a927a23

• It should be possible to test it even in the Castle Game Engine editor, just add a RegisterSerializableComponent(TCastleColliderFromPhysicsEditor, 'Collider From PhysicsEditor'); line in the unit's initialization section and follow https://castle-engine.io/custom_components on how to add a custom component to be visible in Castle Game Engine editor.

I hope it helps anyone interested in implementing this. Don't hesitate to ping me if you need more info :)

[CodeAndWeb]

Our game dev tools PhysicsEditor and TexturePacker can both create whatever output format is required - the exporter is template based and can easily be adapted to whatever is required. XML, JSON, Pascal source code if you completely want to omit the loader code.

I assume that PLIST is probably not the best format - except you already have a generic parser to load the cocos2d/starling sprite sheets... or is there a JSON parser that could be used?

I must admit that my Pascal knowledge is a bit "outdated"... I last had contact with Delphi 25 years ago. :-/

But I am happy to help setting up an exporter for Castle Engine.

[michaliskambi]

For me, any format is good :)

PLIST is OK, it's just XML and we know how to handle it. JSON would be good too, we have a few things we read from JSON (glTF, Spine JSON, various REST APIs naturally). So I would suggest to pick any format you already generate -- I would not want to burden PhysicsEditor with extra maintenance of another format just for our small Castle Game Engine.

If your PLIST generated for Cocos2d (I see on https://www.codeandweb.com/physicseditor/tutorials/creating-physics-shapes-for-cocos2d-x you load Shapes.plist) already contains enough information, then we should likely just load it in CGE. My "sketch" implementation on https://gist.github.com/michaliskambi/067414b28ab3b14ea4c19e072a927a23 follows this route :)

I would discourage from generating just Pascal code -- while possible, this would mean that the effective collider is "hardcoded" and each change requires compilation of the code. Having the data in any external file allows for easier modification at runtime, we could e.g. auto-update the collider when the respective file changes even at runt-time (which may be useful during development, to allow users to iterate on perfect collider faster).

P.S. If anyone will develop this, I can take over maintenance of it on CGE side, if you'd prefer. That is, we can commit the loader into core CGE https://github.com/castle-engine/castle-engine/ , I can add a few auto-tests, and this way maintenance is on us. And CGE users have the PhysicsEditor loader available "out of the box" in CGE.

[CodeAndWeb]

PhysicsEditor currently outputs convex polygon outlines. Looks like you need triangles. That should not be a big issue since they are easy to convert if we can live with potentially "skinny" triangles.

Is it possible to use multiple meshes / circles within a single collision object (e.g. for head and torso of a character)?

The question is what other parameters might make sense to pass... and what other stuff to configure. PhysicsEditor can set properties per mesh, shape or globally.

• coordinate system direction (top left vs bottom left)
• collision flags / bits / masks
• bounce vs resititution
• mass vs density
• pivot point ?
• shape / mash identifier

If we simply use the existing cocos2d exporter, it might not be a very good user experience.

I currently don't have sufficient resources to dive into the depth of the Kraft engine you are using...

[michaliskambi]

PhysicsEditor currently outputs convex polygon outlines. Looks like you need triangles. That should not be a big issue since they are easy to convert if we can live with potentially "skinny" triangles.

Oh, you can upload polygons (convex or not) too. For this, one would use TIndexedFaceSetNode instead of TIndexedTriangleSetNode. One example is on https://castle-engine.io/viewport_and_scenes_from_code#_building_a_mesh_using_code . The TIndexedFaceSetNode has a boolean property Convex, you can even set it to false to make "careful triangulation" that accounts for concave polygons too. By default Convex is true and we make trivial calculation assuming each polygon is convex.

My example https://gist.github.com/michaliskambi/067414b28ab3b14ea4c19e072a927a23 uses triangles just because I didn't know whether the input is triangles or polygons :)

Is it possible to use multiple meshes / circles within a single collision object (e.g. for head and torso of a character)?

In TIndexedFaceSetNode you can have a number of polygons, and they can be "disjoint". So if someone wants one collider with multiple "islands", this will work indeed.

Unless one wants multiple colliders (and e.g. connect head and torso rigid bodies using constraints). Then it means multiple TCastleMeshCollider components and so multiple TCastleColliderFromPhysicsEditor . If that is a feature we need, then the TCastleColliderFromPhysicsEditor could share an instance of a loaded data.

coordinate system direction (top left vs bottom left)

CGE coordinate system puts (0,0) in bottom left. By default, Y grows up, X grows to the right.

collision flags / bits / masks

We have collision layers, just 20 layers, https://castle-engine.io/physics#_layers .

Though they are specified in rigid body (sibling component to the collider). It would not be straightforward to change them from the collider, so I'd suggest to not do this initially.

bounce vs resititution

We have Restitution, see https://castle-engine.io/apidoc/html/CastleTransform.TCastleCollider.html .

mass vs density

We have both Mass and Density, see https://castle-engine.io/apidoc/html/CastleTransform.TCastleCollider.html . If one specifies non-zero Mass, then that is used. Otherwise, if Mass remains zero (default) then we calculate it using the Density and collider sizes.

The underlying Kraft "mesh collider" doesn't have any useful mass calculation, but it is also forced static.

The underlying Kraft "convex hull collider" seems to have a mass calculation.

Basically, if you already have "mass" available, then it's probably better to use it.

pivot point ?

Each collider may have it's own translation, i.e. https://castle-engine.io/apidoc/html/CastleTransform.TCastleCollider.html has Translation property. So, you can have pivot in any place necessary.

shape / mash identifier

Our collider components have names, to identify them from Pascal. They can be changed from CGE editor, and must adhere to Pascal identifier rules. I think we don't need an additional identifier from PhysicsEditor for start -- users will effectively associate them themselves, by loading proper PhysicsEditor data into proper TCastleColliderFromPhysicsEditor .

I currently don't have sufficient resources to dive into the depth of the Kraft engine you are using...

Of course. You should not need to -- that is, whoever takes on this job (whether PhysicsEditor or CGE devs), should be able to just use existing public CGE APIs. No need to dive into Kraft integration, the Kraft API should be "hidden" in CGE.

If there's any need to for particular work in CGE (e.g. expose "convex hull collider" -- I think it will be best for this case), I'll do it. Adding "convex hull collider" to my TODO list right now anyway, I see we don't expose it yet. But we will -- I'll just add a boolean flag Convex to TCastleMeshCollider .