GDevelop 5.6 Adds Real-Time 3D Editor

For example in my view to do this properly, we'd need to expose to addons the entire editor UI library, such as tree controls, list views, data tables etc. so editor addons can make use of the same look-and-feel of the rest of the editor and not have to reinvent the wheel for things like a custom editor window with a tree view in it.

RE: Editor tools

I think this eventually deserves to be its own thread but Ashley I don't know if you are aware of this but I recently implemented my own editor UI API to fix this exact problem you're mentionning:

construct.net/en/make-games/addons/1534/editor-window-manager

This addon can't be added to projects but exposes an editor SDK for any other addon to create and manage new editor windows. It handles its own thing on top of C3 and of course I had to handle minor quirks but I was able to handle most things just fine.

This manages an extra layer above C3's UI and doesnt properly integrate with the Undo Redo system but at least this is completely off of your shoulders.

I think it's best to focus on making better APIs that allow us to do real things in the editor rather than expose the UI system if that proves to be too painful.

The ONLY thing that would be nice I suppose would be if we could get a proper URL for when I pop out the window for security things as browsers otherwise block some common actions, but it's not too bad.

I used it in this other addon that lets users make custom tools using JS scripts directly from within the project files, and with a default minimalist UI component library

construct.net/en/make-games/addons/1535/editor-tools

And I used it in this other experiment I made that allows people to make themes directly from within the editor.

construct.net/en/make-games/addons/1533/caw-theme-creator

Check these out and let me know if you're ok with it.

I tried my best to integrate best I could with the editor and the theme but its hard to do without messing with engine internals. Exposing info about the currently loaded theme, or having classes for external editor tools would be nice but not necessarily needed.

I don't know if you are aware of this but I recently implemented my own editor UI API to fix this exact problem you're mentionning:

I'm afraid this makes me quite nervous. This is not something we officially support and the editor is not at all designed to accommodate this type of thing. It risks repeating the issues of SDK v1. If we change Construct and suddenly thousands of people's editors are crashing on startup because we accidentally broke your editor UI API - something I'd say is likely, because we don't support it, don't know what it does, we don't have an officially supported API for it and so we don't know how to not break it - then we face disaster, and everyone will be contacting our support, and blaming us for releasing a broken update. I think that outcome is ultimately inevitable and there is no acceptable way to properly support it for commercial software that is meant to work in the long term.

Editors crashing on startup is a worst-case scenario and prevents users even being able to update or uninstall the addon causing it. That is a nightmare scenario worse than we faced with SDK v1. It is such a serious outcome that we may well take steps specifically to prevent it, much like moving to SDK v2.

The addon does not run any code on startup that relies on anything C3 does if that makes you happier

Just take a look at the addon's code and let me know if something in it would cause an actual issue instead of reaching for the nuclear option.

What would you even do, add Mutation observers and nuke the editor if you detect any unauthorised HTML? That would actually cause the editor crashout you're talking about rather than anything I might do.

The editor SDK is already in an SDK v2 encapsulated state in case you're unaware. The whole point of making my own layer is to decorrelate it completely with the editor, the system would actually keep running just fine even if the editor underneath stopped existing.

Also, I tried to make it as foolproof as I can. If the things any of these addons need stop existing the way they do, the addons just do nothing instead of crashing.

There is really nothing to worry about, and if you want I am more than happy to spend any amount of time explaining everything I did so you do know if anything might cause an issue so I can take steps to changing them right now.

The whole purpose of this addon is to provide a single common interface for implementing editor UI rather than have each addon handle its own interface which would actually be super scary. That way there is only one thing to worry about rather than a dozen addons all managing their own thing.

If this still does not satisfy you, I don't know what to tell you. I'm not planning on deprecating this system so if you'd rather cut your leg off than tell me not to step on your toes be my guest, I'm not the one dealing with the consequences.

What an exciting thread!

I really appreciate the ethos of Construct 3, where things are tied together. Sometimes things have to happen (like HTML layers), other times it's a logical situation (expecting 2 behaviours to not conflict with each other), but beyond that, very rarely will you encounter a feature in C3 that doesn't work with another feature.

My ignorance is probably going to be shown with what Three.JS offers, but, I feel confident that Scirra can tackle their own 3D implementation - Three.JS is excellent from what I've seen/read, but at the end of the day, Scirra have figured out extremely effective and optimal design choices for 2D game design, from cheap collisions to optimised rendering, all without the user barely needing to configure anything. Maybe it's bad for me to say this as it makes third-party addon devs, or those familiar with Three.JS, have less use for their skillset or become restricted in some ways, but I stand by my point as of now.

With 3D, I thought I'd share what I feel would be the most-categorically-important starting point, and also share a list of the features I feel are more deserving of a voting-based system.

In order, starting with most important, here is what I feel is most needed:

1. Full rotation of a 3D shape.
2. Upgraded Layout view for 3D objects.
3. Loading in gltf model files.
4. 3D Bounding box collision.
5. Basic 3D lighting (New Object: 3D Light).
6. Basic 3D animation (from gltf files).

Then the features I feel should be a voting case:

• Enhanced 3D Collision (Raycasts, esp for FPS games with shooting, but also for allowing users to design effective movements for their platformer games and such. Hopefully the ability to get useful information such as X Y Z, reflection angle, or perhaps even the name of the part of the model (assuming you can separate, e.g. a Person model's head and body, then it's much easier for someone to make a "headshot" system). If these types of info are expensive to generate, then allowing to disable/enable would be great.
• Enhanced 3D Lighting (Whether a different form of lighting, shadows, etc).
• 3D Physics
• Further usage from the gltf file format (unsure on what could be gained from this, but bones, leaf tree visibility hierarchy, etc).
• Multiple 3D Cameras (Placeable even within a layout, e.g. a TV effect, or a car's rear-view mirrors, without relying on Drawing Canvas (which may not even be possible!)).

With all 5 important points added, it feels like a beginner could easily step into C3 and get cracking on many types of 3D games, from First Person Shooters to Platformers - Whereas right now, every point listed becomes an issue for someone trying to get started.

1. Full rotation - A requirement that does not need an explanation!
2. Upgraded Layout view - Needed for ease of designing a 3D game - Free cam and such.
3. Loading in gltf models - IMO This is a critical barrier and is high on the priority list - Being limited to just a few shapes is not what someone expects, there must be some way for someone to load their own objects in.
4. 3D Bounding Box collision - A great starting point for simple collisions; whilst alone is not capable for wacky 3D projects, it's still extremely powerful to get started. I am unsure on the appropriate way for Scirra to handle this, whether the bounding box should expand/shrink depending on object rotation, or if its size shoudl remain static, or if the bounding box should also rotate (imo I think not, to keep collisions cheap and efficient - Although choice is always good to have!).
5. Basic 3D Lighting - I am noob with 3D overall, but I understand gltf models come with normal data to help with lighting, I presume "vertex lighting", so a new plugin for "3D Light" would be amazing to see, allowing beginners to throw together a scene and make a nice atmosphere.
6. Basic 3D Animation - Again, I am noob, but I presume there's a variety of animation types, from a likely-simple "move vertices" to "bone animations". As long as there's some form of animation, even if one must adapt their model file to utilise this, then this is the last feature to make a valid game - Rotations, collisions, lighting, sound, animation - All good!

In order, starting with most important, here is what I feel is most needed:

1. Full rotation of a 3D shape.
2. Upgraded Layout view for 3D objects.
3. Loading in gltf model files.
4. 3D Bounding box collision.
5. Basic 3D lighting (New Object: 3D Light).
6. Basic 3D animation (from gltf files).

- Jase00

I agree with these 6 points. I think this is everybody's expectation when it comes to 3D in Construct.

I want to emphasize that these features alone would already create a significant divide between 2D and 3D (exceeding the difference we see with HTML layers). For instance, implementing 3D bounding box collision with rotation would break compatibility with all the 2D principles that Construct is based on (an example is collision cells, which must be 3D and support various rotation angles, as detailed at construct.net/en/blogs/ashleys-blog-2/collision-cell-optimisation-914).

Additionally, Scirra would need to manage features that only function within a 3D layer/context, such as lighting, glTF support, bone animations, 3D bounding boxes, and rotation.

My ignorance is probably going to be shown with what Three.JS offers, but, I feel confident that Scirra can tackle their own 3D implementation [...] Maybe it's bad for me to say this as it makes third-party addon devs, or those familiar with Three.JS, have less use for their skillset or become restricted in some ways, but I stand by my point as of now.

I, too, feel confident they can tackle their own 3D implementation with everything you asked... but it will take 10 years.

Implementing these 3D features is orders of magnitude more costly (in time, effort, maintenance, and bug-proneness) than 2D. I'm concerned that attempting to reinvent the wheel will result in two years passing with only a few new 3D shapes added to Construct, rather than the six features you mentioned.

Realistically, tackling 3D will inevitably involve dependencies. For example, I doubt Ashley is thinking about creating (and maintaining) a fully fledged gltf loader from scratch.

BTW: I'm not an addon developer and I don't have a skillset in ThreeJS. I actually dislike it. The proof of concept I posted before was made with a different 3D library (BabylonJS). Since ThreeJS is a more stable, tested, and widely used library, I believe Ashley will see it as a more prudent option.

MasterPose is right. Of course, a fully featured 3D engine developed by Scirra would be the best, but let's be realistic!

My take is that Scirra should focus on creating a clean API/UI/wrapper around a mature 3D library/engine... I'm sure it will involve significant effort, challenges, and a lot of "pain", but at least this approach would address the increasing feature gap in a feasible way.

Please: take a step back, look at the ways the industry has come up with over decades to ensure reliable software development, look at everything we already just went through with SDKv2 which was just re-learning those same lessons

To be clear I'm more than happy to take a step back. If you're willing to work with me to make it as safe as possible while still having it work somewhat even if it includes only managing popups and not including any CSS inside the editor, I'm also happy to do that.

I am reaching out to you with the express purpose of working with you to make it work sustainably, but when you react this way by immediately categorizing any experiment as an existential threat what you're doing is telling other addon devs that if they don't want to trigger a cataclysmic event they should hide their work from your eyes, which in turn will cause far more headaches for you.

I'm doing this because I know the need exists and I think I can do it in a way that minimises harm and I can communicate transparently about it. You also understand why the need exists and you know how useful it could actually be to have some form of custom tooling for advanced users.

To be honest, it is a bit terrifying to me that you would rather reach for extreme options that combats and destroys the work of dozens of devs who give so much time for your engine rather than first see how you can work with said devs and assume none of them have nefarious intents.

It looks like you have over 2000 lines of code making similar kinds of changes.

My code manages its own DOM element and has everything in its own bubble. Same for the CSS, it is scoped to only affect my elements. If you think it's still reaching too far, I'm happy to make any adjustments to make it reach less far. If having any amount of me messing with DOM is still too much, I can just open a popup window and handle custom editors exclusively in that popup window, that way it's in a completely different context and can't risk messing with your editor's DOM or CSS.

Even better, you could add a special div in the editor meant for any kind of custom content that would need to contain any of these edits that you can accept leaving alone, without having to do any of the extra work of maintaining anything.