Patch LGTM, but the name of the commit is not valid, it should not hide a change to a generic API behind a issue fix.
If we wanted that behavior, indeed non-currently-used pointers should be cleared when the source is switched. That way info would not be stored in file etc.
But as long as the reference to the…
The logic in this code is also wrong, these two pointers should be expanded, regardless of the source setting.
I would not accept this change at all. If you follow that logic, then you can also not link the force collection if its not needed etc.
This is expected behavior, no bug here.
Starting to implicitly filter out what data we import based on what is currently exposed to the user is a hard no-go. If you do not want your collection…
USDMeshReadParams
.
create_mesh_read_params
function. Remove unnecessary const
.
This call can be removed (see comment in collection_gobject_hash_ensure
).
Found some more possible tweaks and improvements...
Would say this should also use collection_gobject_hash_ensure
? While the overhead of initialization may be significant, this is often called in a collection manipulation context, where other calls (like object adding) will ensure the hash anyway... And then code is simpler, call to BLI_ASSERT_COLLECION_GOBJECT_HASH_IS_VALID
can be removed, etc.
You can save a lookup here by using BLI_ghash_ensure_p
instead... Since you know you'll always end up with a valid cob
for the given ob
key in that function.
Not sure why we still have this actually?
Should also call BLI_ASSERT_COLLECION_GOBJECT_HASH_IS_VALID
here.
This call can be removed (see comment in collection_gobject_hash_ensure
).