Construct 3 r499

You're viewing a single comment in a conversation. View all the comments
  • 4 Comments

  • Order by
    • [-] [+]
    • UpvoteUpvote 1 DownvoteDownvote
    • Ashley's avatar
    • Ashley
    • Construct Team Founder
    • 1 points
    • (3 children)

    Making the lighting model extensible can be done, but I think it involves a lot more complexity than you might expect. For example Phong and PBR use different material properties, and other lighting models might use other material properties. So it's not just a matter of writing a shader, it also means defining what the material properties are, having the editor display those custom properties, update shader uniforms accordingly, store the material properties with instance data, handle undo for changes, etc. That's not currently possible with the SDK, so supporting that means developing a range of features to cover that.

    • I'm not sure I understand, the effects sdk already supports custom shader parameters. If we get access to the normals and lights we could implement custom (fragment) lighting already with direct-3d-rendering? (some helper functions like you added to wgsl would be awesome too for some common calcs like attenuation etc.)

        • [-] [+]
        • UpvoteUpvote 1 DownvoteDownvote
        • Ashley's avatar
        • Ashley
        • Construct Team Founder
        • 1 points
        • (0 children)

        Currently 3D lighting is a built-in feature of the renderer. It is not done using effects, because those run through the effect compositor, which is primarily designed to handle a sequence of 2D effects and has a relatively high performance overhead. So in my view using the effects system as a means to achieve this is something of a hack - it's just that it's currently the main way third-party developers can write custom shaders, but that does not mean it's a well-designed system to handle this.

    • So I guess instead of allowing us to do lighting in effects, you'd rather add a new Material addon type, which has access to lights, normals (maybe even the vertex shader and additional textures for normal maps for example). This way it would always be the first shader and could sidestep the awkwardness with effect stacking, where only the first effect can do certain things.

      That indeed would be more complex to add, but also sounds more robust.