applyDisplacementMap

[unicomp21]

Given I'm using mesh quads w/ texture tiles, what can I expect when using applyDisplacementMap?  The sphere demo looks like it has higher poly count after applying the displacement map.  What's going on here?  How are the rgba values in the displacement map used for the displacement?  In the demo both the texture and displacement maps use the amiga.jpg, which is confusing.

 

[Wingnut]

Hi U21... good to see you again.  Take a look at http://www.babylonjs-playground.com/#P9UZG#9

It's just another displaceMap demo... but because of wireframe overlay, you can see that there is no increase in poly count.

Also, your tiles of quads won't displace properly with applyDisplacementMap.  You'll need another method but it won't be very difficult.

Inside the above playground, I "hijacked" the applyDisplacementMap function and its friend applyDisplacementMapFromBuffer from the BabylonJS source code.  It's easy to see how it all works, now, right?    Lines 34-45 was an area I needed to "hack" to try to get my image to fit my sphere, better.  It's a long story. 

You'll see in line 54 ... that is a sphere.  Lines 65 - 81 do the actual heightMap adjustings to sphere.positions.

To make applyDisplacementMapFromBuffer work with a grid-o-quads... you will need to re-code it.  In a grid-of-quads, for each displacement position... you will need to displace 1, 2, 3, or 4 positions, on 1, 2, 3, or 4 quad mesh.  (For example, where 4 quads come together, 4 mesh need a point raised.)  This is different from the current system... which displaces one position on one mesh (ground is a single mesh).  Your ground is MANY mesh, right?  You can still make your grid-o-quads "act" exactly like a heightMap/displaceMap, you just need to tell it to do so... by re-coding applyDisplacementMapFromBuffer (making a custom applyDisplacementMapFromBuffer() function).

Yes, maybe using amiga.jpg on both texture and displace is a little confusing, but it sure looks cool, eh? 

If you make a playground (even using a spinoff of mine) with a 64x64 grid of quads (a ground of quad tiles)... and include applyDisplacementMap and applyDisplacementMapFromBuffer (like I did)... then maybe somebody will help re-code applyDisplacementMapFromBuffer() so it works on your grid-of-quads.  Or maybe ya got it all handled.

Holler if you have more questions.  I hope I'm not telling you wrong things.    Someone please correct me, as needed.

[Wingnut]

http://www.babylonjs-playground.com/#1VGWP9#1 

I started a little work with a BabylonJS tiledGround.  I don't think anyone has ever tried to apply a heightMap/displaceMap on a tiled ground.  This should be some fun experimenting... and I will learn things... I know it. 

I started with Célian Garcia's Tiled Ground Tutorial and added a wireframe layer (multimat2/material2)... and I am using colors on the tiles, and not textures.  (Good enough for testing position displacements).

My line 67 alert... says there are 24 "indices" per tile.  Hmm.  That's more than I thought there would be, but I'm a newbie in the land of plotting. 

There appears to be 4 "quads" per "tile", so I need to be careful with my terminology.  I am no longer sure what a "quad" means.  I always thought "quads" had 4 vertices, and that's all.  SO, I have much to learn.  I have not worked with tiles at all, and I have never tried to displace their vertices.  But there are vertex Gods around the forum, and maybe we can beg some hints and code out of them.  (thx, everyone)

[jerome]

 

• name : the name of the mesh
• xmin, zmin, xmax, zmax : extent values 
• subdivisions : number of tiles (subdivisions.w : in width; subdivisions.h : in height)
• precision : number of subdivisions in each tile (precision.w : in width; precision.h : in height)
• scene : the scene which will contain the mesh
• updatable : if the mesh is updatable or not

AFAIUnderstand,

For convinience, let's assume that we subdivide the same way on the width and on the height, so w and h are equals.

You divide the width per subdivisons.w subdivisions. These are the tiles.

Then you subdivide each tile per precision.w subdivisions, these should be the quads. And a quad is still two triangular facets, so 4 vertices.

I wish I'm not wrong, that's how I understood the stuff.

[Wingnut]

Thanks Jerome!  And, hi readers!  Umm...  I decided to TRY to advance this topic a bit.  The quest:  Coding createTiledGroundFromHeightMap() or... adding power to mesh.applyDisplacementMapFromBuffer().  Here is a starter PG:  http://www.babylonjs-playground.com/#1VGWP9#4

See my hacked tiledGround.applyDisplacementMap() func at line 87?  Well, that is NOT BJS default code.  I hacked it, so I could do image flips and rotates and scales... to adjust my image buffer.  That is all irrelevant, because the real issue is a helper function called applyDisplacementMapFromBuffer() - at line 121.  What you see there IS default framework code (almost)... and it is working... but only "per tile".  You see the BabylonJS logo on each tile.

What I want to do... is make a smarter or different applyDisplacementMapFromBuffer() that will spread the displacement map across ALL the tiles... AS IF the tiled ground was a single ground.  (make it look like a standard non-submesh heightMap/displaceMap).

I assume "we" would want to divide-up the buffer into sub-sections... to match the (variable) layout of the tiles.  Then use a big fat double-nested FOR-loop, and we are on our way.  Maybe.

But I don't have the math skills for this, and others LOVE doing these kinds of challenges.  I... hate them.   

So, I could use some help.  If ANYONE would like to write a "branch" for applyDisplacementMapFromBuffer() that handles tiledGrounds properly, or wants to write a custom applyTiledDisplacementMapFromBuffer()... THANK YOU!  Maybe we will put it into the core framework... possibly adding it to the tiledGround class.

Is this the correct approach, though?  WHAT IF... we (temporarily) merge the subMesh into a single mesh, then apply a STANDARD applyDisplacementMapFromBuffer() action, and then de-merge the subMesh?  Is that a wiser way to go?  Possible?  Thoughts?  Hints?  Wisdom?  Ideas?  HELP?    (thx!)

PS: If you get a demented idea like trying our edgesRenderer on this, it will fail to find the heightMap edges, and your browser will slap you for trying something too crazy (long script warning). 

[jerome]

Hi

To summarize (DK's way ), you wish you can morph a tiled ground from buffer data, like some CreateGroundFromHeightMap or applyDisplacement ?
I think it's possible.

Actually, as the tiled ground was designed, afaik, to set different textures per tile, and not a single big one as for the classic ground, I'm wondering about the goal to morph a whole tiled map according to some buffer data. Can't we just change its positions only from known numeric data (geo data, etc) ?

[Wingnut]

The goal?  Yeah, I was wondering about that, too.  Let's ponder using our playground heightMap...

http://playground.babylonjs.com/#1BAOJ4#1

Each tile (16x16 tiles used above) would have it's own sub-section of the whole heightMap image.  Each tile object/submesh could/would carry its own subHeightMap (or carry the code to derive it).  Game writers could tell these tiles to render or not... depending upon where the character/camera is located-at.  Tile wrangling.

I THINK this is what Unicomp21 is talking about.  I think folks want to "serve" these heightMap sections (tiles) and have each tile "carry", or quickly compute... what index of the landscape map they are positioned-at and apply the right sub-section of elevation data... to seamlessly attach to the already-rendered land.  (Man, what an ugly sentence!)

Smart tiles.  These tiles can carry or compute both their diffuseTexture subSection, and their heightMap subSection.  They know how to paint themselves and grow their elevation... because they "know their place".  Does this make any sense?

I could be an idiot, too.    I have rarely used servers, and have certainly never done tile-serving, but if I was to try to build Babylon Bay virtual reality "area" for all forum users... and allow "walking" from one person's scene... to another,  then I would use a tile server system. 

Jerome gets a 10x10 tile area along Babylon Road.  Wingy lives next door to his hero, on HIS 10x10 tile area, then Dad72's CastorFarm is next to me, then Temechon Trail turns off, and he and Unicomp21 have ranches down that road, etc.    (DeltaKosh lives off-world, in a spacecraft, of course.)

Just thinkin'.  I'm not sure what Unicomp had in mind, but it seems we're talking "seams", here. 

Unicomp:  "Given I'm using mesh quads w/ texture tiles, what can I expect when using applyDisplacementMap?"

I think smartTiles would be the way to go.  They know (carry or can compute) what subsection of diffuseTexture they need, they know (carry or can compute) what subsection of heightMapTexture they need, and they know (or can derive) where they are supposed to place themselves. 

Self-contained, self-actualizing tiles, can ya dig it?  Unicomp's world server would serve tileObjects...  smart ones, to a "live" scene.  *shrug* 

I guess the tileObjects could be "dumb", too... needing to be parsed by a tileParser before installing/rendering.  *shrug*

Maybe all that image-dividing is done on the server-side, though.  What I speak-of... is having cllent-side code do tile-serving to the scene graph, dependent upon camera/player location.  Ideally, it doesn't matter WHAT serves the tileClass object... the object format would be identical.

Do I make any sense?  If so, that's rare.   Sorry for being so newbie, here.  I know there are MANY folks who have thought long and hard about world-serving... and I'm sure they are completely bored right now.

 

[Wingnut]

Ok, here's my latest (like anyone is following along) 

http://www.babylonjs-playground.com/#1VGWP9#7

Grab the zip, take it home, join me in staring at it. 

Primary Objective: Spread single worldmap across all (4) tiles.  Then test with 8 tiles, 16, change precision values, test again... celebrate! 

I hijacked the BJS CreateTiledGround() func (line 3), so I/we could see how tiledGrounds are made (especially their .subMeshes array).  Also, this would be the starter func for a crazy attempt-at CreateTiledGroundFromHeightMap()    Wow!

I also hijacked CreateGroundFromHeightMap() - line 84 - having this handy also helps if someone tries CreateTiledGroundFromHeightMap().

tiledGround.applyDisplacementMap is at line 224, pretty much stock, and likely needing no changes.

The old applyDisplacementMapFromBuffer() is disabled (line 319), and replaced with the new, un-coded applyTiledDisplacementMapFromBuffer() at line 262.  It needs coding.  I added two parameters...  subdivisions and precision.  Those values will be needed in the new un-coded func.

So, this is THE ultimate starter scene for hacking this challenge.  Zip it up!  Take it home!  Camp it like a Winnebago!  (beg beg beg)  The re-code probably starts with ANOTHER  outer FOR-loop... like...  for (subMesh in that.subMeshes) { apply a certain portion of the displaceMap buffer }  *sigh*

I'm scared.    I'm still staring at this challenge, and adding white-space, and procrastinating.  I'm thinking that the code will write itself if I stare at it long enough.

This first buffer-dividing challenge is WAY BEFORE any thoughts of extending BABYLON.SubMesh  (see line 213) into being a "smartTile".  SmartTiles are for later, and might not be for-framework objects.  (might be user-coded for certain projects only) 

But still, the idea of a tile... knowing how to compute its PROPER section of the heightMap, and its proper section of the ALL the textures placed on its material...  that seems cool, and powerful.  hmm.  I think I'm going insane.    Ideally, I think it would be good if a tile (a tiledGround.subMeshes item)... carried the following info:

- where it belongs in the tiledGround grid.
- its START location in the displaceMap/heightMap image buffer (probably not possible - non-linear).
- its STOP location in the displaceMap/heightMap image buffer (probably not possible - non-linear).
- its START/STOP location in any material textures applied to the whole tiledGround (probably not possible - non-linear).
  (That last item might need to consider texture wraps, angles, offsets, scales!  Oh no!)
  (I need to study subMaterials better)

Lots of "not possible", eh?  Start and stop locations within a texture... I don't think so.  Offsets problems.  *sigh*  That's why having the smartTiles be able to "gather" their own subMaterial (and subHeightMap) at "install into tiledGround"-time... might be the ONLY way to do that. 

So, maybe "smartTiles" IS the way to go... intelligent subClass of BABYLON.SubMesh... maybe.  I dunno.

sigh.  Help?  Fix my thinking?  (thx)