refactor(flame_3d)!: Allow LightComponents to be nested#3883
refactor(flame_3d)!: Allow LightComponents to be nested#3883luanpotter merged 4 commits intomainfrom
LightComponents to be nested#3883Conversation
…rials decide themselves how lights should be used
| void update(double dt) { | ||
| // NOTE: this ensures the matrix gets computed if need be, so that | ||
| // the light position moves with it's anecstors. | ||
| worldTransformMatrix; |
There was a problem hiding this comment.
this feels a bit hacky - why is the same not needed for other nested components? 🤔
There was a problem hiding this comment.
Because the Object3D is computional but the Light one isn't, worldTransformMatrix is a getter so if it doesn't get... get it doesn't compute and in turn the light inside a nested component would not move
We only compute it when needed, to prevent unnecessary computations and for light we just need a little get call ✨ it's cached if nothing changes so it isn't expensive most of them time
There was a problem hiding this comment.
I guess I was confused as to where this value is actually "read" every tick, but I see it is just sharing memory with the light getter.
| ..setVector3('Lights.positions[$index]', light.position) | ||
| ..setColor('Lights.colors[$index]', light.source.color) | ||
| ..setFloat('Lights.intensities[$index]', light.source.intensity); | ||
| } |
There was a problem hiding this comment.
tbh I don't see why not keep these as methods inside each Light subtype, I thought that was more organized (but same behaviour either way)
There was a problem hiding this comment.
Because that would force users who want to write custom materials to follow the same pattern
Lights are an inherit part of materials so all the logic should be in its respective material and how they act on different lights (including custom ones)
There was a problem hiding this comment.
got it, so we might have different (non-spatial?) materials in the future with different light behaviour and different shader code
luanpotter
left a comment
luanpotter
left a comment
There was a problem hiding this comment.
Awesome! glad you found a way that doesn't require navigating the comp tree every tick
luanpotter
deleted the
refactor(flame_3d)!-allow-LightComponents-to-be-nested
branch
2 participants
Description
LightComponentscan now be nested inside anyComponent3Dallowing for a more flexible light system. On top of that refactored the light system so that every Material decided how lights should be applied.lights.mp4
Checklist
docsand added dartdoc comments with///.examplesordocs.Breaking Change?
Related Issues