engine
engine copied to clipboard
playcanvas
Refactor of Frustum.containsSphere
Refactor of Frustum.containsSphere was returning values 0,1,2 but the result was only tested as if bool. Also, MeshInstance culling that is using it was then returning false, 0, 1, 2 values, which are different types. Element custom culling functions also return boolean.
Being able to differentiate between in and intersection can help speed up hierarchical traversal (in means all children are also in). Even though this isn't currently used, it could be helpful in future?
Yes it changes the API .. but I very much doubt anybody uses the distinction between fully in and partially in. Even the engine does not use it .. I never did in my life.
If we in the future need this, which I doubt, we can always add it in in a consistent way.
Other option is - we keep the public API as is, but create new internal function. But I'm pretty sure this is not necessary.
Yes it changes the API .. but I very much doubt anybody uses the distinction between fully in and partially in. Even the engine does not use it .. I never did in my life.
If we in the future need this, which I doubt, we can always add it in in a consistent way.
Other option is - we keep the public API as is, but create new internal function. But I'm pretty sure this is not necessary.
Well, previously there was always backwards compatibility guaranteed if API is public. Unless it was no other way (like Scripting 2.0, Sound API, etc.) Some power user could be using that method, and there is no simple way to say: "nobody uses it".
What advantage do see changing this API @mvaligursky? Not sure I see it right now.
Seems there is some resistance to merging this, @mvaligursky. Perhaps it's worth closing it for now.
