Wondering if this would be more feasible. If the user could specify three points for the shape then the normals could be calculated more easily trigonometrically as well as the area for mass/inertia calculations. Then, models could possibly be more easily made to collide as well if the model tris could be used to create triangle collision shapes automatically. Although this would probably not perform well, so some ability to create a model collision mask with lower polys could be provided.
EDIT: Thinking about it more, in conjunction with the supported shapes, there would have to be a depth for the triangle in 3D. If a front and back triangle were provided, then this would entail having to calculate collisions to a rhombus shape for the sides of the 3D object, so it would be more complex. Not sure if this would be the best way to thicken a triangle in 3D or not though, maybe the 3D experts can weigh in here Otherwise the other obvious way would just be to provide a 4th point and construct a pyramid style object with 4 triangle surfaces.
You can make a custom triangle shape for collisions with Defold Polygon Editor it would also be possible to make one manually with text editor once you know how the format works.
True, just was thinking, since it is a primitive shape it would complete the triad of triangle, rectangle, circle for primitives but itâs mysteriously absent. Thanks for linking though, Iâll look into this again. I do feel like Defold is a bit too reliant on 3rd party extensions for a free engine project however. Already we have to use RenderCam to achieve a reasonable baseline for camera usage without spending lots of time calculating projections, etc. I wonder why some of these seemingly crucial extensions/tools arenât being incorporated into the engineâŚ
Regarding the design philosophy, we want to strike a balance where we provide a lot of the common components in an easy to use fashion, while at the same time allowing users to create what they want/need.
We donât want to add every conceivable feature in the engine since it adds to the engine size, as well as the maintenance burden. Also, how things should be implemented is also something to be considered.
There are several areas where there is no âcorrectâ way to solve a problem, and users will inevitably ask for a different solution. A good example is a GUI system, different users want different things to happen when they interact with it. In such cases, we add the bare minimum of functionality for the users to solve the problem the way they like it. Another example is ofc the camera.
In some cases, we might incorporate functionality from a userâs extension into Defold. But we wouldnât do it without considering the added maintenance burden and/or the potential increase in engine size.
Already we have to use RenderCam to achieve a reasonable baseline for camera usage without spending lots of time calculating projections
Defold is a very community driven project, and it is built around the concept of using defold libraries (or extensions). I donât really see much of a problem in using code other users have written, if it works and is maintained.
Would the project be opposed to a tetrahedron collision shape contribution? I feel like this is primitive enough that users shouldnât have to rely on a 3rd party extension. Iâm looking into the code as of now and Iâve managed to add the âTetrahedronâ shape to the collisionshape add dialog (just using another icon as placeholder since Iâm trying to get the shape working.)
I also see a âbtTetrahedronShape.cppâ in the \external\bullet3d\package\bullet-2.77\src\BulletCollision\CollisionShapes directory which implies it should be supported by Bullet physics. For a physics shape to be supported must it be included or implementable in both Box2D and Bullet or just one or the other? Maybe you can clarify this for me. Iâm keen to get this working since I feel like it would open up a lot of creative possibilities for the engine to have more primitive collision shapes.
For that particular issue, I do agree that we have a very limited set of shapes.
Some of the design comes from (I believe) a slightly strange assumption (imho) that the developer would switch from 2D to 3D physics (or vice versa). The question is then, what to do with those shapes that are not supported. However, we already do support the capsule in 3D, but not in 2D, so itâs clearly not a hard rule. (Although itâs ofc possible to implement a capsule in 2D)
I would say, for a âsimpleâ polygon shape like this, it makes sense to support it in both 2D and 3D.
I agree with that. Probably best to have some depth to any shape added and then let the developer correct any issues in 3D if they decide to switch to 3D. As long as the âshapeâ facing the camera is correct. For a triangle a tetrahedron makes the most sense to me since it just is adding one extra point to add depth to the shape in 3D.
EDIT: After adding the shape I see an error: âclojure.lang.ExceptionInfo: handler â:addâ in context â:workbenchâ failed at â:runâ with message âNo matching clause: :type-tetrahedronâ
java.lang.IllegalArgumentException: No matching clause: :type-tetrahedronâ Do you know where the :workbench related code is by any chance? Iâll keep searching for it just wondering if you knew though already
EDIT2: I think I see where it is, probably in scene_shapes.clj? Iâll see if I can add the tetrahedron shape to the scene next.
I went with tetrahedron just to match the bullet physics name for the shape. Pyramid might be more game-friendly however. However, if one searches Google for âPyramidâ one finds architectural articles vs searching âTetrahedronâ reveals geometric articles which are what is being searched for more specifically. I donât know how far I can get yet with the implementation. There are quite a few things to do just on the editor side before the physics even get involved
EDIT: I have the engine/editor building with super-early-work in progress code for the tetrahedron. However, I might be missing something necessary. Iâm seeing the following when I attempt to add the collisionshape:
clojure.lang.ExceptionInfo: handler ':add' in context ':workbench' failed at ':run' with message 'SCHEMA-VALIDATION'
clojure.lang.ExceptionInfo: SCHEMA-VALIDATION
Doing an fgrep for the phrase SCHEMA-VALIDATION but assuming this doesnât turn up anything useful have you encountered this one?
Okay thanks! Hoping I can get this feature in, but Iâll probably have to spend sometime to make sure the code quality is good after. Still learning my way around the codebase
This actually tripped me up a bit the first time I messes around with collisions: I saw that capsule doesnât work in 2d and then assumed that sphere wouldnât either, since itâs also a 3d shape.
For searchers here is a 2d capsule / pill .convexshape you can make a shape like this out of 2 circles and a square but it wonât be watertight and so will introduce bugs if you try that.
If you have forked the Defold repo on GitHub you can perhaps do the changes on a branch and create a draft PR so that we can easily review the changes youâve made so far.
Sure, I forked it and made a branch on my fork here: https://github.com/Epitaph128/defold/tree/origin/DEF-5260 I havenât yet done the actual tetrahedron implementation yet. Iâm trying at this point to figure out how to setup things in the editor to support creating/manipulating the shape before I worry about the physics side of things. Currently still getting the SCHEMA-VALIDATION error. It could be because Iâm missing something like â(dynamic error (validation/prop-error-fnk :fatal validation/prop-zero-or-below? diameter)))â as in the â(g/defnode SphereShapeâ block. This is my first time using Clojure so most of my confusion is coming from there . Hopefully I can get something showing up in the editor and then go from there.
Also, I was going to ask how you guys would prefer the input to be like. I was thinking a 4x3 table which allows the user to enter the vertex data points and then the validation should verify that itâs actually a tetrahedron. I wouldnât want to require the user to specify the points in any required order but Iâm not quite sure how to accomplish yet. Ideally, I think it would be nice if the editor side would arrange the vertices in the proper order and then it could re-validate on the engine side but wouldnât have to do any re-arranging at that point.
This should be part of the design document, so that we can discuss the design before the implementation.
For instance, this shape will share the characteristics of the Box and Sphere shape in that it will be an âimplicitâ shape, i.e. that you will specify things like width and height, not individual points.
Reading the Wikipedia article on tetrahedrons I see some forms which might be hard to support using simple size measurements like width or height: https://en.wikipedia.org/wiki/Tetrahedron such as mirrored sphenoids and irregular tetrahedrons. However neither of those forms of shapes are easily created using rectangles, capsules, or spheres. It would be nice to be able to specify the vertices directly since many shapes are creatable with four vertices and fit the definition of tetrahedron.
I donât think we should go that complex route altogether.
Either, something like a pyramid, that makes sense in both 2D and 3D, or better support for custom shapes through our buffer format (and possibly through .dae)
It would be extremely nice to be able to programmatically work with some custom collision shapes for sure. I was thinking tetrahedrons could maybe fill the gap between the current feature set and that which may take a ton of effort. Since even then a 3D model could be made to collide by creating tetrahedrons to cover the tris of the model (although that would probably be quite laggy except for simple models.) Not sure if the engine would support such a thing anyways since Box2D is meant for 2D physics, but I do see bullet is included which supports 3D.
For custom shapes in 3D, the artist will usually create a (relatively) lowpoly mesh shape that fits the visual mesh well.
To support this, we need to be able to set a .buffer resource to the collision object somehow. That way, we can precreate resources, or create them programatically at runtime.
Otherwise the other obvious way would just be to provide a 4th point and construct a pyramid style object with 4 triangle surfaces.
