Stretched decals

[kurhlaa]

Hi,

If I create a decal near the edges I get last pixels stretched on other sides. Looks like a barcode. Playground: https://playground.babylonjs.com/#2PBY8W . Is it fixable?

[Gijs]

You could paste the decals at an angle, but that causes them to stretch a different way:

https://playground.babylonjs.com/#2PBY8W#1

If you only want that cube in the playground, maybe you can make a cube from 6 planes, and apply a decal to them individually

[kurhlaa]

7 minutes ago, Gijs said:

If you only want that cube in the playground, maybe you can make a cube from 6 planes, and apply a decal to them individually

What about a full real world?

[Gijs]

45 minutes ago, kurhlaa said:

What about a full real world?

I don't know

[kurhlaa]

Anybody?

[Wingnut]

Kurhlaa, did you do a forum search for info about decals?

It was less than 25 days ago when I responded to a topic "Decal stretching" posted by AngryBot.

And once for you...  not long ago...

http://www.html5gamedevs.com/topic/34713-placing-a-non-repeatable-secondary-texture/?do=findComment&comment=199437

" Decals along sharp edges/corners... has always been a rough area of town. "

Your decals (in the PG above) are acting normal.

var decalSize = new BABYLON.Vector3(2, 2, 2);   Did you try setting that z value to a very low number?

https://playground.babylonjs.com/#2PBY8W#2

In above PG... I turned-on showBoundingBox.  It helps for learning about HOW decals work, and what their limitations are.

Didn't we once talk about putting a picture/window frame or similar.... AROUND the edges of your planes/boxes... to hide decal "wrap-arounds" and/or image-plane "hang-over-the-edge" problems?  Maybe not applicable for your project.

Have you tried context2d image/canvas manipulation, using dynamicTextures?   https://www.w3.org/TR/2dcontext/#drawing-images-to-the-canvas

With good dynamicTexture and context2d operations, you can put an image or piece of an image... anywhere atop another image (which could start-as a completely transparent image, if wanted.)  With DT's, you could APPEAR TO wrap parts of a decal-like image... around 90+ degree corners.  Likely, you would need a different/discrete dynamicTexture on each side of the box/mesh, though.

It is easy to "believe" that decals are simple little "stickers".  Actually, coding-wise, they are quite complicated and serve a certain special purpose/use.  Successfully spanning angles nearing 90 degrees... are not part of that special purpose/use. 

Have you read the forum thread where decals were first introduced and talked about?  You will see that is was I, "Wingnut the Annoying"... who first asked (I actually whined pathetically) about decals going around corners.  heh

I now pass the "Custodian Of The Decals" torch on to you, Kurhlee McWhurlee.  Next time someone on-forum asks...

"WHY do decals look so goofy when wrapping-around tight corners?"

...then you can show them the source code for decals and say "Look how friggin' complicated they are, and need to be. 

Move to dynamicTextures to get more powers/features."  (the job of decal custodians)     And then, pass the "Custodian Of The Decals" -torch... on to them.  Then quickly wash your hands.

What's that?  You haven't yet found Wingnut's  "Great Decals Yap-A-Thon and Learn-A-Thon"?  It's here... http://www.html5gamedevs.com/topic/12974-decals/

It seems like it took FOREVER (4 pages of forum thread) before Wingnut FINALLY understood what a decal IS and DOES.  Decal custodians must KNOW what decals are, and what they are not, so they can pass-on that brain tumor to future torch-bearers.    I hope this helps.  When you decide to use dynamicTextures/context2d buffers-o-pixels, and leave-behind decals, we are here to help, as needed.  I think you'll be happier in dynamicTexture land.  No more bad wrap-arounds or images/planes hanging-off the edges, into space.

You'll even have the power to TRI-WRAP!   That's when you place a decal-like image at a box corner where THREE SIDES intersect.   It will wrap perfectly (after you survive another brain tumor... caused by compositing portions of the decal-like image... positioned at three different canvas positions... onto three separate dynamicTextures).    Pain is fun!

[kurhlaa]

On 1/19/2018 at 9:08 AM, Wingnut said:

Did you try setting that z value to a very low number?

Hi Wingnut,

True, why did I put "2" everywhere?! Maybe taken from some example. This really is a solution.

 

In general, why do I avoid complex solutions - performance is a priority Nr.1 for me. So I want my project to be as lightweight as possible. I've seen some browser 3D games or examples, which are totally unplayable. Ok, there are things like the best shadows, lights, special effects, character and world animations like moving tree's leaves, and so on - but as a result - the game is SOOOO SLOOOW and laggy. FPS 20-30 feels very very low.

I don't want to use some solution just because it works, somehow, things must happen fast. Then the game can be enjoyable.

 

I hope you understand me thoughts

[Wingnut]

Thanks.  Yeah, now I understand your goal... a bit better.  Although better perf than decals, both sprites and image-planes have the hang-over-the-edge problem, right?

hmm.  Let's pretend you had a sprite or image-plane generator func.  Every time a shot was fired, you call this function to generate the "impact" graphics/noise.

The first thing the function does... is use the pickinfo.pickedPoint... to determine how close to the edge of the mesh... that the shot hit.  If it is less than 1/2 sprite-width from any mesh edge, the function makes a SMALLER imagePlane or sprite... with its texture perhaps uOffset and vOffset properly.  It makes a sprite or imagePlane that will not hang-over the edge.

The function would be "smart" and know when half-width sprites or quarter-height sprites are needed... because the function KNOWS how close-to a mesh-edge... the impact happened.  It can create an impact image on-the-fly, and made specifically (specially) for the situation.

Still a bit complex, but not necessarily slow.  *shrug* 

I'm trying to think-up some more ideas.  I don't know if you are actually working-on shot-impacts, or just using shot-impact decals/images as an example for something else you have planned.

In some games, shot impacts "heal" after some time passage.  This can also help with performance.  Will yours be doing healing?  (If ya don't mind me asking).

Do you plan on doing any particleSystem "puffs" (manualEmitcount) when/where impacts happen?  Could a little particle "explosion" at impact point... be enough? (without placing a more-permanent image/black-mark/hole at the point of impact). 

BJS particleSystems are surprisingly efficient and hi-perf... and can get a lot of action happening in-scene, for a decent overhead cost.  Just one particleSystem can...  place emitter at vec3 position, set a manualEmitCount to 100, particleSystem pukes a 100 particle puff, quickly move the vec3 emitter, set .manualEmitCount again, PUFF, over and over, and do it FAST.

Now turn on THREE of those particleSystems... one for chunks of flying shrapnel, one for puff of smoke, one for puff of fire.  Each one of your shot impacts would start looking rather cool, realistic, and animated.  Yet PERHAPS, you position NO black "scorch mark" image after the puff-a-thon. 

The impact can happen at an edge and/or anywhere else, and it fades-away at the speed of the particleSystem maxAge setting.  Particles can also change colors as their age gets older.  They can grow or shrink with age.  Yet, the impact triple-puff takes only 2-3 seconds to complete.... with all its smoke, fire, and shrapnel at THAT impact location, gone.  You won't need to wait for one particle-puff to complete... before moving emitter to another impact point.  The .manualEmitCount feature pukes ALL 100, 1000, 10000 particles.... RIGHT NOW... instantly.  After that, the particles will continue their age-evolution... but the emitter or particleSystem need not wait-around for its previous particles to die of old age.  As soon as it puffs, it can leave and go make another particle-puff somewhere else.

Are you trying for maximum shot-speed?  As in... machine-gun speeds?  Do you plan-on letting a user "shoot something to pieces"  (until its gone)?

Perhaps, the more I know about your goals, the better we can think-up hi-perf ideas.    Party on, have a great weekend.

[Wingnut]

https://playground.babylonjs.com/#2PBY8W#5

A little 'manualEmitCount demo'.    *shrug*.

[kurhlaa]

2 hours ago, Wingnut said:

A little 'manualEmitCount demo'

Thanks! Strange question - how do I set initial black color for particles?  black image's background is being used as transparent

[Wingnut]

https://playground.babylonjs.com/#2PBY8W#6

Line 22 - blendMode = 1   ...seems to fix it.  Default is 0, i believe.

I don't know the story, but I THINK it has to do with rendering depths and alphaTesting and alphaBlending and stuff like that.

After you play with particles a bit, you'll see that they will render IN FRONT OF certain things, and behind certain things, but it's difficult to get them to render on BOTH (front and back) sides of something (at the same time). 

I think... "particles front and behind" can be faked... using two particleSystems (with differing layer masks or renderingID's or something like that). 

I need to do more learning about depths.  I'm pretty weak in that department. 

[kurhlaa]

On 1/20/2018 at 8:16 PM, Wingnut said:

Line 22 - blendMode = 1   ...seems to fix it.  Default is 0, i believe.

Thanks! Check this one  https://playground.babylonjs.com/#635S1L#1

This happens when particles are before the mesh with alpha. There were some forum talkings about the order of rendering, but I'm not so good yet at terminology to understand. What can I do here? Can particles be rendered without transparency (only as in source image)?

[Wingnut]

https://playground.babylonjs.com/#635S1L#2

(line 28) 

[kurhlaa]

20 hours ago, Wingnut said:

https://playground.babylonjs.com/#635S1L#2

Bad result too  particles become square. And if I replace black background with transparent - it makes a part of mesh after it completely transparent: (here you are able to see pink ground through the red mesh)

 

[Wingnut]

Well, let's goof-around with some rendering groups...

https://playground.babylonjs.com/#635S1L#3

Lines 71 & 113.  Change some numbers... see what blows up.  Fun! 

And there's layerMasks, too... and needsAlphaBlending, and needsAlphaTesting... and and and... just SO MUCH to learn!  My brain hurts! 

I wish we had a "Do exactly what I want you to do" button.  heh

Let's get back to manualEmitCount shooting at the board.  Poom, Poom!  That was fun.

Ya know, particleSystems have... umm... 2-3 "magic" functions.  One is called startPosition()... and the other... update().

StartPosition() is really good at putting newly-spawned particles exactly where YOU want them.  Update()... can be told to DON'T let them fly/move... and don't let them change color-over-time... or spin on the z-axis... or change any size-over-time... and it can also ignore particle age.  Update is pretty powerful.  You can make your own custom Update Function.  Perhaps use it on a 2nd particleSystem.

See where I'm going?  A guy COULD... use that special "black charred particles" particleSystem... to spray a dark area onto the mesh at impact point.  That particleSystem would have a customStartPosition (to position the black "powder burn" particles onto the mesh near the impact point)... and a customUpdate (to keep the particles stationary, steady-colored, and fading-out with age, or not).

A special particle system JUST FOR the charred black mark!  Cool!  Then, STILL add another for smoke puff, another for fire flare, and another for flying chunks.  Flying chunks COULD be a special particle system called SPS... solid particle system.  It can spray non-uniform more-complex mesh... like chunks of assorted shrapnel.

Ok, so that's 5 particle systems... for one impact.  1-stationary powder burn, 2-smoke(rises), 3-soot(all-directions on outer edges of fireball), 4-fireball(often evolving color), 5-SPS for flying "chunks".

That would be SO COOL!  Then some GUI sliders on-screen... like 100 of 'em, so we can live-adjust all the settings on all 5 particle systems (while the gun is in auto-fire mode).  Wow!

Ahhh... exploding stuff... it always excites me.  Not sure why.    Pitchew... pitchew.