Proposal for Community-Developed SDK V2 compliant 3D Add-on Suite

4 favourites
From the Asset Store
Add SubRip (SRT) subtitles to your videos in Construct 3
  • I initially replied here, but to avoid diverting from the original topic, I made a separate thread:

    construct.net/en/forum/construct-3/general-discussion-7/custom-3d-renderer-instead-182406

    I think Mikal's proposition deserves to be discussed and I don't want my response to take away from that.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • These are requests for SDK V2 for existing C3 addons, so they can be compliant SDK V2 instead of using engine internals.

    This means you ignored a warning in the SDK documentation specifically saying you should not do that. We will make a best effort to support all existing SDK v1 addons with additions to SDK v2, where feasible and where in our judgement we deem it important, but we still reserve the right to say "sorry, you shouldn't have done that, and that won't be supported any more - we tried to warn you".

    I would still rather you tried to use the approach of importing a 3D engine than getting us to continue adding bits and pieces of a 3D engine to Construct's own renderer, which will never be enough.

  • As skymen pointed out we are looking at integrating a 3d engine and it requires sdk v2 to expose a lot more engine APIs to get close to the level of C3 integration for 3d that is available now with addons. Changes to the editor to support 3d layout craetion with models. More addon APIs to get internal data to map between C3 engine and the seprate render engine. All the work to make many 3D addon to have useful ACEs for event programming for a 3d game, leveraging C3 no code strengths.

    In this case I am following what you said previously, to work together to get SDK V2 to a point that previous popular addons can be covered by SDK V2, so there will be no need to bypass encapsulation.

    You said in regards to SDK V2 discussion:

    Over the next year or more we plan to be continually providing support, SDK improvements, and any other improvements we can to make it easier to move to the new addon SDK. Part of this project is being proactive over the next year to make sure the transition can go as smoothly as possible. We can't do everything right now, as we're only just starting the process and it will depend on feedback from addon developers, but we will be actively working on this in the long term.

    Here is where we are giving you feeback on improvements on ways to make it easier, instead you are proposing a huge amount of work, us doing the work to integrate a 3d engine to support events and useful in editor, also a lot of work for SDK V2 (many more apis for editor and engine). The previous 'integration' example was a toy, not anything devs doing 3d game dev with C3 find useful.

    Our goal over the next year is to increase the capabilities and APIs available for the addon SDK v2 so that you can do more advanced things with it, and try to make sure where feasible, all popular v1 addons can be ported to v2.

    It is feasible to add another output to the vertex shader, which is a pass through - to increase capabilities. So let's discuss doing that.

    I recognize that some addon developers do want to be able to do more advanced things with the engine; the best approach for that is a more comprehensive and documented API which is supported long-term.

    Here we are looking for you to stand by your words. For 3rd party devs to take on this large burden of porting to SDK V2, we want to work together to make SDK V2 the way forward and create a more comprehensive API.

    On my side on these requests, I can forgo API for GPU rotations, that would mean not adding a way to modify the MV matrices. I am not making any further requests for additional 3D capabilities.

    My hope is that you look back at your own words and reconsider this discussion and the specific request.

    Yes other developers may have a different approach than you do, but that is one of the points of having a more comprehensive SDK - to allow users to devlop differently than using the official addons. Dictating a single approach in a dogmatic way stifles the creative work that the community has already shown is possible using the wonderful C3 visual scripting development paradigm.

  • I will take a look at the integration points raised in skymen's thread. Perhaps we can do some work towards that over the next year.

    However making Construct in to a capable 3D engine is a huge amount of work - and likely endless work, regardless of whatever anyone claims about "we just need this one last thing". Providing APIs to integrate a 3D engine is also a lot of work, but probably not endless work, so while it seems a more feasible path, it's a lot of work either way. This will all take a lot of time and work no matter which path we choose, and that will require patience. Meanwhile there are other tools on the market that are already capable 3D engines, and if people really need a capable 3D engine to develop their game, then it may be wise to choose a different tool anyway, as it's not currently a goal of ours to develop Construct in to a fully capable 3D engine ourselves.

    Accessing the engine internals against our advice is not a sustainable or responsible way to develop software, no matter what results it can achieve. Our SDK documentation clearly stated that undocumented features may be removed at any time. Presumably you had a plan for what to do if the features you were using were removed, as the warning stated may happen. If the addon SDK v2 removes those features, then you should implement your plan for what to do in that case. If you didn't have a plan, or assumed it wouldn't happen, then what can I say? We tried to warn you about this very situation happening. In the other thread the gist of what I was saying is that we will make a best effort to try to make sure addons can be ported where feasible, but that is not a guarantee, and we reserve the right to say "sorry, we warned you". In this case it looks like there's a lot of work whichever way we go, we do not currently intend to make Construct in to a capable 3D engine ourselves, and integrating a separate 3D engine looks like it might be a better way forwards in the long term, and that will inform our priorities when considering what to add to the SDK v2.

  • Thanks for the reply.

    I don't want to generalize about all addons at this point. Better to focus on known requests, so more concrete to discuss. The specific request was to add the aPos output, no changes to c3 render engine, etc. change two lines of vertex shader code, which does not impact other shaders, render engine, etc.

    There are plans:

    - Stick with C3 SDK V1 LTS to maintain compat for this particular request

    - Discover new ways with SDK V2 version of C3 to implement the request - as has been stated SDK V2 is not complete, perhaps there are alternate ways with future C3 SDK V2 features.

    If SDK V2 expands to support in integrated editor 3d render of 3rd party, 3d object layout, etc. I will certainly help with that effort, it will be big (on both sides, Scirra for new editor API and runtime render support to mix with C3 object render and behaviors in a useful way and larger load on 3rd party for doing the visual events integration editor integration using SDK V2 editor APIs)

  • Ashley I appreciate this discussion, I had a different understanding about what you meant when you described supporting addons devs for porting to SDK V2. From this discussion, I understand better the limitations to the support you intend to provide. That is helpful. Along these lines I'll close the related world coord for shader and GPU rotate for object requests as discussed and rejected.

    On the other hand, we do already see some SDK V2 suggestions implemented and that does help with showing what may be possible in terms of SDK V2 and addon future development, not just porting (e.g. drawMesh() is appreciated for Spine (and perhaps Sprite2 if that releases)).

    That is helpful guidance for what SDK V2 suggestions to make and what SDK V1 era addons are likely possible to port to SDK V2.

    One other area that I think would help addons devs for the porting work is to know about SDK V1 functionality support in SDK V2:

    • Will SDK V2 be a superset of SDK V1 (all SDK V1 functions + additional V2)
    • If not, can you please let us know what functions will not be supported (in general terms for now, but details later will be needed to evaluate and implement porting)
  • I once did something similar to this: hllgln.itch.io/drive-up

  • Will SDK V2 be a superset of SDK V1 (all SDK V1 functions + additional V2)

    Yes, the goal is for SDK v2 to be a superset of SDK v1 in terms of the officially documented and supported capabilities. We promise to ensure any addon using only the documented and supported features in the SDK v1 can be ported to SDK v2. In some cases we may change how the API works, so code is written differently rather than porting exactly the same set of methods, but in this case it will still be capable of the same feature the addon was previously using.

    Undocumented unsupported internal details of the engine are not supported, never were, and may be fully removed and become permanently inaccessible in SDK v2 as we always warned they might. This does not mean SDK v2 is not fully compatible with SDK v1 or that it is a subset: as is standard in the software industry the only concern is what happens with supported and documented APIs, and in that regard, SDK v2 will be a superset.

  • Mikal and skymen, I would like to discuss a plan for a Construct 3 plugin that I dropped awhile ago, but will picking back up very soon as I port a project I was previously developing in Unity to Construct 3.

    You can see here the work that I've done to port Three.JS to Construct 3.

    https://fb.watch/sEdJUkBK5p/

    I've been thinking of this problem of 3D implementation in Construct for many years. Actually, for more than 10 years. I have approached the problem in many ways, and have never bared fruitful results. Until 2022, that is. That year, I had realized Construct 3's Web App nature meant that it was not limited only to the plugins of the engine itself, but could also be extended with Chrome extensions.

    My proposal, then, and what I've conceptualized and worked toward since, is a Chrome plugin that simply injects a 3D Editor into Construct. I would suggest two different ways it could render, either directly to a Viewport Texture which would update within Construct 3 like any world object, or within a separate editor that would be accessible via 2D/3D tabs at the top of the editor ala Godot style.

    The Chrome plugin and the Construct 3 Addon would work in conjunction to provide the whole suite of ThreeJS tools to Construct 3. I would like to create a public repo to work on this, and was wondering what you two thought of this plan and if you would want to contribute or provide input.

    If you wish to work together, I'm most easily reachable via Discord at: thechayed

    I'm looking forward to hearing back from you.

  • Hi CairoCreativeStudios

    Absolutely!

    Please DM me on Discord :)

  • CairoCreativeStudios ditto!

  • My proposal, then, and what I've conceptualized and worked toward since, is a Chrome plugin that simply injects a 3D Editor into Construct.

    Browser extensions are already a big source of compatibility problems and support requests in Construct, because they can easily break things. My advice would be to, wherever possible and to the greatest extent possible, develop a separate external tool and have some way of importing that tool's output to Construct.

    The big problem with browser extensions is they have no encapsulation. They can reach in to the internals of web pages and do whatever they like, even if the web page was not expecting that; and then the web content may change over time, and then break the browser extension, or the browser extension breaks the web content. Unfortunately this encapsulation-breaking approach is fundamental to the way browser extensions work. It is a constant headache for us dealing with support for customers who have some browser extension that does something unexpected to the page and then crashes Construct. People just see Construct crash and then think it's our fault. This is the same story as the Addon SDK v1 all over again, and regardless of what you may think of the Addon SDK v2, if you consider the lengths we are going to in order to prevent this happening, it should indicate to you the magnitude of the problem it is for us. If the option was available to us, I'd have probably already disabled the ability to use any browser extensions with Construct, in order to stop the endless compatibility problems. That is not something browsers let web pages do though.

    Obviously we can't stop you and you can build a browser extension if you want to, but that approach risks falling in to all the pitfalls of the Addon SDK v1. It could end up causing serious compatibility problems and support burden for us, and if it does, we may end up deciding to take action to stop the compatibility problems, which may then impact your browser extension.

    If you build a separate tool which does something like produce a file you then import to Construct, you avoid all these problems and it will probably work fine indefinitely. So I'd strongly recommend you do that instead of trying to use a browser extension to hack unsupported things in to a large, complex and continually changing codebase that is not expecting that.

  • Ashley

    Browser extensions are already a big source of compatibility problems and support requests in Construct, because they can easily break things.

    I understand your concern, Ashley. I have already considered this reality, so I have no intentions of actually messing with the internal structure of the Construct Web App. My proposal is simply to create an extension that overlays a 3D Editor viewport above the entire app, that has access to the local files that are being worked on in Construct.

    If you build a separate tool which does something like produce a file you then import to Construct, you avoid all these problems and it will probably work fine indefinitely. So I'd strongly recommend you do that instead of trying to use a browser extension to hack unsupported things in to a large, complex and continually changing codebase that is not expecting that.

    The separate tool I'm going to build is this browser extension. I will not muck up Construct, you have my word. If I do, and problems come your way, I will end development of the tool myself.

  • My advice would be to, wherever possible and to the greatest extent possible, develop a separate external tool and have some way of importing that tool's output to Construct.

    If you build a separate tool which does something like produce a file you then import to Construct, you avoid all these problems and it will probably work fine indefinitely. So I'd strongly recommend you do that instead of trying to use a browser extension to hack unsupported things in to a large, complex and continually changing codebase that is not expecting that.

    I largely agree with that point of view, but as stated in my other forum post, the fact that C3 does not do any kind of live reloading means it's actually extremely complicated to build any kind of external tool that has a decent UX.

    I recommend you look at my Construct Crawler tool that allows reading and modifying Construct 3 project files. The tool would be infinitely more usable if it did not require closing and reopening C3 constantly.

    I wrote it at the time with the intent of making it easy to refactor or extend with more functionnality in the future, but any feature I think of ends up being made completely unusable because of the archaic UX.

    Being able to do live reloads means external tools can be used with the project open, and this would also allow addons to communicate with external tools directly as well.

    Since the editor SDK is so limited, the only way for 3rd party addons to get data from the open project is either through an external tool gathering data from the project folder, or from an extension that gathers that data from the editor directly. Without live reload this significantly limits how useful external editors can be (since most likely an editor is not meant to read data but also to write back what you want)

  • I largely agree with that point of view, but as stated in my other forum post, the fact that C3 does not do any kind of live reloading means it's actually extremely complicated to build any kind of external tool that has a decent UX.

    What about the 'Reload all from folder' option for folder projects? You can have an external tool that changes files in the project folder, and then use that option to update the files in Construct.

    You can build a browser extension if you want, but it runs the risk that some time in future it permanently breaks with no workaround, and we won't help you as that's not the kind of thing we support - all I'd say is that I tried to warn you. If that happens then your work is largely wasted and customers may be unable to proceed with their projects. Usually experienced developers faced with a risk like that will do anything but that.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)