solved Noobin' - Setting Mesh Rotation to Aim in a Direction

[Wingnut]

Hi gang!

I'm still having problems "aiming" mesh in some direction (vector).

I know, I know, I should have this mastered and memorized, but, not yet. 

https://www.babylonjs-playground.com/#BFM7EX#24

I have TWO cones that need to be set per the direction of a spotlight. 

#1.  The green cone (arrow1) needs its POINT aimed the same direction as the spotlight.  (-1, -1, -1)

#2.  The curiously black-sided blue cone (spotcone) needs its WIDE-END... aimed in same direction as spotlight.

I added the spotlight so I could "see" a -1, -1, -1 direction... and I know spotlights do direction correctly.  I could "steal" example code from spotlight direction-setting code, but that direction-setting code... rotates no mesh.  It only creates light directions, and lights aren't mesh.

The spotlight is positioned where the two cones meet.  And again, the spot is aimed -1, -1, -1, and it appears to be using that direction properly.

Feel free to turn-off animation in lines 101-102.  They are there only to prove that I have my pivot points set correctly for the two types of cones.

There are two un-coded important functions.  Lines 73-75 to set arrow1 aiming, and lines 80-82 to set spotcone aiming.

Lines 95 and 96 are where both do-nothing functions are called-from.

Can someone please assist me in coding arrow.setDirection(direction) [line 73] and spotcone.setDirection(direction)  [line 80] ?

That would be great.  Currently, cam is aiming +z.  We already knew that, because the -1, -1, -1 spotlight direction... is down, left, and backwards toward the cam.  Thanks again for any/all assistance/consideration.

[Pryme8]

mesh.lookAt(mesh2.position);

Soooo:

arrow.lookAt(arrow.position.add(direction));

spotcone.lookAt(arrow.position.add(direction.scale(-1)));

Did not test any of this though... but I think that's the ticket.

[Wingnut]

https://www.babylonjs-playground.com/#BFM7EX#25

Thx for comment, @Pryme8!  That formula isn't working.  (lines 98-99)

BUT... it appears that the SIDES of both cones... are aimed in the spotlight direction.

So, me thinks you are on the right track.  Perhaps a Dot or Cross or something fancy like that?  hmm.

 

I have a bake on the arrow1 master (called qcone) in line 22, but that's just a 45-degree Y-rot baked-in.  Not sure why that would cause trouble.

And spotcone has no bakes.   hmm.

Thx agn, P8 and helpers.   At minimum, I have a new clue. 

[Pryme8]

It will point in the positiveZ direction, so maybe create the arrow, transform it so the direction you want pointing is the positive z then bake those transforms before doing the above steps.

[adam]

You can also use lookAt's optional params to correct the rotation:

https://www.babylonjs-playground.com/#BFM7EX#27

https://www.babylonjs-playground.com/#BFM7EX#28

[Wingnut]

https://www.babylonjs-playground.com/#BFM7EX#26

Well done, @Pryme8!  It took both some rotational AND positional baking, but it worked!

I need to run it thru some torture tests, but, I think it's going to work just fine!

(Wingy hugs P8 and hands him a gift certificate for booze, drugs, and sex) 

Alright!!!  (Wingy dances around like an idiot).  Very good!

@adam Oh yeah, the optional offsets.  Good idea, thx!  With a minor switch of the offset signs (reverse both arrows), we're fartin' thru silk!  [#29]

(Wingy does even more dancing and smiling and hi5's).  First torture test looks perfect!   YAY!

[Wingnut]

Hi again.  For future knowledge, the spotcone had black sides... because its bottom diameter == 0.

I changed it to .001 (in line 51), and the spotcone side-colors started working.  [#32]

Reversing it... setting top diameter to 0, and bottom diameter to 8... no problems.  [#33]

Likely, there's a little epsilon-ish bug in createCylinder... when bottom diameter = 0.

[brianzinn]

Sorry to hijack this thread, but I have a noob question myself.  Do you need to bakeCurrentTransformIntoVertices()?  Does computeWorldMatrix(true) not accomplish the same thing in this case?  I'm just trying to learn when you would want/need to call one over the other. Thanks.

It doesn't seem to fit the situations outlined in the docs (http://doc.babylonjs.com/resources/baking_transformations), but there is an "etc."!

edit: I see the cqone is rendered rotated differently using computeWorldMatrix(..)... not sure why yet.

[Wingnut]

  Generally, I always use bake... to set the "natural" of the mesh.  Spin it, scale it, position it, and then ZAP IT with the magic wand.  Bvvvvrrrt... re-installed hymen. 

Hymenizing!  heh  ahem. It sets position 0,0,0, rotation 0,0,0, and scaling 1,1,1... without moving the mesh at all.   mesh.naturalize()    I think that would have been a better name, yet not very descriptive.

computeWorldMatrix?  That thing just scares me.

Want me to un-mark the thread solved, so we get more attention?

Check out what DeltaClaus said here:  http://www.html5gamedevs.com/topic/33815-movewithcollisions-issue/?do=findComment&comment=194139

I made another version of that PG.  [#19]  Check console.  Now activate the box1.computeWorldMatrix() in line 22, and run again.  Console different?  *nod*

But why box1, when we're moving box2?  hmm.  Anyway...

...if I were to describe it in my simpleton manner, setting cwm() "enlivens" the mesh so that it updates its changes FASTER THAN once per frame render.  It hurts performance, but sometimes it's necessary.  In this case... there was a console dump of WHERE ARE YOU, then moveWithCollisions, then WHERE ARE YOU.  That sequence surely happens in less that a single renderFrame of time-span.

But why box1?    box2.computeWorldMatrix(true); does nothing.  hmm.  Anyway, I wanted to be helpful if I could.  I probably just made things worse, though.

[brianzinn]

No need to make this an X-Files case - just curious.  computeWorldMatrix() is called the first line of bake, so no need to be scared!

Thanks for the explanation.   I just like to learn more stuff, so diving more into the engine code again.  I think also baking the changes may be faster renders, as less computations needed to scale/rotate.   Little bit of extra work up front.

[Wingnut]

*nod*  Possibly, that cwm() early in the bake... is used to "get all pending position, rotation, and scaling completed before opening the bakery". 

I think rot, pos, and scale (transforms?) are all affected, but not by the bake.  I think all 3 transforms are computed every frame, unless umm... freezeWorldMatrix()?

But I think when mesh cwm(true)... the transforms are applied faster than once per frame... or in other words... mesh onChangeObserver.

I could be wrong.  In fact, it's likely.  But I think freezing is the best perf, cwm(false) is 2nd place, and cwm(true) is Bogtown. 

Anyone buying that?    I bet a forum search for computeWorldMatrix would produce a pile of goods.

Hey, there's one from BZ. 

Yeah, you're a pro at this stuff, but you hang around with noobs like me, because you are kind  (hug).

Although all the big dogs are performance-driven, I bet Jerome has really worked hard to power-perf his Solid Particles System (SPS).  He's produced some SPS demos with HOLY CRAP-levels of mesh moving on the screen.  I can hear my CPU grunting and snorting on many of his demos. 

Goofy as this may sound, I ALMOST bought a gorgeous snowblower model for $64 a couple days ago... JUST BECAUSE Jerome has SPS/collisions working so well.  I want to get a road grader (motor grader) model, too, and perhaps a bulldozer and front-end loader.  (I have Tonka Disease)    For me, SPS stands for Soil/Snow Particle System.  heh.  Someday I'll start work-on Tonka Land.  You can "embank" on it.  ar ar.