Decals

[GameMonetize]

Fixed:) (it was already but you did not see what I changed:))

http://www.babylonjs-playground.com/#1BAPRM#6

[Wingnut]

@dk - That one doesn't allow shots to the top and sides of the crate.  (sorry for being a pain in the butt)
 
@josh - I like the idea of a "bend beyond 89 degrees" option.  This idea would need lots of testing.
 
Here's a good test scene with a 3-sided and 5-sided cylinder.  Now we can test with angles <90, >90, and == 90 degrees, and we can test the "all sides" stuff, too.  Currently, the decals in this new demo don't seem to work at all.  Likely, I broke something. 
 
http://www.babylonjs-playground.com/#1BAPRM#8
 
Line 54 - I made pickInfo.pickedMesh be the second arg of CreateDecal.  (worked fine when tried on #6)
 
I'm not sure what I'm doing wrong in this new demo.  Picking seems a bit broken.  Wingy's brain seems a bit broken, too.  Where's that morning coffee?  Can I get coffee here in the forum?

[GameMonetize]

http://www.babylonjs-playground.com/#1BAPRM#10

 

@Wingnut: for you demo, you have to remove the filter function at the end of scene.pick

[Wingnut]

Duh, Wingy.  (Thanks DK!)

 

Ok, here we go... http://www.babylonjs-playground.com/#1BAPRM#12

 

90 degree corners looking good.  Crate decals look good on all 6 sides!

 

When we get the sides of the cylinders to allow a decal, then we can test decals on corner angles that are <90 degrees and >90 degrees (corner angles on the sides of the cylinders).  The tops and bottoms of cylinders are already working fine.

 

I think I am going to make a hippy van, with peace signs and flower stickers ... decal mania!  YAY!

 

Then... we can start selling advertising space on the backgrounds of folks' scenes!  YAY!

 

err... no... BOO! 

[joshcamas]

On your demo wingy, I cannot add a decal to the sides of the cylinders. :C

[Wingnut]

Me either.  Me neither?  Me, as well? 

 

When we get the sides of the cylinders to allow a decal, then we can...

 

Deltakosh has been working real hard on this, so I tried to deliver the side-of-cylinders problem in a gentle manner.  (i.e. Later, when the cylinder side-decals work... etc.)

 

I dunno.  I was trying to imply that there was no hurry for DK to find/fix this issue. 

 

Actually, the decals are there.  Shoot a bunch of times in one WHITE place on the cylinders.  You'll see them start getting black specks.  There's problems:

 

http://www.babylonjs-playground.com/#1BAPRM#14

 

So, WE peasant puppies COULD beat this issue ourselves.  Sure, it will take us 250 man-hours to figure out, and it would take DK about 32 seconds to fix it or tell us why it's happening.    But we could do it.  We could roll up our sleeves and gun this bug out of the air, mid-flight.

 

But maybe, the wiser move is to code-up a bionic Deltakosh Droid.    Something we can store in the closet for when we have bothered the REAL Deltakosh too often about the same feature. 

[GameMonetize]

This is not an issue we can fix:) To keep things performant as I mentioned before direction is evaluated once

[Wingnut]

Yes, you said decal direction is the picked face direction, checked once, or something similar. 

 

So the decals can't straddle corners, no matter the angle.  It's cool.  But we should be able to place decals on the large flat faces of the cylinders, yes?

 

That doesn't work.  Clicks on the flat sides of the cylinders... show that the bounding box for the decal... is messed-up.  (and so is the decal.)  IE and FF.  Did you run my most recent demo?

 

Am I missing something?

[GameMonetize]

That's does not work because of this line:
var decalSize = new BABYLON.Vector3(1, 1, 0.0001);

 

Changing it to:

var decalSize = new BABYLON.Vector3(1, 1, 1);

 

and tha'ts work

 

 

This line is about the size of the cube used to extract the sub mesh part used to display the decal

[Wingnut]

Thank you, thank you, thank you, DK!   A very fine feature, and great ingenuity used in its coding!  You're a friggin' God, dk, that's all there is to it.

 

Ok, let's talk turkey (grind the conversation more).  Let's pretend a user has placed a blank base texture on a plane, and covered it with assorted decals (is that called 'compositing'?).  After that... can we somehow "extract" the entire view-texture of that plane... as a single image?

 

I bet it would be something similar to our Render Scene on a PNG feature.

 

Be advised that I am not asking for the abilities to SAVE it, yet.    I would want to use the image in the same scene it was created-within.

 

Superbrief:  Can we convert layers of composited decals... into a single image... on the fly?  This might be a performance enhancer for a many-decal scene.  And, IF this could be done, then the decal-baked single texture could be used anywhere, including as a shader sampler/refMap.  Coooooool.

 

ANYONE can talk about this, guys.  This conversation is wide open, and the more ideas/comments, the better.  We have completely hijacked fenomas' thread.    (But hey, we're still talking about decals.)

[GameMonetize]

This is possible by rendering only the object and its decals to a rendertexture and then use this texture like any texture

[Wingnut]

Thanks dk!

 

Um, I started a project.  I need to position a flat cylinder... directly over the center circle... of impact.png.  Imagine I need to place a coin atop the center black circle.

 

But... decals have no .position or .rotation.  They have... hmm... "baked" transforms?  Did I use that term correctly? 

 

So, could somebody teach me how to "extract" a v3 position and v3 rotation from a decal mesh?  Can it be done?  (thx). 

 

And dk, if you want to PROVIDE  a v3 .rotation and .position FOR US... before you return the decal... that would be a-ok with me.  (only if possible and wise)

----------

 

Aside: Have you folks seen the decal code?  It's amazing.  Sigh.  Lines 1140-1163 is just...  wow!  DK gathers a nice pile of tools in that section... preparing to take over the world(space).  I wish I knew how to dig in MY toybox... like that.  heh

 

Hey look, there's a section called extractDecalVector3.  hmmm... that sounds like what I need... sort-of.

 

A guy could learn some things... experimenting with CreateDecal.  It's full of delicious transforming goodness.  If a guy could understand that stuff, then a guy would BE somebody, a guy would think.    (droool)

[GameMonetize]

Decals are created to be on top of an object. But they still have a position and rotation because they are basic meshes

[Wingnut]

Thanks Dk.

 

   Could it be that decals get their .rotation and .position... LATE, somehow?

 

http://www.babylonjs-playground.com/#1BAPRM#16

 

The sun in the sky is called 'hole'.  It is master model used to do hole.createInstances.  Each instance is called newHole.  So a newHole goes with each newDecal, and needs to share its position.

 

The objective here is to place a flat godray cylinder exactly over the black center circle of the decal... on every shot.  This is to test a situation where a crate has a bright light inside, and each bullet hole lets a beam of light escape from the crate or cylinder.  (all faked)

 

Shoot once at the crate, and then visit code lines 77-78. 

 

Line 78 seems to fail.  Currently, the godray cylinders that get created each shot... all .position at 0,0,0.  They are SUPPOSED to position at newDecal.position.

 

 

I think line 78 fails because newDecal does not have a .position/.rotation at that time. I have also tried parenting but, I failed.  There are parenting test lines nearby there.  Tests welcomed.    Also, this is my first time using createInstance(), so, there could be incompetence in that area.

 

Simply stated, I am having troubles getting the godray cylinders... positioned to the new decal.  Thoughts, anyone?  Thanks!

[GameMonetize]

the problem is that position of a decal is (0, 0, 0) because the vertices positions already contains the good positions  as they are extracted from a mesh

[GameMonetize]

why not moving your godray to pickInfo.pickedPoint (which is used to position the decal).

 

We can also think about havin decals created at the center of the world and then moved to pickInfo.pickedPoint

[Wingnut]

Yep, great idea, DK. 

 

Darn, I should be able to find solutions that well.  Thanks Deltakosh.

 

http://www.babylonjs-playground.com/#1BAPRM#18

 

Lookin' pretty good.  Now rotation.  I guess the smart thing would be to use a plane with a circle texture as the godray emitter... and then copy the positionKind from newDecal... onto newHole.  Then rotation and position automatically match.  I'm on it. 

 

It looks like that might require clones instead of instances.  I'm still on it.

 

Maybe even smarter... just use another decal, a bit smaller and coated with godray juice. 

 

What if godrays could use selective colors? 

 

Then I would paintbox the center circle of impact.png to be pure white, and then configure the godrays to only activate on white parts of the impact.png texture, and then, you know, no need for hole or newHole.  The center circle would be a godrays emitter, while the rest of the impact image... remains normal.  hmmm.  So much to ponder.

[GameMonetize]

That's huge:)

[Wingnut]

  Nothing is huge here, except my lack of knowledge and talent to create this affect/effect. 

 

Ok, it appears that I must use createInstance, or else I don't get the godrays on the newHoles.  clone() apparently doesn't copy materials.

 

Per DK - pickInfo.pickedPoint worked great for newHole.position, thx again.  But I still have broken rotation (shoot the cylinder, hole rotations are wrong).

 

So, I tried to copy the positionKind from newDecal, to my newHole instances.  But apparently, instances don't have any set/updateVerticesData functions.  They appear to a be a shell of their former selves. 

 

So, I most-recently tried to make newHole be another decal, and that is working great, but... the new HOLE decal is NOT an instance of hole, so it has no godrays texture.  It's decalTexture is a white circle on alpha background.  And, I am having troubles using/cloning the godrays texture from hole... onto each new HOLE decal.

 

Sigh.

 

Is there a secret way to set/updateVerticesData on instances?  That sounds programmatically illegal, eh? 

 

I must keep using .rotation and .position... if I want to keep using instances.  And I HAVE TO use instances for the godrays to copy to each newHole.

 

What the heck is that... pickInfo.getNormal(true)?  Can I derive a correct rotation for my newHole... from that thing?  Anyone know?  (thx)  I tried using it to set newHole.rotation, but that wasn't correct.  If it IS useful data, I need to transform it somehow.... to use it for newHole.rotation.

[GameMonetize]

Hey hey!

 

New version of decals is available with published rotation and position:

https://github.com/BabylonJS/Babylon.js/blob/master/Babylon/Mesh/babylon.mesh.ts#L1631

[MarianG]

Wonderfull feature. Congrats all.

I really need it. And it works great in heightmap too http://www.babylonjs-playground.com/#1XZ7G5

 

Have a nice day!

[Wingnut]

Hi gang!  I have some new decal questions, should anyone like to comment.

 

As we can see by my most recent test, these decals CAN wrap around the corners of Babylon basic shapes... IF the angle is less than 90 degrees.  Click some decals onto the corners/edges of either mesh, and you can see that the decal cannot smoothly wrap around any 90 degree corner.

 

I'm calling it "long-lining" but there might be a more proper name.  The decal is handling the 72 degree angles of the 5-sided cylinder, but the decal is long-lining on all 90 degree angles.  I have played-with line 35 - dmat.zOffset = -.01;  ...but that is not the cause of long-lining.

 

The actual question is... can we (the decals author) determine programmatically... when a decal will long-line?  AND, can the long-lines (side stripes on the orthogs) be avoided/removed?

 

Here's what I am seeking.  I want the decal to look correct, even on 90-degree corners.  This will likely mean using two/three decals, but none of the decals can do long-lines, or it will mess-up the look of a "partner decal."  Is "orthogonal decal" a better term?  *shrug*  Let's call it the aux decal.  The aux decal(s) (the 2nd/3rd decal) would be placed where the long-lines (stripes) are currently drawn.  The objective... to make the decals look correct even when straddling a 90-degree corner.  Can it be done?  Surely not by me... or... maybe.  I sense impending brain pain. 

 

It's a kludge.  Or, a feature.  Or, an OPTION for decals.  And, it's probably miserably-difficult to code.  I suspect our buddy Deltakosh would be the man for the job, and if you have ever seen the decal code... you know this feature request could cause DK some hell.  It might be impossible to do.  But maybe not.

 

Why, you ask?  Well, it all started with my stupid 16-lights-on-a-single-material demo, and went to hell from there.  This demo was the first time I thought about "glow".  Glow is one of the most difficult effects to accomplish in webGL, I hear.  Mop was working on the glow effect... here.  It might not be evident, but compositing is one way to accomplish a glow effect, and I think that's what Mop was trying.

 

Temechon and I played with using a godray (volumetric lighting) for glow, too.  I don't know what Temechon did with his experiments, but godrays will not "light up" mesh that is near the glowing object.  A great glow effect... needs to light-up nearby mesh... and that is the difficult part of creating great glow without a light, I suspect.

 

Many of you have seen my t26 flying 4-poster bed... eventually to become a game called Space Taxi 3D and hopefully coded by someone other than I.    One of the important parts of this game... is what I call "close-in".  The Space Taxi is physics-active... and thus... you want to fly it real gently, especially when you are flying execs into "the mines".  It takes gentle thrustings and careful maneuvering... to fly the taxi in these tight spaces.  AND... the coolest "effect" on the whole friggin' planet... is the clearance lights and marker lights on the taxi... while in these dark caves... glowing off the walls of the cave... and glowing on the surfaces of the taxi itself.  The taxi should be COVERED in these cool marker lights... little ones... often on the corners and along the edges of the taxi body.  Each light needs to create "glow" on 2-6 surfaces. 

 

If a marker light is placed on the corner of a van-like taxi, there's three surfaces on the taxi body ALONE... to make glow!  (and the glow on the cave walls or taxi garage, too).  IF the marker light is active on the corner of the taxi, while the taxi is in the garage... then the glow must light-up up-to three surfaces in the garage, too... side-wall, back-wall, and ceiling, for example.

 

So, decals could/should straddle the CORNER of a box... which means one primary decal and TWO (2), yes, count 'em TWO aux decals.  ERF!

 

Now, back to my 16 streetlight example.  Those streetlight glow textures... (on the roadway) aren't bad.  They could be used as decal textures... but... taxi marker lights happen on the CORNERS of the taxi.  So... the glow of the light... might need to shine on 2-3 surfaces that are 90 degree angles of each other (orthogonal sides).  So, I need the decals to span across 90 degree angles correctly and nicely... if I ever want to use a decal as a marker light glow.  I need... "a sphere of glow".

 

(Yeah, Wingy, its called a volumetric limited-range omni light, and you don't get even ONE of those, speak nothing of a few dozen.)  hehe  (sniff)

 

So, we're at 3 surfaces on the taxi (for corner lights), 3 surfaces for the corner of the taxi garage, and... there is one more thing I would love to light-up with the "sphere of glow"...

 

Dust particles.  If SOME dust particles from the thrusters... floated near the marker lights... they should light-up rather twinkly and sparkly, and ideally, without using a light. 

 

The particles floated into the "glow sphere" of the marker light... and thus we can see them... swirling with each thruster firing. 

 

Can ya picture it?  This is a massive amount of realism to ask webGL to accomplish... but... wouldn't it be nice?

 

How many, you ask?  I'm imagining about 48 marker lights on the taxi... and that doesn't include the auxiliary spot lights and primary headlights and taillights.  As you can tell, this is not a job for classic webGL lights (max 4 lights per any given material).  It is probably a task for fake light glows... like we see in the streetlights demo. 

 

Maybe... I don't need decals.  Maybe I need specialized glow-texture placing.  Or maybe... a new kind of light... a sphereLight... an omni that only lights things that are within it's glow ellipse.      Naturally, glows on the rock walls of the cave/garage/etc... is dependent upon how near the marker light IS to the surface.  *scratch scratch*

 

How about some decals on the inside of a box?  http://www.babylonjs-playground.com/#1BAPRM#24

 

Oh, but are tri-grid-positioned planes REALLY the same as the inside of a box?  hmm.  Different UV's, eh?

 

In #24, you can test using three clicks... to make a 3-decal corner shot that looks pretty good.  One main decal, two aux.  :x

 

Some tests can be done with the decalSize in line 51.  z-fighting tweaks.  *shrug*  I'm not sure what can be learned, there.

 

Here's another test... http://www.babylonjs-playground.com/#1BAPRM#25

 

I was able to use this demo... to experiment with the 3-decal inside-the-garage glow.

 

 

The alpha on the black part of the decal (flare.png) is not being very transparent, but I could be making mistakes with that.  All-in-all, pretty nice, eh?  Too bad all of those decals need to be animated when the taxi is entering or leaving the garage.  erf!   sigh. 

 

The sphereLight would be nicer, and especially if HUNDREDS of them were allowed in the scene. (omg) 

 

Ok, that's all I have (finally).  I thought I would tell of my quest and see if anyone had some great ideas, or feels like working on the decals system... to see if we/they can do 90-degree angles nicer. 

 

Thanks for listening, gang.  Be well, everyone!

[dbawel]

Wow, that's huge.  I've seen this post before, but didn't fully understand the process.  Thanks for adding to this thread, as I'm finally grasping what's going on, and it will help me FINALLY finish my v1 app for multi-user drawing in real time.  Perhaps I'll finally be able to post a working version by Monday.  Without this forum, there's no way I could have written half of what is now built.  Thanks to all you Brainiacs for assisting with the heavy lifting.  And I have to thank many people and specifically Temechon for building the bGUI extension - once again - as it's possibly the most valuable tool I've used to date - with of course BJS.  However, I may need some additional help from Temechon to integrate the additional canvas into a scene with multiple canvas'  for drawing on dynamic textures.  I also haven't yet been able to save the dynamic textur to disk, so any code examples would be extemely helpful.  But I'll create a new post if I haven't yet connected my GUI to the script main.

 

Cheers.

[Dad72]

I also haven't yet been able to save the dynamic textur to disk, so any code examples would be extemely helpful.

 

Hi dbawel,

 

To save a dynamic texture, you can do like this:

Get the texture sending Ajax to PHP:

$.ajax({     url:"PHP/save.php",    type:'post',    data: "dir=" + dir + "&img=" + textureDynamic._canvas.toDataURL()});

With php create the image in png:

function saveImg($img, $finalDir) {    $nameImage = "myImageName";    $img = str_replace('data:image/png;base64,', '', $img);    $img = str_replace(' ', '+', $img);    $data = base64_decode($img);    $file = $finalDir.$nameImage.'.png';    chmod($file, 0777);    $success = file_put_contents($file, $data);     $im = imagecreatefrompng($file);    imagepng($im, $file, 9);    chmod($file, 0644); }saveImg($img, $dirFile);

[dbawel]

Hey dad,

So I don't need to declare the geometry which the dynamic texture is applied? I'm still trying to wrap my head around this one. Thanks, I'll try and add this to a gui panel today.

Cheers.