Closed luanpotter closed 2 months ago
@wolfenrain I think I came up with a nifty solution to solve the problem of LightComponent vs Light. however I got excited and also attempted to solve other problems :P
@wolfenrain removed the group component, please lmk if this makes more sense to you
still keeping the separation of obj3d/comp3d; lmk if you want me to drop that as well.
@wolfenrain removed the group component, please lmk if this makes more sense to you
still keeping the separation of obj3d/comp3d; lmk if you want me to drop that as well.
Yea let's park that for now as is, we can always talk about it with the rest of the team later!
Left one comment on an open thread but apart from that LGTM!
@wolfenrain addressed final comments!
Description
Implement a basic light abstraction.
Still only supports one light for now, and no parameters other than its position. Note: I will fix the 0-lights case when I add support for multiple lights.
A few complications arose that led me to revamp our component system a bit. Basically splitting the
Component3D
class into a more fundamental version of itself that only includes the 3D positioning stuff, and none of the rendering stuff, and what used to beComponent3D
becomesObject3D
(I am not sold on the names, feel free to suggest replacements).I also added a
Group3D
class to allow for people to create groups of components without carrying the rendering code. Of course you can still add children to Object3D as well. I am open to removing it and just makingComponent3D
concrete instead.The image below explains the new structure:
The difference between the 3 "light" classes:
LightComponent
→ interacts with FCS. is Component3D, thus carries the positionLightSource
→ describes the light in abstract terms (minus position). used both byLightComponent
andLight
Light
→ base description of a Light as a Resource. FCS agnostic. includes properties (source) + positionAgain, I am open to any renames.
FAQ
why separate component3d and object 3d?
not really needed but I didn't want light component to "carry" the rendering code that is not used. that also makes the distinction more clear as objects are completely different than lights. that way we don't have to have a definition of "non-light objects/components"
~why do we need group3d?~
i removed group3d!
~again not really needed, you can add children to objects, but if you want a pure container (no rendering), this would make more semantic sense. other options would be to not have anything (tell people to group things using object3d) or make component3d concrete (tell people to use that). having group3d consolidates the separation of light as its own thing.~
why some classes end in 3D and some classes end in Component
answer (please help)
Checklist
docs
and added dartdoc comments with///
.examples
ordocs
.Breaking Change?