Cleanup RendererSceneRender::GeometryInstance#63345
Conversation
c140feb to
6539fdc
Compare
|
Ok, also applied this to the pair functions. Cleaned up nicely I think. |
|
Two more outstanding questions I want to add here:
|
I think changing it to a class is fine. If not just for style/consistency. I don't know about inheriting from Object though. I'm not sure it will benefit from anything that Object would provide. We should wait and see if it will be helpful once we get to the point of overriding GeometryInstance.
I don't have a strong preference here, but it may be nice to separate it out into its own class. But again, this could also wait until we are ready to implement |
I'd prefer splitting it out now, especially if we decide to change it into a class. I've found that moving code into a new file really causes havoc on rebasing and increases the likelihood of code changes getting lost. Better to get it over with now. |
|
Inheriting Object is probably too inefficient, the bindings to GDExtension will likely expose this a bit different. |
That is what I worry about as well which is why I haven't made any such change yet. We do need to think about how we're going to expose the object through GDExtension then because that requires an object to be registered with ClassDB right? |
6539fdc to
0bd042c
Compare
|
Thanks! |
|
It looks like this broke the GLES3 renderer (crashes immediately after opening any project). [bisected to this commit] |
Part of the render cleanup we're doing, after discussing with Reduz we're changing a number of classes in the render device implementation where we can have a base class with basic state and just override methods for the implementation.
RendererSceneRender::GeometryInstanceis one such class. As the data obtained from our scene for a geometry instance is fixed, our base class can capture this data, while the implementation in subclasses defines how this data is stored on the GPU for rendering.