Jump to content

Reposition decals


Recommended Posts

Okay, so I've been trying to solve this on my own for a while without getting much wiser; I have an island that's higher in the center and I have units that can move around that have a decal arrow in front of them. This decal arrow is supposed to be visible as much as possible, however from a lot of different positions and angles, a lot of the decal is "cut away". It's like it goes under the island it's supposed be above. 

So far I've simply changed the texture angle and decal position every time I move it. The decal is based on `pickInfo    =    scene.pickWithRay` on the cirlce mesh. I still haven't fully grasped what this does, just that it works. 

My question is this; am I missing something somewhere that makes part of my decal get stuck under the mesh or should I recreate the decal every time with new `pickWithRay` that is it positioned, and would that take a lot more resources to do? Remember people saying that decals can be heavy, but I'm not sure which part of the process that is.

I've so far tried increasing/decreasing `decal.position.y` and test `decalSize = new BABYLON.Vector(6, 6, 6)` with different Y values.

Thanks for hints at the right direction!

Link to comment
Share on other sites

Hi Raitch!  Decals, by their nature... work like crap on bumpy surfaces.  You can play with the decal material's .zOffset property (line 21)... like in this playground that uses click-to-decal.

As you can see (after testing), nothing really works well to clean-up the decals (when applied-to super-bumpy surfaces).

Are you ready to hate me?  :)  THE BEST terrain-following decal... is likely a small piece of heightMapped ground that matches Y-heights with the REAL heightMap terrain just below it.  Then put another material on the little moveable piece of heightMap decal... probably with some transparency.

Let's give this thing a name.  Let's call it HMD... height map decal.  Every time the HMD is moved, it needs to have all the vertexData.positions.y (heights)... copied from the terrain beneath it... into the Y-heights of the HMD (contour matching, vertex-for-vertex).  It is exactly like a copy of a tiny section of the real terrain... but raised a small amount (so it lays atop the real terrain).

I think this HMD (height map decal) will be used SO OFTEN, that it should become a main-line BabylonJS feature.  It will be a sister-feature to the non-heightMap decal... and likely much easier to code.  The other (current) decal system is quite complex, and again, is not really designed for bumpy surfaces.

Dragging this new HMD... will be easier, too... and will maintain terrain-following contours the whole time... IF done correctly, and IF the HMD is not overly-high resolution. The lower the resolution of the dragged/moved height map decal (HMD)... the smoother the moving/dragging of it.  Less heightMap elevation (Y) data needs to be copied from real terrain to the HM decal... per movement step.

With me?  God, I hope so.  Perhaps we can convince one of the forum's "I love pain" programmers... to code it for us.  Perhaps YOU are well-qualified to build such a thing, too.  I'm not so, but I could probably pull it off... in about a week.  :)  I think there are other coders that could make it happen in about an hour.

Thoughts?  Anyone?  If I remember right, @jerome invented a... getTerrainHeightHere(X/Z point) function, which I can't find anymore, mainly because I can't remember its name.  :)  That could be the beginning of a... cloneHeightMapSection(startingPoint, width, depth) function.  If you had THAT, you'd be fartin' thru silk (in good shape), right?  Sure, it will be a square area, but just like the standard decal, it can be made round, or be an arrow, as wanted, by using an alpha-enabled decal texture.

Wow, huh?  Like you REALLY wanted to hear THIS bad news, eh?  :)   Sorry.  But, if you want a GREAT terrain-following decal... I  think that might be the best way.  Comments?  Code?  Anyone?  thx!

-------- Addenda --------

I want to show you one more playground... http://www.babylonjs-playground.com/#UCORW  It is from @fenomas, and... it is "techie".  I don't understand what is happening in there, but I DID replace the grassy plane with a heightMap ground mesh (during an un-saved test).  After I did that, the white circle turned into a white "bar" all the way across the terrain width.  (like the white circle was z-stretched extremely).  But, just the same, I thought you should see this playground and possibly test it for heightMap smoothness. 

That playground was introduced in the post AFTER this one. But notice what Deltakosh is saying, there.  Is he saying... that a reflection texture could be moved-around on a heightMap, perhaps with reflectionTexture.uOffset and .vOffset... and perhaps... that could be a reflection of an arrow?  Reflections are automatically terrain-hugging, right?  hmm.  Double hmmmm!  Boost the .level on the arrow reflectionTexture, and we should easily be able to see it... super-imposed (composited) atop the terrain texture.  TRIPLE hmmmmmm!  :)

Bye again.  :)

Link to comment
Share on other sites

7 hours ago, Wingnut said:

I want to show you one more playground... http://www.babylonjs-playground.com/#UCORW  It is from @fenomas, and... it is "techie".  I don't understand what is happening in there

Fair warning, I don't think anyone understands what's going on there (unless perhaps deltakosh). It uses some undocumented feature that DK suggested could be used to implement decals (but as far as I can tell it can't).

Link to comment
Share on other sites

:)  That's worth a test... watch your FPS... or profile the project in browser dev-tools... for best performance watching.


That's a first-test version of an arrow on a heightMap... using material.reflectionTexture.  The blue arrow is huge, and I haven't learned how to shrink it, yet.  Perhaps line 41's projection_mode won't allow it.  Still testing.  But you must admit, THAT decal isn't sliding under the landscape and becoming partially obstructed.  :)

The first method I FIRST mentioned... where a little piece of ground with the arrow texture on it... is moved around just above the normal ground (and matches height with the normal ground)... I haven't tested that, yet, or ever.  I'm a bit overloaded at the moment.  But I think the piece-of-ground decal system... would LOOK the coolest of all... especially close-up.

But, I'd like to first see if I can shrink this reflectionTexture somehow, and then... you can move it around with material.reflectionTexture.uOffset (and vOffset), and rotate it with .wAng.  It will be easy and fast to move... using the reflectionTexture, maybe.

I had another thought.  What if... we used emissiveTexture instead.  http://www.babylonjs-playground.com/#11JINV#2

Looks pretty cool.  Good ground hugging, but, there's some artifacts, possibly caused by lines 47-48 CLAMP_ADDRESSMODE.  Change to WRAP_ADDRESSMODE for an interesting and useless adjustment.  I DO like the way the arrow(s) is following terrain contours.  Looks clean.  But, still not perfect.  They can be "brightened" a bit... with something like groundMaterial.emissiveTexture.level = 3; .  Those offset and scale settings... look totally retarded to me, but I am no expert in texturing.  :)

Raitch, what do you think about the "look" of these arrows?  Are they good enough quality... to replace your decal method?  I'm not saying you SHOULD do that, but... just wondering what ya think of this method.  Talk soon, party on.

Link to comment
Share on other sites

Ahhh, sorry... I somehow got the impression that a heightMap was involved.

Here's a modification of a @RaananW-made demo... where the arrow texture is placed on a plane, and as it is moved-around on the sphere (with mouse pointer), it rotates to match the "normals" of the sphere.  http://www.babylonjs-playground.com/#2C8LVE#13

SOME jaggy artifacts seen... when mousing near the left edge of the sphere.  *shrug*.

Just thinkin'.  This same method COULD be used to rotate your decal to match sphere contours, I suppose.  Fancy coding... pretty much over my head.  :)

Link to comment
Share on other sites

Yep.  Well, its NAMED "box" but it's really a plane... because I was too lazy to adjust the name... when I changed it from box to plane.  :)

I wish some more forum folks would get involved, because, we have some excellent thinkers and idea-people nearby.  But... not many are participating at the moment.  Don't count on my ideas to be good ones... because... I haven't learned the "pro tricks", yet.  Notice that I'm simply finding/borrowing playgrounds from smart people, and showing them to you.  If you can afford a bit more time, better ideas are likely to come.  (maybe)  :)

Link to comment
Share on other sites

I really don't get how to make this work. I tried using pivotMatrix on decal to center the decal arrow, but that didn't seem to do much of the trick either. I really feels like I don't grasp something important regarding the decals to make it work. Just changing x/y/z positions doesn't seem to cut it. 

What makes a decal get stuck on a surface? I don't understand that logic since sometimes it looks like it's on the surface and sometimes soaring in the air.

Link to comment
Share on other sites

Hi guys.  Raitch, do you REALLY want to know why decals act the way they do?  https://github.com/BabylonJS/Babylon.js/blob/master/src/Mesh/babylon.meshBuilder.ts#L911

Take a moment to look at that thing... and its "inspired by three js" clipping engine.  Possibly grab the JS version of that code, and install it into a playground or home scene.  Then load it up with console.log() reports and watch it work.  It's amazing.  I'm pretty sure the whole feature was coded by a robot. :)

Decals are magical and "different".  They won't act like you expect, yet they'll work wonderfully in certain situations.  To understand WHY the decal behaves like it does, you'll need to understand what is happening... in that source code.  AND... IF you learn the decal's source code, and become "hot" with it, then you can write a custom decal system (modify the BJS version).  But more likely, you'll abandon the idea of using a decal... for your needs, this time, this project.

I can try another analogy, here.  Picture yourself inside a box... looking into one of its corners.  You want to place a decal in that corner, so its texture will cross-onto all three walls, equally.  Perfectly centered on the corner of the box... so 3 surfaces to deal-with.  But the decal constructor "samples the angle" of only one surface (to set its decal orientation angles).  It can't take all three surfaces into consideration.  So, the decal looks fine on ONE of the three flat surfaces of the box corner, but looks like crap as it crosses onto the other two flat surfaces.

Oh, I have a PG demo that shows this.  http://www.babylonjs-playground.com/#1BAPRM#25

Click-around in the corner of the box... to paste some decals.  Notice that it takes 3 clicks (3 decals) to create a decent corner-centered decal-look.  A single decal could not do a "flare in the corner".  It takes three.  The "sampled surface" (extracted portion) used to "grow" the decal's orientation... is very position-oriented, yes?  The angle of the decal... depends upon where we click.  The angle/orientation of all decals... is dependent upon what surface it is constructed-for.  So, after-construction angle-adjusting... is not going to help.  The decal was angled to match a surface... when it was constructed.  (what Deltakosh said)  :)

Hmm, I wonder what would happen if I mesh-merged the three walls.  I should try that someday.  :)

Have you thought about "projecting" your arrows onto a surface... lighting-wise?  hmm.  :)  Seems like there should be an easier way to get your task done.  But don't let us stand in the way... if you have a Raitch vs. Decals war declared.  If you are bound and determined to battle with decals until your head explodes, then who am I to get in your way.  :)

Link to comment
Share on other sites

  • 2 weeks later...

Hi Raitch.  Perhaps boxMaterial.diffuseTexture.wAng ?   Ever hear the story-of how u v w came to be?  Somebody needed x y z for textures, and simply used the 3 alphabet letters that come before x y z.  Goofy, huh?  :)  So, wAng is rotation around z.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...