Geometry Nodes: Improve geometry nodes evaluator api.
ClosedPublic
Actions

Authored by Jacques Lucke (JacquesLucke) on Apr 26 2021, 12:39 PM.

Details

Reviewers

Hans Goudey (HooglyBoogly)

Commits

Summary

This is a first step towards T87620.

This patch should not have any functional changes.

Goals of this refactor:

Move the evaluator out of MOD_nodes.cc. That it is easier to improve it in isolation.
Extract core input/output parameter management out of GeoNodeExecParams. Managing this is the responsibility of the evaluator. This separation of concerns will be useful once we have lazy evaluation of certain inputs/outputs.

I'm sure you have some plan for the inline comment, it's more of a question. The basic idea makes sense anyway.

source/blender/nodes/NOD_geometry_exec.hh
63	Do you expect there to be more than one implementation of this? I know the compiler might optimize away the virtual calls anyway, but it's just a bit confusing to have this specific thing generalized. Maybe I'm missing something.

This revision is now accepted and ready to land.Apr 27 2021, 6:11 AM

source/blender/nodes/NOD_geometry_exec.hh
63	I don't plan to have more than one "good" implementation of this. However, just because something is only used once doesn't mean that separation of concerns is bad in that case. It just reducces the things you have to care about when modifying the code. The compiler probably won't optimize the virtual calls here, but I'm not concerned about the virtual function call overhead here. We might have two evaluator implementations in the future. One is very good and is used in practice all the time. And another one that is very basic and less efficient. The benefit is that this would allow us to check quite easily if a bug is in the evaluator or an individual node. Anyway, I don't plan to have two evaluators any time soon, only when we run into bugs where we don't know what's wrong often enough.