Add support in vertex shader to output world position for fragment shader to go along with new 3d direct rendering

[MikalDev]

Reviewed guidelines

• [X] I have read and understand the suggestion guidelines

Checked for duplicate suggestions

• [X] I checked for existing similar suggestions

Summary

Wonderful news on opt-in to direct rendering with 3D objects! This will allow us some interesting effects with 3D shapes and objects.

We need one more thing to enable more effects for the new 3d direct rendering feature for effects. This will help for effects like 3d shape fragment lighting.

Can you please add a varying output to the default vertex shader, just passing through aPos, so we know the world position of the fragment.

So please add in webgl2 vertex shader: out highp vec3 pos

in main(): pos = aPos;

Also, please do the equivalent for webgl and webgpu. This will get the frag shader the world coordinates needed for world based frag lighting and other world based rendering effects.

In terms of impact, if the following shader does not use pos, the shader compiler could compile it away. Even if it does not compile it away, it would seem to have small impact to have an unused output which is just a pass through.

Thank you for the consideration and great beta release.

Possible workarounds or alternatives

I don't know of workarounds using the standard C3 SDK, effects or C3 expressions.

Proposed solution

So please add in webgl2 vertex shader: out highp vec3 pos

in main(): pos = aPos;

Why is this idea important?

Will enable more world based effects such as 3d fragment based lighting, height based fog, snow coverage, etc.

Additional remarks

If you need an example addon that uses the new vertex output, I can supply it.

[constructVOD]

Shadows and Lighting are needed to make modern games. Ashley please help develop this addon or make your own in this year. Each serious game engine should hav this feature to give posibility to make pro games

[CreatedbySeere]

It would so beneficial for the future of Construct, please add this!

[MikalDev]

Here's an example of what would be possible with this request.

(It is done using a quick Monkeypatch for the default vertex shader to add pos = aPos)

The lighting is done through an effect addon using the new 3d direct rendering effect plugin option

[MikalDev]

Additionally you can see in the corner of the above example that this technique will also work with 2D elements, such as sprites. It will also work with sprite meshes w/ zElevation variations.

[mOOnpunk]

Yes please.

[NickR-Git]

Additionally you can see in the corner of the above example that this technique will also work with 2D elements, such as sprites. It will also work with sprite meshes w/ zElevation variations.

THIS makes it extra-cool. Not just through the ability to match up 2D with 3D visuals, but straight 2D projects would also benefit and we'd have to spend less time developing our own sprite-based "lighting" solutions.

[MikalDev]

Right, for example here is a 1 light experiment with a sprite/mesh.

Note it does not do shadows for 2D or 3D, that requires additional tech/SDK.

[banquetburger]

Note it does not do shadows for 2D or 3D, that requires additional tech/SDK.

It's great that you're pushing this - very much appreciated. How far away do you think we are from being able to implement cast shadows?

[CodyRockwell]

This would be a dream come true!

[MikalDev]

Here's an example effect with a project template that does the requested change to the vertex shader to support the example effect (webgl2 and soon webgpu)

https://kindeyegames.itch.io/c3-3d-effects

I have sent a key to scirra support also, if needed.

[MikalDev]

Another example using eight lights with a modification of the drifting template.

[MikalDev]

Another example with a height fog shader based on world height

https://github.com/Scirra/Construct-feature-requests/assets/33675273/810fde2a-fa13-437f-8d49-34c7e996a11e

[MikalDev]

Snow shader based on noise + surface slope (world)

[MikalDev]

Distance and height based fog example using the tech that would be possible with this suggestion (banding due to video compression.)

[AshleyScirra]

The latest beta r393 includes a new example 'Integrated 3D engine'. This demonstrates how in combination with the HTML layers feature, a custom canvas rendering 3D content with the three.js library can be inserted in to a Construct project and layered in between other 2D content rendered by Construct. As the Addon SDK v2 is based on the scripting feature, exactly the same technique and code can be used in an addon to achieve the same result and then expose some additional 3D features to event sheets, such as loading models and moving the camera around. This may be a better direction for third-party addons interested in implementing more advanced 3D content. Construct is designed primarily as a 2D engine, and even if we implemented the request here, the requests for more 3D engine features will surely continue. (First it was "we just need 3D shapes", then it was "we just need to be able to move the camera in 3D", then it was "we just need a 3D audio engine"; here we have "we just need a 3D rendering pipeline"; next we'll have "we just need 3D physics", "we just need SSAO", "we just need a front-to-back deferred renderer", etc... to me it is clear this will continue indefinitely until we have a full 3D engine, which is not something we intend to do at the moment.)

So with the integrated 3D engine approach, you can bypass the Construct engine entirely and not need us to keep hacking in bits of a 3D engine to a primarily 2D engine - instead you can drop in a fully-featured 3D engine and do what you like with it, and thanks to HTML layers you can still show other normal Construct content both above and below the 3D content.

[MikalDev]

The implementation of a separate three.js canvas without any integration with C3 besides being in the same document (no SDK integration used except for adding the canvas to the document) seems orthogonal to this request. It is a minimal integration with C3, C3 objects cannot be mixed with the three.js render and they do not share any depth data. it is vanilla JS, there is no evensheet or C3 related scripting involved. The controls are using dom events, not anything C3 related. Most importantly the layout editor cannot be used to place three.js 3D models in the layout to create a level, environment, etc.

This request is not to 'add a new 3d rendering pipeline'. It is a request to add an output from the vertex shader (the value already exists in the current C3 vertex shader, so it means declaring an output.) That is the request.

Add these two lines to the webgl vertex shaders:

out highp vec3 pos in main(): pos = aPos;

It does not require an SDK change. If the current effect (frag shader) does not use it, it will not impact effect performance.

It will allows us to do some very interesting effects with both 2D (sprites, etc.) and 3D objects (3D Shape, Sprite Mesh, etc.), based on their world position, distinct from their screen position and object rotation (which is difficult with current effects).

The new possible effects includes 2D normal mapping with C3 3D Camera changing and some of the above examples.

Please reconsider, this is not a request for a new '3D rendering pipeline' It is a request for a change that will enable amazing effects for 2D and 3D in C3 where are all the C3 events, scripting effects and objects are truly integrated together.

[AshleyScirra]

The point of my comment is: if you want to do advanced 3D rendering, I would suggest to use a real 3D engine rather than waiting for us to add bits and pieces of 3D to our existing 2D engine. Perhaps exploring the ways in which addons can use three.js as per the new example in Construct may get you a lot more capability a lot more quickly.

Further, as per the feature suggestion guidelines, please do not claim your suggestion is easy to do. These changes can often end up being very complicated to retro-fit in to an already complicated engine with two renderers, each of which work significantly differently; and far more complicated if they end up running in to graphics driver bugs, which can happen even with minor alterations.

[MikalDev]

"Further, as per the feature suggestion guidelines, please do not claim your suggestion is easy to do."

I did not claim that it was easy to do. I stated the required changes. If you think I claimed this, can you point out my comments where you got this perception from, since that was not my intent.

This suggestion is not only for 3D, it can also be interesting and helpful for 2D effects also.

[NickR-Git]

The point of my comment is: if you want to do advanced 3D rendering, I would suggest to use a real 3D engine rather than waiting for us to add bits and pieces of 3D to our existing 2D engine. Perhaps exploring the ways in which addons can use three.js as per the new example in Construct may get you a lot more capability a lot more quickly.

Further, as per the feature suggestion guidelines, please do not claim your suggestion is easy to do. These changes can often end up being very complicated to retro-fit in to an already complicated engine with two renderers, each of which work significantly differently; and far more complicated if they end up running in to graphics driver bugs, which can happen even with minor alterations.

People have been inserting these 2 lines for close to a year in real, actual projects, by people who know what they're doing - not just test scenarios designed to prove a point. They work. They do not break anything. There is little to test, because inserting these 2 lines has no impact on anything else.

[MikalDev]

The main focus of this request is to allow 3rd party effects and addons to expand what is possible for developers and their projects, adding new features and options for the look and content of their games. The point is to put that work of doing these new effects on 3rd party development, so they don't become requests and suggestions to the core C3 development path.

[MikalDev]

I am going to put a pause on this discussion on my side, I want to reengage with a more thoughtful plan considering Scirra's comments and direction, to work toward a solution and scope of work that may be more reasonable for Scirra, the addon community and interested C3 users/devs. In terms of my requests, I want to talk out the limited scope, so it does not seem like there will be no end to the parade of requests if one is accepted.

[MikalDev]

Closing, focusing on specific SDK V2 requests and Community 3D suite proposal.