I'm not sure that would work well in practice. Suppose someone wants to drop a 9-patch object or Text object on to a 3D layer powered by a third-party library like ThreeJS.
🙂
(or maybe this can be handled in a way that resembles how HTML Elements are handled when outside of an HTML Layer [AKA: logically in one layer, but rendered in a "virtual[for the lack of a better term]" layer)
That probably involves two sets of rendering code, depending on what they are rendering in, which is a pain for maintenance.
Indeed, inevitably. Therefore, the way to opt-in to make an object available in the special 3D layer could be to implement some "glue code interface" to instantiate, update, and maintain an instance in that library. I think 99% of the addon builders would be more than Ok with that.
It could be that object types that support such a special layer have to implement an onCreateRich3D(runtime, threejsScene), onUpdateRich3D(runtime, threejsScene), onDestroyRich3D(runtime, threejsScene) interface. Where `threejsScene` is provided by Construct. (oversimplification to clarify the idea.)
For the native plugins, having just Sprites, Tiled Backgrounds, and 3D Shapes supporting the special 3d layer would be sufficient.
I want to highlight that, in theory, the code for Sprites and Tiled Backgrounds is the "straightforward" (POC/non-production-grade) code I wrote [Construct Arcade Link]. Also, the author of MakeIt3D successfully wrote the code necessary for native Sprite animations to function. While clearly not production-ready code, these two examples demonstrates that such code may not be as much of a liability as it appears. (it will be some pain for maintenance, like everything... but perhaps less painful than the increasing 3d feature gap)
but now you have zones with different feature sets that aren't compatible, and you can't do something like decide to make an existing 2D layer in to a 3D one.
To some extent, this is the case with current 3D/2D layers: Once a project includes any 3D camera rotation, changing a layer from 3D to 2D will likely break the project and require some refactoring.
Still, it wouldn't be completely incompatible. Typically, the 3D layers consist of Sprites, 3D Objects, and Tiled Backgrounds. As long as these objects implement the onCreateRich3D(), etc interface, these layers could be transformed into a "special 3D layer" while maintaining their original functionality, enabling customers to switch seamlessly between standard 3D and "special 3D" layer types.
Ideally, an error message should prevent such a switch if the layer includes objects that aren't compatible with the "special 3d layer".
In my experience users do not understand such things. Instead - not unreasonably - they expect things in a commercial product that they paid for to just work.
I think this type of approach would be better explored via third-party addons, so it's not in the core product and can more easily be treated as an "beta" type technology that we don't support. So perhaps that's another direction we could explore, via exposing APIs in the addon/scripting system.
You're right. Users expect things to "just work," but I struggle to see how this is much different than the 3D/2D/HTML layer distinction users already deal with.
Sorry for the stubbornness... This is just some brainstorming on creating a foundation for addon developers to converge when choosing to leverage a third-party library. I truly believe this would help the Construct community quickly gain impressive 3D capabilities.
I wonder what all the talented addon developers would accomplish if they could just converge around a common `THREE.Scene` instance (AKA: the special layer), knowing that all they have to do is call `add()/getObjectById()` and manage their objects. (again, oversimplification)