solved How to change the orientation a plane according to ground orientation

[meteoritool]

Hello !

I need some help, after looking through many threads relating to rotation/orientation/translation, I still couldn't manage to find a solution...

I made a playground : There is a Ground with a height map, when you click on the ground, a flat Plane appears where you click.
With pickingInfo, I could modify the position of the plane, but I'd like also the plane to change its orientation to match the orientation of the ground.

https://www.babylonjs-playground.com/#95PXRY#28

Any help with this script would be greatly appreciated ? 

[sable]

Something like this:

https://www.babylonjs-playground.com/#95PXRY#29

Would need to be changed slightly if you wanted facet normal instead.

[Wingnut]

And if you are placing "markers"... and would like the marker to follow the terrain "contour", perhaps no plane, but instead... a decal?

Decals have one minor non-feature.  They don't drag/relocate well.  They are "grown" to match the contour of the underlying mesh, but don't like to change, afterwards.

The best way to drag/move an already-created decal... is to keep disposing and re-creating the decal... on every pointerMove.  erf.  Smarter to drag a "token" (like a little box, or just change the pointer cursor to a "hand grab" symbol), and then ONLY recreate the decal upon pointer-up (after dragging/moving is done).

Some have said that drag-around/move-around markers on bumpy terrains... is best done with little "patches" of heightMaps... one "little heightMap" per needed marker.

These "smart little heightMap" patches could continuously monitor the elevations of the big heightMap beneath them... AS THEY ARE DRAGGED.  Much like a magic carpet with VERY LOW ALTITUDE terrain-following capabilities.  Very liquid/flexible, depending upon heightmap x/z resolution/subdivs.  FUN!  I've never done it, but I have always wanted to see someone else try it. 

There is another way.  One material (the height map texture)... CAN handle what?  48 spotlights?  I dunno.  All in all, a spotlight, shined down onto a terrain location... is VERY MUCH "contour-following" and thus... works pretty good as a terrain marker... maybe. 

Meteoritool probably doesn't need markers.  He/she is going to build some skyskrapers!  YAY.  No?  *shrug* 

[meteoritool]

@Wingnut @sable Thx for your answer ?

".setDirection" might be the obvious way I've been missing all along, thx for that.

But maybe facet normal would be even better : I'd like to display footsteps textures where my characters feet hit the ground when he walks in dunes...
I would also like to display a cursor/marker sprite where the user click ton the ground. Both will be Plane Meshes and I need them to fit the ground orientation at precise points.

How to use facet normals ? 

[sable]

Using facet normals: https://www.babylonjs-playground.com/#95PXRY#32

https://doc.babylonjs.com/how_to/how_to_use_facetdata

Though I think @Wingnut is right in that a decal may fit your needs better, especially for footsteps.

[meteoritool]

Ok thanks a lot for your answers !

I will use Decals for footprints, and facetData for the cursor pointer.
Thank you very much for enlightening my day ! The BJS community ROCKS !!!!!

Here's a screenshot BEFORE I add the features, I will post a screen when I have figured out how to best implement everything, KUDOS !

[Sebavan]

It looks really cool !!!! GG.

[Wingnut]

14 hours ago, sable said:

Though I think @Wingnut is right in that a decal may fit your needs better, especially for footsteps.

Oh, I wouldn't trust Wingnut to be right about anything. 

Footsteps, eh?  That... might be a particle system thing.  BJS particle systems have three (or more) easy-adjustable funcs: particleUpdate, particleStartDirection and particleStartPosition.

https://playground.babylonjs.com/debug.html#1PQT7P#14

That is a demo with all 3 custom particle funcs.  Lines 83-85 is where they are "wedged-in".

Line 83 -  ps1.startDirectionFunction = my_startDirectionFunction  -  that is currently broken.  (some backwards compat gone astray, "what's new"?)

But, using .manualEmitCount and custom funcs, you could tell a particle system to ... position one particle and don't move it, after positioned.  When you need another particle, force the .manualEmitCount = 1, and out it comes... using the customStartPosition as the particle "placer".  Every foot step, another particle.

What's cool... is that particles have an age, and can change colors TWICE across that (max) age-range, and then disappear (particle life-time), as wanted.  (blowing sand might cover-over the footstep after 5 minutes, leaving you lost in the dunes). 

You'll still need to deal with rotations and facet normals, I suppose... in the customStartPosition.  CustomStartDirection might be involved, too, but probably not, as your particles won't be flying anywhere.

CustomUpdate is the most important func for power-customizing.  You will remove the "fly the particle" lines, and the possibly disable any rotation spinners, size/color scalers, etc etc.  Your footstep particles won't be flying or spinning during their lifetime.  They will just sit there and look pretty until the blowing sands cover them over, dependent upon current scene wind speeds. 

You never need to stop() a particle system with a .manualEmitCount.  When a manualEmitCount is SET (perhaps to 0 to start out)... and start() the PS... it just sits there, waiting for you to dump fresh particles into the manualEmitCount hopper.  One at a time... is just fine.  Set manualEmitCount = 1 at any time, and poom, particle comes out of emitter (which can be a vector3 worldspace position and need-not be an emitter mesh).

This all applies to the OLDER particle system.  The newest one... I haven't had much time-with.   So far, the new one has some troubles with line 24 of my custom startDirectionFunction.

You might not need that func... for "footstep" particles.  If anyone wants to help me fix line 24, that would be fine with me.

Just another idea for footsteps... and a fine reason to do some power-drinking for breakfast.  heh.  And I agree... nice scene!

[adam]

alignWithNormal might come in handy:

https://doc.babylonjs.com/api/classes/babylon.mesh#alignwithnormal

[meteoritool]

Thanks for your answers !

I could go on building the Playground and here it is now, with even more questions :
https://www.babylonjs-playground.com/#95PXRY#51

# Click somewhere on the ground to animate the Character #
What it does :
  - an animated cursor mesh (disc) at the position of the picked point appears. It's rotation/orientation is deduced from the ground's normal in order to fit to the surface's orientation.
  - a character mesh moves from it's standing position to the picked point. While moving, the character's 'position.Y' is deduced from the ground's altitude thanks to a ray.picking.
  - footprints are created with 2 animationEvents (when each foot hit the ground) when the character walks. Decals are created by ray.picking the ground from the feet position.

I have two questions :
#1 rayPicking the altitude on each frame seems to really hit the performance very badly... Is there a better way -other than physics/collisions- to handle the characters's altitude ?
#2 The most important question ? after several tries, I really have difficulty orienting the footprints decals correctly... How can I make the footprints be aligned with the character's direction ? Also, creating a decal seems to freeze the fps each time.. How to improve that ?

The code is maybe a bit messy, but if someone knows how to do the tricks, this would be super cool as I'm really stuck on this small thing here like pulling my hair lol

 

[meteoritool]

Hey,

I fixed the boi to have correctly oriented footsteps, finally

Updated PlayGround:
https://www.babylonjs-playground.com/#95PXRY#52

As always, the solution was simple, but it took time and many tries and researches ?

#1> When rayPicking, performance is better if the ground has less vertices/subdivisions. Same for decals creation. 
#2> To achieve correct orientation of the footprints, see line 99 in the PG, i leave the decals' normal option blank instead of "pickingInfo.getNormal()"
then, decals' angle = -character.rotation.y 

I hope it will help others too ^^