Mikal's Forum Posts

  • I'll follow down the rabbit hole...

    construct.net/en/make-games/manuals/addon-sdk/reference/graphics-interfaces/iwebglrenderer

    What if there was a way to override all of these types of calls, including what is done in the C3 renderer.

    e.g. if C3 called Quad3D2(tlx, tly, tlz, trx, try_, trz, brx, bry, brz, blx, bly, blz, texQuad) it could be directed to a wrapper around a three.js call to draw a Quad3D2.

    This would be slower compared to what three.js render could do, but all of the normal C3 behavior might be available.

    Do it both in the editor and runtime, basically replacing C3's renderer, but use all the rest of C3 functionality.

    Translating a 3D model to C3, would probably just be represented still by a bounding box.

    Or is this the _worst_ of both worlds.

    ------------

    On a different topic in terms of textures, I am imagining three.js or babylon.js, etc. will be in a separate context, so we'll either need to ignore C3 textures and focus only on three.js textures or transfer them over outside the context and upload them to GPU again for the different renderer.

    As Skymen mentions, a big challenge does seem to be getting larger access to the C3 editor, to make a 3D editor to create levels during editing. Will there be a large increase in the editor SDK API surface for us to work with?

    For placeholders in editor, perhaps we could generate textures on the fly for things like C3 cubes, etc. which are 2D snapshots of the models rendered from each side of the model, fully lit. At least this way there will be _some_ representation of the models in the editor besides a bunch of black and white dice. For this, it would then be useful to pass the texture data in the other direction too.

    With vanilla C3 render for the editor as placeholders we might end something like the below, trying envision how useful it might be.

  • Ashley

    Here's another way to look at this, don't focus on the 3D aspect. These are requests for SDK V2 for existing C3 addons, so they can be compliant SDK V2 instead of using engine internals. Which you have stated in the past is a big goal for SDK V2 and justifies why you are requiring 3rd party addon devs to do so much work moving to SDK V2.

    It is not an ask to add new features. it is exposing to the SDK V2 functionality that already exists in C3, but we would to use it in a SDK V2 compliant way.

    How do we get to SDK V2 and port SDK V1 addons so that we no longer need to touch engine internals, if we don't have the discussion of what is needed.

    In terms of priority and not being able to do workarounds that do not use engine internals with existing SDK V2, we can review the list.

    The first one is most important, it can't be functionally done in SDK V2 yet, instead of using internal engine without the change.

    The second one on rotation would be very helpful, but is more of a performance focus.

    The third one is I hope is already in your plans, support SDK V1 functionality.

    The fourth one allowing access to mesh points rounds out the existing mesh SDK, but if needed they are work arounds like having a separate object like JSON shadow the points in C3, but seems to be a unnecessary complication.

    Can we reset and look at this from the standpoint of SDK V2 compliance and working towards that goal with this specific list of requests.

    Can you please comment on what is possible for future SDK V2 in this regard to help with SDK V2 porting of existing addons to make them compliant.

  • Ashley yes I have tried (using babylon.js engine). It is not a good experience with C3. Rendering to one 2d plane does not allow for 3d to be mixed in front and behind c3 elements.

    Another large downside is that you cannot compose a 3d scene n the editor. It can only be seen at runtime. No level design in editor, no placement of characters or props where you can see them.

    None of the other C3 features can be used with the 3d objects rendered via js.

    My point is that this is the limited list of requests that will enable the community to do the work of adding 3d in an sdk v2 compliant way to C3, Scirra does not need to create a 3d physics engine or 3d model/animation system or 3d lighting and effects - these will be done by and supported the community, not Scirra.

    Our point in showing all of these examples is that we are already where we need to be to create great c3 3d games and edu apps, we don't need additional requests beyond making the current state of addons SDK v2 compliant.

    Please review the limited list above, if you have alternatives to these limited requests, please consider discussing them or if some are more possible to implement than others, the addons can be changed to adapt.

    This the SDK V2 work you mentioned before, working between you and addon devs on what is needed for already existing C3 addons to become SDK V2 compliant, so we can transition away from touching engine internals and make C3 addons forward compatible with future C3 changes. Lowering support requests for Scirra and offering other great features in C3 that Scirra does have the resources to do.

  • I think you'll have to make a suggestion / feature request for this. However, it might be because they want to keep the underlying data structure private to keep the SDK clean.

    Depending on your usage, you could just create your own JSON object or class and use it in scripting and expose it to events via C3 functions that use scripting.

  • Right now it still depends on use case. So, experiment with your project, try both renderers and see the results. Look at both CPU and GPU usage.

  • Ashley, can you please could provide your thoughts on this. I created a limited set of SDK V2 requests to enable community 3d addon development. What do you think of implementing the functionality of the SDK V2 requests in light of this?

  • I've done work like this with dynamic textures before (I made an addon that used the SDK to update a drawing object addon from a canvas). I tried it with a few different ideas, including 3D, Spine, Babylon and I did find it to be a performance bottleneck.

    The first Spine addon was something like that also, updating a C3 dynamic texture from a separate canvas / webgl context that was rendered by Spine. This was also a bottleneck which is why I jumped through so many hoops to implement spine webgl rendering direct to a C3 dynamic texture in the C3 webgl context. With SDK V2, the goal is to render spine with only SDK V2.

    I don't know if it still works, but here's the addon (it has an example of rendering to a separate canvas for spine webgl and then using that canvas to update a C3 dynamic texture in the addon.)

    construct.net/en/make-games/addons/312/elementquad

  • Dokse's example with 3DObject and 3D Effects (frag light)

    Subscribe to Construct videos now
    Subscribe to Construct videos now

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Zero Protocol Demo - 3DShapes + effects

    Subscribe to Construct videos now

  • Smaads Escalation - 3D Shape, Mesh and effects

    Subscribe to Construct videos now

  • 3d shape, some 3d model, ssao

    Subscribe to Construct videos now

  • 3d models, ssao effect and lighting effects

    Subscribe to Construct videos now

  • 3D Showcase, 3d models, effects, physics (PixelMetal samples)

    Subscribe to Construct videos now

  • I want to express my sincere appreciation for Scirra's dedication and innovation in developing Construct 3 (C3). The continued improvements, driven by both Scirra's creativity and the valuable suggestions from the community, have made C3 an amazing game development tool. I see that SDK V2 is aligned with this direction.

    However, as user demand for 3D functionalities grows, I believe a collaborative approach can further enhance C3's capabilities. This proposal outlines a community-developed 3D add-on suite that would not only empower users with 3D features but also remove the 3d feature pressure from Scirra's valuable resources, to allow more focus on other areas of C3 development.

    This proposal outlines a suite of three FOSS (Free and Open Source Software) projects:

    1. 3D Object: Handles 3D models and animations (already FOSS).
    2. 3D Effects: Manages 3D lighting, height fog, and other visual effects.
    3. 3D Physics Behavior: Provides realistic physics simulations for 3D games, including kinematic character controller

    These projects leverage C3's unique visual scripting and event interfaces, allowing for rapid development without coding. They are currently functional but require changes to comply with SDK V2 and completely eliminate any engine hacks.

    To enable this suite with V2, I propose the following limited and prioritized SDK V2 requests:

    1. World coordinates for effects (Git #236): Essential for 3D lighting and effects.
    2. GPU 3D rotation (Git #230): Improves 3D object and shape rotation performance.
    3. SDK V1 functionality support in V2: Ensures backward compatibility with existing add-ons, without any internal engine access.
    4. Mesh data access (Git #283): Allows for features like 3D text and physics tri-mesh terrain support.

    I have prepared examples showcasing C3's 3D capabilities with these addons and without any addons. It shows the viability of C3 doing a nice level of 3D in commercial and educational projects. The intent is that this collaboration would benefit Scirra, the product, and the entire community. The examples follow this post.

    I am open to discussing this further through any available channel (forum, Discord, email, etc.). Thank you to the community for their feedback on this post. Looking forward to feedback, alternate approaches, etc.

  • Headbang Games do you mean you are using browser text rendering or composing letters from boxes used as pixels?

    If browser rendering, across all browsers it seems difficult to turn off 'font-smoothing'.

    I think I understand the problem better, the issue is with how C3 implements the text object and how it is blitted to a lower resolution canvas.

    I think HBG means to use HTML rendered canvas separate from c3 canvas (e.g. using C3 HTML layers) to render at screen resolution to get a sharp effect. I've tried a quick experiment and talked with the OP about this and they are doing experiments. They are also using High quality scaling.