relationship between Object3D and Light

[MichaelJPCT]

i thought of a method that saves memory and make program code more clean: sharing list between objects(or lights).
often several objects (or lights) have the same setting, they only need one list.
a good way in practice is like this: user creates a list, then set the list to several objects.

[EgonOlsen]

thanks Egon, it works.
please also add object list for Light.
the logic is this, if a light has list and the object is not in list , the light is off for this object.

this test is needed only if object has null list.
if object1 has light1 in list and light1 has object2 in list, light1 in fact can lit object1 and 2.
or you may have other way to cross check these 2 types of list.

Actually, I don't really like this idea. I think that one entity should be the defining one, in this case, it's Object3D. Putting the invers logic into another class causes nothing but confusion IMHO.

please use null list if list is empty, because null doesn't refer to additional memory space.

The list is null unless you add something to it.

[EgonOlsen]

i thought of a method that saves memory and make program code more clean: sharing list between objects(or lights).
often several objects (or lights) have the same setting, they only need one list.
a good way in practice is like this: user creates a list, then set the list to several objects.

That wouldn't really work, because Light is (for historical and performance reasons) just a wrapper around an int value. When adding a Light to the Object3D, what you actually do is adding an int to an internal list. So a shared list of Light instances would have to be converted to individual int lists per object anyway, which eliminates the saving alltogether. Maybe something like

Code: [Select]

shareSpecificLights(<Object3D>)
would work better? That way, I could just copy the internal int list behind the scenes with the same effect.

[MichaelJPCT]

it's good enough as long as the user can write clear code to manage it.
thanks.