When will Construct 3 get support for 3D physics?

Generally the devs don’t give roadmaps, we just find out what they added when releases come out. Sometimes you can see what they currently working on when we see related features being added. That said we haven’t seen many 3d features added in a bit.

We can make feature requests on the suggestions platform, but features such as full 3d rotations seem to be delayed indefinitely as the dev calls it complicated.

Anyways we can do some physics on our own. We can use the distort mesh feature to make full 3d rotation, then the rest is math.

Here is a test I made for one die. I have some ideas to improve it and make it work for multiple dice but it may take a bit to implement when I get a chance.

https://www.construct.net/en/forum/construct-3/how-do-i-8/create-3d-dice-rotation-167723?kws=Dice

It's a little frustrating that they've said 3D features received more excitement than anything else in years and then... nothing. Can't even handle basic 3D rotations because, apparently, math is hard. Total nonsense. Guess that's their MO though.

Construct remains primarily a 2D engine. Unsurprisingly when we added some extra 3D features there was a lot of excitement, but also a lot of further requests for things like animated 3D models, 3D lighting and shadows, 3D physics, 3D collisions, 3D features in the editor, etc. etc. If we did all of that, not only would it take years, but we'd essentially be building a full 3D engine. While that might be cool, it would probably amount to building a whole new product. It's important to have focus, and our goal is still to focus on building a 2D product, but with some fun extra 3D additions - for example an otherwise 2D platformer but with a few elements of 3D added in, along the lines of the 3D platforms example.

Construct remains primarily a 2D engine. Unsurprisingly when we added some extra 3D features there was a lot of excitement, but also a lot of further requests for things like animated 3D models, 3D lighting and shadows, 3D physics, 3D collisions, 3D features in the editor, etc. etc. If we did all of that, not only would it take years, but we'd essentially be building a full 3D engine. While that might be cool, it would probably amount to building a whole new product. It's important to have focus, and our goal is still to focus on building a 2D product, but with some fun extra 3D additions - for example an otherwise 2D platformer but with a few elements of 3D added in, along the lines of the 3D platforms example.

Not asking for anything complex like 3D lighting, physics, collisions, etc. Just simple (and it is simple) object rotation. I'd be remiss if I didn't point out people have already figuring out how to deal with 3D physics and collisions so it is somewhat eyebrow-raising to read the standard response when it comes to any feature requests that would make life better for every user, regardless of whether or not their game project features 2D or 3D gameplay.

As for animated 3D models, that appears to be handled quite well by the 3rd-party addon created by Mikal... which really should be an included feature, but that's a conversation for another time and leads down a rabbit hole of discussion around why C3 is doing so much on the CPU when webGL/GPU has support for handling for more on the GPU out of the box. But, again, another time.

Another extremely basic feature would be 3-axis distance, which we can do fairly easily manually, but given the addition of 3D positional sound, it seems like it would tie into the functionality that's already been created for that, as you're already checking 3-axis distance AND direction.

Individual requests may often be presented as simple, but many things that may seem simple are in fact very complicated and time-consuming to develop. Further, if you add up all the 3D feature requests across all the users making them, it amounts to developing a significant chunk of a 3D engine, and that's not a goal for us with Construct right now.

Individual requests may often be presented as simple, but many things that may seem simple are in fact very complicated and time-consuming to develop. Further, if you add up all the 3D feature requests across all the users making them, it amounts to developing a significant chunk of a 3D engine, and that's not a goal for us with Construct right now.

So 3D positional sound was added because it was easy, and other things aren't, so you won't add them, which doesn't matter because Construct is a 2D engine, even though you just added 3D positional sound, which would require some or all of the same ground work as, say, the very specific example of a 3D distance(x,y,z) method, that was given because users pretty much know how you'll respond to most requests with a no, but who needs that anyway, because Construct is a 2D engine? Do I have that right?

We're a small team with limited resources. I say that a lot because it's true. I'd totally do absolutely all the things everyone ever mentioned if it was possible. Unfortunately we are bounded by the laws of physics. It's not that we're ignoring people, it's just that we get asked to do about 10x as many things as we can actually get done.

We do lots of things for lots of different reasons. Construct Animate is an effort to grow the business, and if it works out, it could permanently increase our capacity to develop Construct and get more done. 3D Audio was pretty much only done because browsers already implement a 3D audio engine, and Construct was already using it, but not letting you control Z positions so it was locked in to a 2D mode; we just added the ability to set the Z positions, which was straightforward.

Some things sound easy and turn out to be extremely difficult and time-consuming. Some things sound hard but turn out to be easy. Some things we do directly because of user requests, and others because we think it's the right direction for the company. There's a lot going on, and I can see how it might not always seem consistent. But we're always working hard to improve Construct, and no matter what we work on, we'll never cover absolutely everything that we're being asked to do, because there's just far, far too much we're asked to do for it to be remotely possible for us to do it all.

We're a small team with limited resources. I say that a lot because it's true. I'd totally do absolutely all the things everyone ever mentioned if it was possible. Unfortunately we are bounded by the laws of physics. It's not that we're ignoring people, it's just that we get asked to do about 10x as many things as we can actually get done.

We do lots of things for lots of different reasons. Construct Animate is an effort to grow the business, and if it works out, it could permanently increase our capacity to develop Construct and get more done. 3D Audio was pretty much only done because browsers already implement a 3D audio engine, and Construct was already using it, but not letting you control Z positions so it was locked in to a 2D mode; we just added the ability to set the Z positions, which was straightforward.

Some things sound easy and turn out to be extremely difficult and time-consuming. Some things sound hard but turn out to be easy. Some things we do directly because of user requests, and others because we think it's the right direction for the company. There's a lot going on, and I can see how it might not always seem consistent. But we're always working hard to improve Construct, and no matter what we work on, we'll never cover absolutely everything that we're being asked to do, because there's just far, far too much we're asked to do for it to be remotely possible for us to do it all.

Hey so I seem to recall the switch to a subscription model being pushed as the best way to grow the team. It's now years later, and it's not like there aren't highly skilled developers both using C3 already and elsewhere.

So... yeah. That particular lines of excuses has lost any effectiveness it may have once had. Maybe time to come up with a new excuse, the current one has aged like fine milk.

I suggest blaming the convoluted integration of javascript into a "you don't have to know how to code" engine, that is significantly more complex to use than just using javascript with any of the number of straight javascript engines that can do more, more easily integrate with external libraries, and are also free.