I know custom shapes have been requested for collision calculations. What about for now a triangle shape?

Questions
#1

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 :blush: Otherwise the other obvious way would just be to provide a 4th point and construct a pyramid style object with 4 triangle surfaces.

#2

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.

2 Likes
#3

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…

#4

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.

1 Like
#5

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.)

addshapetetrahedron
addshapetetrahedron.png543×668 21.1 KB

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.

#6

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.

3 Likes
#7

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 :smiley:

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.

#8

You’ll create the predefined shapes in c++ code, see the Box shape for example.

tetrahedron

I wonder if “pyramid” is a better “common” descriptor for the shape in both 2D and 3D?

#9

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 :smiley:

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?

#10

I haven’t seen that no. I’ll ping @vlaaad and @mats.gisselson to get some pointers on this issue.

1 Like
#11

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 :smiley:

#12

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.

#13

capsule_pill_2d.zip (287 Bytes)

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.

1 Like
#14

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.

1 Like
#15

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 :blush:. 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.

#16

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.

#17

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.

#18

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)

2 Likes
#19

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.

#20

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.

2 Likes