Using a spotlight the function setDirectionToTarget
has an unexpected behaviour when first assigning a parent:
Note that without that line, the workspace illuminates just fine and the lamp follows the target.
However, explicitely setting it to the mesh position messes everything up.
I guess this is somewhat understandable in the sense that it just modifies its local coordinate direction, but is this really the intended behaviour?
Hmm 
I donāt see anything unexpected here. Since you move your sphere and you parent your light to the sphere, the direction should also be recalculated from your new parent.
I.E: If I set the sphere at zero position and parent my light to it, the direction is still correct/as expected.
However here, you are instructing to change the direction of light to be set to the parent (sphere) direction. Which means the new light direction is now the one of your parent.
I believe setDirectionToTarget is essentially ment for shadowing. May be this is not what you are looking for. In case, you should use ātargetā.
Yes you are right, I was just confused about which coordinate space should apply under which parenting condition. But nevertheless, for a couple of hours I am stuck with trying to bind a spotlight to a target.
What would be extremely helpful is a setParent() method for the lightsource. Unfortunately this does not seem to exist. Any idea, how to achieve something similar.
The lightsource is actually defined by some rays, which only exist in the world coordinate system.
Its easy to make to lightsource in the correct world position and direction, but I was unable so far to bind it without completely messing it up. I tried quaternions, world matix, rotations in the convention order orientations, their inverse etc. So far without much success.
Glad you got an understanding of it despite my āclumsy explanationā 
I was just thinking it might be more explicit like this (comment/uncomment lines #32 to #39)
Can you explain a bit further. You want a follow kind of spotlight, is it? Keeping the same direction or adjusting its direction to the direction of the target?
Maybe this playground is helping:
From the programming perspective. I am given a mesh and a wold-coordinate direction (a ray) from which to illuminate it and I need to figure out how to place the spotlight. I also would like to parent it, since otherwise I have to keep track of all spotlights in a list and clean them, once the mesh gets deleted.
One coudl argue that a directional-Light may be better, but then I need probably a huge procedural texture to cover the whole scene, which sounds inefficient.
OK, I think I start to understand. Point is Iām not eng, rather a designer and art dir. Understand I like when things are āsimpleā 
So, I guess I faced something similar before. You have meshes (eventually imported meshes) that the user can control. It might rotate, reposition or eventually rescale. And you want to add a light to it (because thereās no light attached to this mesh, else you would use āunlitā), correct? And you need a way to parent it to the mesh, because eventually the user will dispose of the mesh, yes? So, the solution I found for my similar use case might just not be the most āsexyā, but is simple and should work. Itās very basic. The idea is to create a new parent for the mesh and attach the light to this parent. Next you would just copy the position of box to the light. And then, in case of dispose, you would dispose the parent and all descendants.
Something like this PG below except of course, you wouldnāt do the change at runtime like in this quick and dirty PG, but on box transformation change/user input. Do you think this approach would work for you?
Thanks. This is a great idea. I will try it but using the setParent() method.
OK, playing some more with this, I finally pinned down the problem. Maybe this is a bug?
As you see the projection texture does NOT move with the rotating light-source but stays firm with the ground (i.e. the world coordinate system).
To me this is very odd as I expected the texture to be pinned to the projecting lightsource.
If you set āDoParentā to false in the script above, then the texture stays nicely fixed to the lightsource!
This is kind-of the opposite of what you whould expect. My suspicion: This is a bug. Maybe the texture offset (observable?) was detached from the lightsource coordinate system but it was forgotten to attach it to the parent coordinate system (or even back to the lightsource) after parenting?
Notice how the ProjectionTextureMatrix is not changing in the parenting case, but is changing in the non-parenting case:
Hmm, interesting Letās just ask the experts here.
Expected, bug or potential feature request, Iām not too sure. Thereās probably a logic behind this and we would also need to see what this change or adding would imply.
May be yours could kindly have a look at this? cc @Evgeni_Popov or @sebavan
Thanks again.
Here is another problem, where you possibly know the answer:
As you see this slighty more complicated object has problems with the spotlight. This probably has to do with the assignment of the zero position in UV texture space. As noted in the program, if you change Math.PI/2 to -Math.PI/2 everything looks fine. Is there a way to somehow fix this issue differently? It seems a bit odd, that the behaviour of the spotlight depends on where something has its zero Texture position.
OMG, a csg Humā¦ I have no faen clue. Not sure anyone has. The CSG is kind of a blackhole. We faced many issues with it. Had another discussion just recently. All I can do is ping again @Evgeni_Popov but if you already found a work-around for your particular use case, Iām not sure we can propose anything better at this very moment. 
Youāre right, itās a bug with the projection texture in the SpotLight class.
This PR will fix the problem:
For the CSG example, I donāt know why the uv coordinates arenāt correct when the rotation is +90Ā°, but Iām glad you found that it works when the rotation is -90Ā°!
Thanks a lot for fixing this!
Is there a way to include some of these PRs in my code development?
Or is there a nightly release which I can put in my JavaScript-Files to import?
As for the CSG, I did not find a general way to avoid that problem. However, playing with options, rotations versus different sizes in the box etc., seemed to help. Yet the interesting question is, whether this works then from all sides in the final object. I have no idea, how texturing with CSG opjects (or in fact any arbitrary meshes) works. But if it is just via a bounding-box, then I suspect that there is still a bug somewhere, explaining the above problem.
The PR will probably be merged today or tomorrow at the latest. When a PR is merged, itās available in the Playground the day after, and the npm packages are generated each thursday morning.
Regarding CSG, I donāt think thereās a bug in the code, but as @mawa said itās a strange beast!
Thanks for the info about the merging. Is the sound-pileup bug then already fixed? It seems like I am still haveing this problem.
By the way, I just found out, that loading a medium-sized (7Mb) hdr environment texture stalls my Pico-4 goggles to a halt which gives weired pixel artefacts during load. It looks like this is somehow achieved synchronously rather than asyncronously? With .env files I did not notice such a problem. But then this may also be because they are smaller.
Is CSG more strange than importing any mesh? I would think in the end a mesh is a mesh. Does the spotlight also have similar problems with imported meshes?
Would be great to keep the separate threads split as it might interests others as well and it would be impossible to find here.
@docEdub fixed it a couple days back so it might not be on npm yet. Please reply on the related thread.
The preprocessing as well as the generation of the harmonics is really heavy hence why we favor the use of env.
It would be the same in any mesh CSG or not if the normals/positions have been generated the same way.