How do I attach a light to a mesh ?

[altreality]

I want my light to move with the mesh, as in a car light.

 

This does not work :

 

            // Meshes - chassis            chassis = BABYLON.Mesh.CreateBox("car", 1.0, scene);            chassis.scaling = new BABYLON.Vector3(3, 1, 1.5);            chassis.position.y = 5.0;                        light0 = new BABYLON.SpotLight("SpotChassis", new BABYLON.Vector3(4, 5, 0), new BABYLON.Vector3(1, 0, 0), 0.8, 2, scene);            light0.diffuse = new BABYLON.Color3(0, 0, 0);            light0.specular = new BABYLON.Color3(1, 1, 1);           light0.parent = chassis;

 

[JCPalmer]

BABYLON.Light is a subclass of BABYLON.Node, so parenting should be possible.  All changes to position of chassis must be AFTER light0.parent = chassis.

[Dad72]

chassis.parent = light0;

light0.parent = chassis;

[altreality]

Tried  "all changes to position of chassis after light0.parent = chassis"

 

No luck. Note that I want to parent light to chassis and not vice versa which makes no sense for a car

            light0 = new BABYLON.SpotLight("SpotChassis", new BABYLON.Vector3(4, 5, 0), new BABYLON.Vector3(1, 0, 0), 0.8, 2, scene);              light0.diffuse = new BABYLON.Color3(0, 0, 0);            light0.specular = new BABYLON.Color3(1, 1, 1);                        // Meshes - chassis            chassis = BABYLON.Mesh.CreateBox("car", 1.0, scene);            chassis.position.y = 5.0;            chassis.material = new BABYLON.StandardMaterial("chassisMaterial", scene);            chassis.material.emissiveColor = new BABYLON.Color3(0.5, 0.5, 0);            chassis.material.diffuseColor = new BABYLON.Color3(0.5, 0.5, 0);            light0.parent = chassis;

If its not possible to attach then how can i get the  spot light direction to always align with a box mesh's x axis, no matter how the box mesh is oriented in space. The box mesh being the chassis of course.

[Dad72]

Ok:

 

http://www.babylonjs-playground.com/#UB1FH

[Wingnut]

Quote

chassis.parent = light0;

// or

light0.parent = chassis;

 

Dad72, I'm not sure if lights make good parents (the top line).  I'm doing some tests right now... trying to make a cone mesh parent to a spotlight.  I'm failing.  I'm still investigating why. 

Notice this:  http://playground.babylonjs.com/?6

Deltakosh does not parent the lightSpheres to the lights.  Instead, he continuously updates the lightSphere's positions... inside the animation function.  Interesting?  *scratch scratch*

Here's the scene I'm playing with... http://playground.babylonjs.com/#1TIIVY  (messy, sorry)

AltReality... you might want to notice lines 45 and 46.  somelight.setDirectionToTarget(somevector3) can be used to set a light's direction (mainly for spotlights and directionalLights), and it can also be put inside of animation functions... to make a spotlight continuously follow a moving mesh. 

But that's not what YOU asked-for.  You wanted a spotlight that stayed locked on the side of a chassis, no matter it's position or rotation.  Dad72's demo does that... and my demo just does it from an angle (and uses .setDirectionToTarget to do an initial direction setting for the light).

 

Now if I could just get the light cone to stay with the light and be angled the same as the light.  I'm still working on that part.    Sometimes I wish lights had a .showBoundingBox property. 

[Dad72]

Dad72, I'm not sure if lights make good parents (the top line).  I'm doing some tests right now... trying to make a cone mesh parent to a spotlight.  I'm failing.  I'm still investigating why. 

Yes I saw it afterwards.

 

Sometimes I wish lights had a .showBoundingBox property. 

I would also like this property, it would be very useful to see where the light is exactly. Deltakosh sowBoundingBox Lights is possible?

[Wingnut]

haha.  I don't think lights can have boundingBoxes or outlines.  I was joking when I said that. 

 

What would a boundingBox on a directional or hemispheric look like?  It would be as big as the entire scene because they have no substance (or lighting frustum).

 

But, yes, I know what you mean, D72.  Some kind of toggled indicator to show us the light's current .position and maybe it's direction when a light has one.  But, of course, hemisphericLights have no .position.  So that light has trouble. 

 

Yeah, lights seem to be a concept.  I think they might be "maps".  Just guessing.

[Dad72]

When I speak of light, I speak of the bulb. which emits light, not the distribution of light.

 

It's not a bad idea I think.

 

In the picture we see well the position of the light, that is what I speak.

 

[GameMonetize]

To get light position, you can display the debug layer and enable the "Clickable labels". Each light will receive a label and clicking on it can switch off/on the light

 

Parenting with a light is possible but only position will be inherited.

[GameMonetize]

A light can have a parent ( a mesh) and in this case direction and position should be updated. If it is not the case, please create a repro on the playground and I will fix it soon

[Dad72]

Oh yes it is true now have a debugLayer. it's really useful. 

[Wingnut]

@deltakosh...

Quote

Parenting with a light is possible but only position will be inherited.

http://playground.babylonjs.com/#2AKHZK

PG lights demo.  I have turned-off the animation of the lightSpheres, and set their .parent properties to the lights they represent.  No go.  The lightSpheres won't position with the orbiting lights.  But I am likely doing something wrong.  Help welcome.

@dad72 - where is the bulb on a directionalLight and hemisphericLight?  As far as I know, they don't have single points of origin.

[Dad72]

@Wingnut, the light can be positioned in a scene, it is therefore a position vector x, y, z and this point is worth seeing or what he is. Do not worry about the direction of the light but just its location. If you can attach a light to a sphere when the sphere is the location of the light. You see what I mean? it works for all the lights.

[Dad72]

.... oops bad exemple 

[Dad72]

new exemple : http://playground.babylonjs.com/#2AKHZK#2

active clickable label in debug layer

[Wingnut]

In demo 1, you are orbiting the children, and the parents follow?  nod.  Thanks.  Strange... but I don't have much experience with orbing families.    It seems to me that a person should be able to orbit the light parents, and the children follow.

 

In the newest demo, you are no longer using lights as parents, so that is not the current topic.  I was talking about lights being parents.

 

On the other subject...  http://doc.babylonjs.com/page.php?p=24638  No .position.  Where would you put the boundingBox (light gizmo) for that?  Always at .Zero()?

[Dad72]

Indeed for the hemispheric it is useless, but on the others ... but with debuglayer is resolved, we can see or are positioning the lights.

 

For the demo, so I reversed, because it seems that it does not work in this direction, the sphere does not follow the the light, but the light follow the the sphere. and I do not see the point of having an object follow one light. 

 

DK : A light can have a parent ( a mesh) => which is equal to light.parent = mesh no mesh.parent = light;

[Wingnut]

The point is...  http://playground.babylonjs.com/#1TIIVY  (my demo from post #6)... where I was trying to attach a lightcone to a spotlight.  This is how you make gizmos (bulb bounding boxes) for lights.  This is how deltaKosh would do it, too.  he would make a mesh, possibly wireframe like mine, and lock its position to the light.  Whenever the light changes position, so does the wireframe gizmo.  Having lights be a parent for mesh... would do this perfectly.

 

But, as DK says, a light's rotation is not passed to children.  And it doesn't matter, because, in the case of my spotlight cone, the wide end needs to face the light's DIRECTION and not its rotation.  So I wouldn't care if rotation was not inherited.  I wouldn't need it.  I need the light's direction to aim the cone, not its rotation.

[Dad72]

This is where you made the mistake I think. It is the object to move the light. Watch it here: http://www.babylonjs.com/editor/

 

The light is moving by the cone that is the parent of the light.

If you move the light, the object will not follow because I find no need to have to attach an object to a light.

Take the case of a car and of light following the car. we're not going to move the light for the car follow, but we're going to move the car, which will be the parent.

 

When you write "light.parent =" this mean: "the light has as a parent" and not "the light is the parent of".

[Wingnut]

 

because I find no need to have to attach an object to a light

 

Yes, I understand that you find no need for this, but some of us DO find a need to move mesh with lights.

 

Think about this, D.  A user is placing a light in a scene.  They want to have a gizmo/boundingbox... so they can see where the light is located in the scene (just like you want to do).  So they make a small wireframe box and position it to the light's position... by setting box.parent = light.

 

Now they keep adjusting the light (not the box)... until they get the light position where they want it.  Sure, they could adjust the location of the box, but the box is a temporary object.  They will be removing it from the scene in the end.  They only wanted to use the box to temporarily help them see where the light is located.

 

In your scenario, once they remove the temporary gizmo box, the light has lost its parent and thus lost its position.  The light now needs to be re-positioned. 

 

But if the light is the parent of the box (my scenario), then they remove the temporary box, and the light stays positioned.  The light is the master, the box is the slave. 

 

In modelers like Blender and 3DS, it is common to use the mouse to grab the gizmo and drag the light around with it.  Our ActionManager could do the same thing.  That is using the gizmo as a light-placing device.  When using the gizmo as a placing/positioning device, then yes, the light should be a child of the gizmo.  Gizmo is master, light is slave.

 

But there are those who attach a box to a light just to see where it is.  They don't want to drag the light with the gizmo.  They just use the box as a temporary visual aid.

 

So, yes, you might see no need to make a light be the parent of a mesh.  But some of us DO see a need to do that. 

 

Personally, I would like both options available. 

[Dad72]

Ok, I see what you mean. But DebugLayer  it is now possible to see where is the light without having to attach an object to the light.

 

I think Deltasosh'll shed some light on the subject  . can join an object to a light? because it does not seem possible at present we can only attach a light to an object but not inversse.

[altreality]

ok, so there has been a fair amount of discussion. But my question is about 

 

light.parent = object

 

Is this possible yet ?

[altreality]

For point lights we apparently can have a sphere be the parent.

Cannot yet have a mesh be the parent of a spotlight 

Here is an example   http://playground.babylonjs.com/#2AKHZK#3

Notice ...there is no red

[gryff]

Cannot yet have a mesh be the parent of a spotlight

 

Altreality: I think the issue you are seeing is that a SpotLight is a directional kind of light. The PointLight emits light in all directions.

 

I tweaked your demo a little so you can see that the central sphere is illuminated by the animated sphere at some times when the Spotlight is actually point at the sphere. Red Light Playground.

 

The animation in your example is only changing the position of the parent - not its orientation.

 

The attached image may explain it. At position A the Spotlight points at the central white sphere. At position B the Spotlight is no longer pointing at the sphere - because position the parent has  just been changed. You would need to change the orientation also, to keep the Pointlight pointing at the sphere.

 

Think of your car example. A car is heading north (ie the lights are pointing north) and makes a 90 degree right turn - the car itself has turned 90 degrees and points east  - so the headlights now point east. The car does not go round that 90 degree turn still pointing north.

 

 

Hope that helps,

 

cheers, gryff