And since children aren't evaluated until they are referred to with children(), you can't know how many objects they will create until you refer to them, and you can't refer to them because you don't know their indexes because you don't know how many objects their earlier siblings will have returned. And you can't know the value of $children until you've evaluated all of them.
I agree with @nophead here. In the example @jordanbrown0 provided, if you want children(1) to give you an empty(), then you need to add an else that adds the empty. Another way to look at this, is what if you want the if to actually change/determine that first child? So I think the if conditional should completely remove its subtree. I'm running in to this with a module I wrote that worked great on previous releases of OpenSCAD, but is now broken.
So given the current structure of the code, I'm not sure having the if remove its subtree is going to be easily done, so might have to look at what @nophead mentioned.
It seems reasonable to interpret a null geometry differently from an empty geometry group, but I'm not familiar what existing interpretations/assumptions come with these. From what little bit of the code that I have seen, it seems like nullptr (null geometry) is return on most error conditions. Are there cases where an empty geometry group is returned to indicate something?
I think evaluation of a false 'if' expression is currently returning nullptr; so would it be safe to make that an empty group like @nophead said, and then ignore empty groups in operations (certainly the boolean ones, but probably minkowski too).
Reported via forum post
if()should take out the whole subtree, so the result is the cube, not the empty intersection between a cube and an empty object.
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
The text was updated successfully, but these errors were encountered: