You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
owlInstanceGroupCreate allows the list of child groups to be null. The documentation used to say (a PR has been submitted changing this) that this sets each of the children to a "null group", which together with the surrounding language implies that this is acceptable. However, if the child groups are not all set to valid groups before the parent group is used, it will crash. And, manually setting a child group to null hits an assertion if in debug mode and crashes if in release mode.
With the aforementioned PR, the documentation now clarifies that the children must be initialized before the parent group is used. So, there will no longer be an ambiguity. However, it seemed there may have been some interest in actually supporting null groups.
The parent would not have to be re-created every time the number of children changed; the parent could be created to hold a larger number of children, and the unused children could be set to null.
Supporting null groups would also remove the invalid intermediate state OWL can be put in where owlInstanceGroupCreate was called but the children were not yet set. For example, in a larger, interactive application, the loading or setup of a child object might get aborted for some reason, but the rendering might need to continue, and this invalid state might therefore lead to a crash.
The text was updated successfully, but these errors were encountered:
Agreed this would be useful. Only concern: what does optix actually do if you create a group where some children are "empty" (eg, prim cout being zero?). Reason I ask is that I'm getting nervous about us "purging" and/or reorganizing the list of child list(s) before we give them to optix - that is sure to create some issues. In other words I'd like to keep the 1:1 relationship between our child lists and the optix build inputs if ever we can.
If there's an easy way to turn a null child into a build input that optix still accepts (eg, making it a triangle mesh with 0 prims) then that's easy - but i have no idea if optix does accept BIs with 0 prims ...
owlInstanceGroupCreate
allows the list of child groups to be null. The documentation used to say (a PR has been submitted changing this) that this sets each of the children to a "null group", which together with the surrounding language implies that this is acceptable. However, if the child groups are not all set to valid groups before the parent group is used, it will crash. And, manually setting a child group to null hits an assertion if in debug mode and crashes if in release mode.With the aforementioned PR, the documentation now clarifies that the children must be initialized before the parent group is used. So, there will no longer be an ambiguity. However, it seemed there may have been some interest in actually supporting null groups.
owlInstanceGroupCreate
was called but the children were not yet set. For example, in a larger, interactive application, the loading or setup of a child object might get aborted for some reason, but the rendering might need to continue, and this invalid state might therefore lead to a crash.The text was updated successfully, but these errors were encountered: