How to (un-)register, delete components (lights)?

[carschno]

Hi,
In the context of Dynamic3D-Project#17, I have been stuck with understanding the global registry of objects.

Looking at specific component types, for instance tours or actions, the CVTours._tours and CVMeta.actions classes respectively keep a list of the existing components. When a delete action is triggered through CVToursTask and CVActionTask, the object is removed from that list, which seems sufficient to remove it.

I reckon that lights do not follow that pattern. The only list of lights seems to to be in the IDocument interface, which is only used during (de-)serialization, as far as I can see.

I am considering to add a global list, for instance to the CVDocument class to:

1. add newly created lights to that list upon creation/deserialization in CVDocument.lights
2. create a new CVLightsTask class that deletes a light object from CVDocument.lights when a delete event is triggered

However, I have realised that the implications might be difficult to see for me. @gjcope would you be able to outline the implementation of how components are tracked in general, and more specifically for lights?

[carschno]

More specifically, I wonder if there should be a CVLights classes as a container for lights. It could be initialized in NVNode.fromDocument(), similarly to how CVMeta is (among other things) a container for actions.

[carschno]

It is a long shot, but looking at the CVLightTool class (which does not seem to be used, as far as I can see), @framefactory might have some useful memories on the matter.

[gjcope]

Hi @carschno , we do indeed use CVLightTool (as well as the rest of the tools) in the Tools and Settings toolbar of Voyager Explorer.

That class will show you one example of how to grab a list of light components in the scene:

dpo-voyager/source/client/components/CVLightTool.ts

Line 65 in 6dfd285

this.lights = next ? next.getInnerComponents(CLight) : [];

Taking a look at component creation:

dpo-voyager/source/client/nodes/NVNode.ts

Line 81 in 6dfd285

fromDocument(document: IDocument, nodeIndex: number, pathMap: Map<string, Component>)

we see that the scenegraph component hierarchy is mapped directly to the document. And the document schema defines a 'lights' node with an array of light children:

dpo-voyager/source/client/schema/json/document.schema.json

Line 371 in 6dfd285

"lights": {

so we can also grab this grouping node like we do in CVScene to iterate through the lights.

As far as removing components, it's a good questions as we haven't had much call for it up to now. The closest thing I can think of is when we are disposing of a document:

dpo-voyager/source/client/applications/ExplorerApplication.ts

Line 221 in 6dfd285

this.documentProvider.activeComponent.clearNodeTree();

Keep in mind that with scenegraph components like lights, there are also correlating nodes in the (Three.js) render graph that will need to be removed as well, so it's probably best to use an existing 'dispose' method to make sure that the node/component/object is all disconnected/cleaned up.

[carschno]

In the case of lights, I figure that this concerns the light object (e.g. a CVDirectionalLight component), and the corresponding CTransform model, as well as the NVNode to remove it from the navigation panel too.

Removing those, however, causes an error:

update - DirectionalLightHelper.ts:45:32
TypeError: can't access property "position", this.light.parent is null

I suppose I need to identify the right child objects first and dispose those as well in the right order (bottom-up in the node tree).
Anyway, this already helps me greatly to get un-stuck, thanks! I will try to find my way through the node tree.

[gjcope]

Yeah, sounds like light helpers may need to get disposed in the respective light dispose methods if there is a dependency there. The current helpers are relatively new.