Fund raising for large animation improvement and tutorial video for the 3DObject Plugin. Puts animation on GPU and in worker almost completely offloading from the main C3 runtime thread.

More details and link to contributing here:

kindeyegames.itch.io/c3-3dobject-alpha/devlog/779636/fund-raising-for-large-animation-improvement-and-tutorial-video

C = CPU %, G = GPU %, F = FPS

Should C3 refocus the export options for desktop/steamdeck? Webview2 no longer has plans for linux or mac support.

nw.js and electron support windows, mac fat binary, linux/steam, so seem like good candidates, as far as I know, only nw.js/electron windows really supports overlays

Other options, Tauri?

In terms of steamworks support which is somewhat related to export, greenworks has started updating again with later versions of nw.js, which is nice. Greenworks and Greengrinds addons work with this.

Another option is:

github.com/ceifa/steamworks.js

Which works well on electron (and can be compiled for nw.js with a few hacks). It has more features vs greenworks and is actively supported. Electron supports overlay on windows. Another benefit of this build is that it is agnostic in terms of recent nw.js releases, you don't need to update with every new release.

MS notice on cancelling Mac and Linux dev for webview2:

github.com/MicrosoftEdge/WebView2Feedback/issues/1314

Thanks to Salman_Shh for pointing out this post.

Another interesting request that may be relevant to this discussion:

github.com/Scirra/Construct-feature-requests/issues/237

Request to allow other 3D renderer to render in C3 context, for speed and finer grained integration (similar to what is done on Spine today (though the desire is for Spine to be fully SDK V2 compliant).

For example, similar to these:

For three.js - resetState()

threejs.org/docs

For babylon.js - wipeCaches()

doc.babylonjs.com/typedoc/classes/BABYLON.Engine

It would be difficult to render into the C3 FB directly, but the other engines could render into a texture in the same context that is used by a C3 drawing object would be efficient and fast and can be integrated at a finer grained level than a html layer (this is what I ended up doing for current Spine and it works well.)

Rendering out of context and sharing with C3 (e.g. via texture download and upload from canvas is slow, I tested this with Spine previously and it was not useable in terms of performance.)

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)

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)

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.

Latest updates, 3D object support and Sprite mesh support.

Available here: kindeyegames.itch.io/construct-3-cannon

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.