Add 'DeleteEntity' node

[bentoogood]

• should be able to delete entities matching filter
• should be able to delete everything but entities matching filter
• should be able to delete everything from a point in the hierarchy down (opposite of current 'subtree' node)

[johnhaddon]

What does it mean to delete an entity but not delete that point of the hierarchy down? Does it just delete the object at that location?

[bentoogood]

I think possibly I was assuming it would re-parent any children of the entity being deleted to the parent of the entity being deleted.
For example - deleting entityC:

├── entityA
├── entityB
│   └── entityC
│       ├── entityD
│       └── entityE

├── entityA
├── entityB
│    ├── entityD
│    └── entityE

What do you reckon?

[johnhaddon]

I'm having trouble picturing a use case for that one - did you have one in mind?

In terms of implementation it'd be much cleaner to have a delete operation always remove the entire tree below the point being deleted, and I had imagined that that would be the most common use case (that and deleting everything except some specified part of the tree). If that is the case, could we keep the delete implementation simple by catering to those cases only, and implement the operation you outlined above as a combo of nodes as below?

  Scene
      |
      |________
      |               |
  Subtree     Delete
      |    _____  |
      |   |
   Parent

The SubTree would be rooted at entityC, and the Delete would delete from entityC down. We then Parent the Subtree back in underneath entityB.

It's worth mentioning that as well as this DeleteTree operation we're discussing, I was anticipating having operations to leave the tree intact but delete objects and attributes from specific locations - perhaps that also goes some way to addressing the above?

p.s. Don't think I haven't noticed your sly attempt to standardise on an entity naming scheme :)

[bentoogood]

If it's a pain to implement, and given that it could very well end up being a fringe case, maybe a gizmo that wrapped up a simple DeleteTree would do.

What if the filter matches more than one entity though? Wouldn't you have to have multiple SubTree+Delete+Parent sets to handle the re-parenting operation at match that affects the hierarchy? Will gizmo's be able to have dynamic content?

In terms of rationale, I was just concerned that as there's no direct hierarchy manipulation (i.e. drag and drop, or copy paste of entities), if users end up having to reshuffle scenes (whatever reasons might be) it's something that could be a bit clunky and time consuming to control with individual nodes.
So anything that could be done to ease the manipulation of the hierarchy would be swell.

Here's my very contrived example:

Say (for some crazy reason), user A is passed a scene cache containing

├── roomA_GEO
│    └── keyA_LGT
│             ├── floorA_GEO
│             └── chairA_GEO
├── roomB_GEO
│    └── keyB_LGT
│             ├── floorB_GEO
│             └── chairB_GEO
├── roomC_GEO
│    └── keyC_LGT
│             ├── floorC_GEO
│             └── chairC_GEO
etc..

they may quite sensibly want to remove all those lights and start afresh. Would be nice to help them out with that if it's possible, and avoid them having to wrangle large numbers of nodes in the NodeGraph to do it.
Like I said, it's a pretty contrived example and I'd hope we're rarely having to do that kind of thing - but the input is technically valid and people are people.

In terms of UX I was imagining something along the lines of these user facing params (either for a wrapped up gizmo or a fully fledged node):

• Filter
• Invert selection (or is this built into the filters?)
• Preserve children (or Delete children - if one makes more sense?)

[bentoogood]

For the atomic node to delete a location and it's children 'Prune' could be a good name.

For the inverse action (currently called SubTree) Isolate might be an option.

[bentoogood]

splitting off rename of SubTree in to another ticket #128