Gugis

Dynamic heightmap

Recommended Posts

I'm looking for way to update ground created with BABYLON.Mesh.CreateGroundFromHeightMap using dynamic heightmap texture. Do I have to dispose mesh everytime when texture is updated and then create a new one with updated texture? Or is there method to update heights just by assigning new heightmap texture?

Share this post


Link to post
Share on other sites

Hi Gugis!  Umm, both methods are available.  Dispose and recreate is probably the easiest... but... are you thinking about never-ending dynamically-generated heightMap?  Player can walk forever in any direction, and never come to the end of the world?  That is possible, too.  Thoughts?

Wanna go for a quick source-code walk with me?  I knew ya did.  First, let's start here... https://github.com/BabylonJS/Babylon.js/blob/master/src/Mesh/babylon.mesh.js#L2083

We are on the MESH class... and this little function does... little.  It packages-up some of the parameters in the CGFHM (createGroundFromHeightMap) call... and then farms-out the task to MeshBuilder CGFHM in line 2093.  Doesn't anyone do their own work anymore?  :)

Ok, let's follow it.  Off we go... to meshBuilder... https://github.com/BabylonJS/Babylon.js/blob/master/src/Mesh/babylon.meshBuilder.js#L609

Lines 610-626 are essentially... breaking-open the options object and other parameters that arrived... no big deal.  Lines 627-651 are one big function... that runs after the image loads... so skip across that... to line 652.  There it is, the image loader... with a callback to the onload function that we just skipped-over.

Let's say we got a good image load... so up to line 627 we go, carrying a parameter called img.  Line 629, make an html canvas, line 630, get a ref to its context2d (a very interesting DOM object, full of SVG-like graphics-drawing power)... and then line 635... BOOM... draw the image on the canvas. 

Let's pee on a tree, right here, at this point of our walk.  We will be revisiting this location.

Line 638... GET the image... from the canvas... and put it into a "buffer".  We just got done PUTTING it onto the canvas... now we need to get it back?  Well that's just goofy, but that's how it needs to be done.  DrawImage, getImage.  A very important place along our trail.  Let's pee some more... to make sure this place is well marked.  heh

Line 639... Oh my God... we are farming-out the task to yet ANOTHER object... called a VertexData... and were calling ITS createGroundFromHeightMap() func.  Doesn't anyone do their own work anymore?  :)  This is the THIRD object that has a function named that.  Goofy, eh?  Layers. 

Ok, let's follow it.  Off we go... to vertexData... https://github.com/BabylonJS/Babylon.js/blob/master/src/Mesh/babylon.mesh.vertexData.js#L1087

We arrive... carrying our "options" parameter... which now has a buffer contained within.  Now we are going to get some work done.  In lines 1087 - 1132 (the whole func)... this vertexData stuffs its pockets (arrays) with "stuff"... vertices/positions, lighting normals, vertex-connecting indices, texture-mapping UVs.  Once it has its pockets filled enough... its says... ok, return ME (line 1131) to whomever called this func (meshBuilder).  Let's head back to Port-Of-Call... meshBuilder... line 639... https://github.com/BabylonJS/Babylon.js/blob/master/src/Mesh/babylon.meshBuilder.js#L639

Phew, we're back.  Did ya survive the trip?  I hope so.  Line 645... apply the vertexData object... to the mesh named "ground".  Set the ground "ready"... and PARTY!!!!

What a fun walk, eh?  Remember back where we pee'd on the tree?  That was where we used an img to drawImage and then the very next line, we use getImage to fill a buffer.

You, my friend... could "intervene" near pee-tree, right?  You could steal some code in that area.... and move it to your project.  You could make your own img by using the drawing tools on the canvas's context2D object.  Or, you could fill your own buffer with math-generated numbers, and then put that buffer into the options packet... and send it over to vertexData's CGFHM ... for further processing.  You could get demented!

So, yes, if you want to keep it simple, it might be best to dispose and recreate.  If you want to get demented and get some fun brain tumors... hang out at Pee Tree Junction.  Steal some code from that area... and put it directly into your project. :)  Buffer-Whackin!  BuffMeisters Inc.  Wanna do fractals?  Spew into buffer.  AND... there is a BabylonJS materials feature called dynamicTextures... and guess what?  They use the very same context2d, drawImage, getImage, and buffer (or real close). 

"BuffMeisters!  We paint with math!"   Yay!

Hope you enjoyed the walk.  You should know some more things, now.  Points of intervention. :)   And perhaps, we SHOULD have a ground.updateFromNewUrl("someUrl").  Perhaps you should code that up in TypeScript, Gugis, and contribute it to BJS.  Coooool.  Party on!

Share this post


Link to post
Share on other sites

In your very specific example, I wouldn't have used a ground created from a heightmap, but just a simple ground mesh instead. Indeed, you don't need the pixel buffer but just the 2D coordinates on the ground where to rise it.

Just create your mesh ground as updatable then just update its positions coordinates (vertex coordinates) at the 2D coordinates x, z

Please have a look at this : https://github.com/jbousquie/ArtilleryDuel/blob/master/level.js#L238

This defines a position function changeAltitude() what reduces the ground altitude at the given x,z coordinates and then updates the mesh. You could do the same but increase the altitude instead.

Share this post


Link to post
Share on other sites

Mizewell link the in-dev demo itself, too.   http://jerome.bousquie.fr/BJS/dev/artillery/artillery.html

"Buggling"... what a funny word.  :)  So, then, a bubble... in a bicycle tire... is also called a "buggle"?  Similar to a "bulge"?  A conglomeration of "bulge" and "bubble"?  Perhaps "booger" mixed with "bubble"?  Booger-bubble?  eww.  You Frenchies sure speak oddly.  ;)

For those outside-the-loop, Jerome once made this simple cannon, and I asked if he could make the cannon "pucker-up" before firing, like a cartoon cannon might do.  He did a fine cannon "pucker", but he called it "buggling".  I laughed, and then I started asking the local townsfolk if they have ever done any "buggling".

"What the hell is buggling?", was the unanimous response. I think Jerome made-up that word.  heh

BUT... the world has these things... inflatable lifting bags.     They have a terrible name.  "Inflatable lifting bags" takes WAY TOO LONG to speak.

So, I hereby officially propose... that these inflatable lifting bags... now be known as "buggles".  They are named for Jérôme "Buggles" Bousquié... the man who invented the word "buggle".  Interestingly, he had NO INVOLVEMENT with inventing or improving air-lift "buggle bags".  :D 

Jerome DID once catch a bugglefish, though, I hear.

All your demos rock, Jerome.  Sigh, drool.  Thanks for making them.

Share this post


Link to post
Share on other sites

So... Gugis... are you going to feed a webcam microphone into the elevation map, so we can spectrum-analyze squirrel farts, and then we drive a little car around on the 3D heightMap fart-graph?  Huh?  C'mon!  :)

Swapping-out heightMap Y-data... FAST... seems... important.  I wonder if worker threads could help.  Possibly SIMD, too.  *shrug*  (speculating).  I would expect that the future DOES hold possibilities for users.... wanting to "wire" cameras, microphones, 3Dscans, and mocap data... onto heightMaps and point clouds.  I feel the need... for speed.  :)

Ok bye again.

Share this post


Link to post
Share on other sites
4 hours ago, Wingnut said:

So... Gugis... are you going to feed a webcam microphone into the elevation map, so we can spectrum-analyze squirrel farts, and then we drive a little car around on the 3D heightMap fart-graph?  Huh?  C'mon!  :)

Swapping-out heightMap Y-data... FAST... seems... important.  I wonder if worker threads could help.  Possibly SIMD, too.  *shrug*  (speculating).  I would expect that the future DOES hold possibilities for users.... wanting to "wire" cameras, microphones, 3Dscans, and mocap data... onto heightMaps and point clouds.  I feel the need... for speed.  :)

Ok bye again.

Huh? :blink:

Share this post


Link to post
Share on other sites

Ya I did this once as well: (You have to create a project, a map, and a terrain in the editor first tho)
http://samacstudios.com/projects/SamacEditor/index.html

Basically, there is no need to create a fancy heightmap. Instead, you can create a ground map, and edit the vertex data itself. This is not only blindingly fast, it's also somewhat easy!
And if need be, you can generate that ground map from a heightmap image, and then still edit the vertex data! :D

Share this post


Link to post
Share on other sites

Hiya TL, welcome to the forum!  What did I do... to whom?  :)

If there's an unwanted pregnancy involved, IT WASN'T ME!  heh

Actually, I'm not sure WHY they are vector4-like values.... but I'm still drunk from eating so much Wild Turkey, yesterday.  :)

I'm glad I was almost right, though.  That's close enough to call-for PARTY!!!

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.