New Idea

[Mezzorio]

Hey! me again! 

I'm really enjoying Babylon at the minute, i'm looking at changing part of a project over to babylon, but wanted to know if you guys think or know if the idea would be possible and if so what would be the requirements, I'd like to make an interactive scene for characters, so essentially creating and positions sprites within a space going from Point A to point B being the start and end of an object that a camera with scroll across the face of, viewing all the characters who i will later add features too, such as clicking on them bringing up profiles, stats anything that will suit the build. I guess the real question I want to know the answer is, is if its possible to create a series of maybe 40 sprites all positioned across a scene and you can go from point a to b and back as you please, but also to keep looping, so for example if you go past point b, point a will restart. Essentially the current project carrying out this, is suffering from lag and is very unsmooth in motion and would like to utilise Babylon for an improvement., I have attached my poor attempt at a simple diagram of what i was after.

[Wingnut]

Not a problem, M-doggy.  Doing that is a BREEZE with BJS... and in ANY of about 3-4 different ways.  If you wanted, you and I could get the prototype for this done.... in about 10 minutes.  Ready? 

It might be coolest... to make a huge circle of boxes (flat panels).  Don't bother with sprites... they're boring.    (just kidding)

Then yeah, rotate the circle of panels past the camera, or pan the camera around the circle of panels.  FUN little experiments galore!

And, it need-not be a circle.  It can easily be a straight line, too.  No matter circle or straight line, it might be wise to parent all the panels/sprites to a central parent.  Then moving ALL the panels at the same time... will be easier.  Just move the parent, and all the kids come-along for the ride.

[Mezzorio]

17 hours ago, Wingnut said:

Not a problem, M-doggy.  Doing that is a BREEZE with BJS... and in ANY of about 3-4 different ways.  If you wanted, you and I could get the prototype for this done.... in about 10 minutes.  Ready? 

It might be coolest... to make a huge circle of boxes (flat panels).  Don't bother with sprites... they're boring.    (just kidding)

Then yeah, rotate the circle of panels past the camera, or pan the camera around the circle of panels.  FUN little experiments galore!

And, it need-not be a circle.  It can easily be a straight line, too.  No matter circle or straight line, it might be wise to parent all the panels/sprites to a central parent.  Then moving ALL the panels at the same time... will be easier.  Just move the parent, and all the kids come-along for the ride.

If you could get me a prototype to play around with to understand it before i start messnig with my build i would be soooo greatful! I'm really struggling with the actual object creation manipulation and stuff, shadows and creating the floor for some reason being the hardest! I'll attach a playground with my current project that I want to change as well  Thanksss!!!! I would like to be able to create a floor for shadows and such as im using 2d characters as you know as sprites currently, but i'm looking for anyway to change it over to the system which you seem to be a pro at! and make it smoother as its laggyyyy when movement gets too much!

https://playground.babylonjs.com/#IDDZ4K

 

[Mezzorio]

17 hours ago, Wingnut said:

It might be coolest... to make a huge circle of boxes (flat panels).  Don't bother with sprites... they're boring.    (just kidding)

 

That playground btw looks great! but do you know how to make it loop infinitely if we set it as a flat object moving left and right throughout the scene instead of using the current circle method!

[brianzinn]

Looks like you are building a carousel with infinite loop.  With my limited imagination I don't see how you are going to pan a camera across a flat infinite loop unless you are dynamically creating/disposing the objects as you pan a custom camera.

With a couple of small changes to wingnuts PG it gets pretty close to a carousel: https://www.babylonjs-playground.com/#HIUL9R#2

I just locked the camera, so it won't go up or down or zoom in or out and moved the boxes closer together.

[Mezzorio]

Im looking for a depth of perception effect, which you don't get having the camera in the middle, which was my original build and the reason ive changed to my camera on the outside build, but if its possible to reset positions without it looking funny and using flat objects it would make it better ten-fold.

[Wingnut]

Wow... you guys are doing great!  Shooooot, you're both better programmers than I am, so I'm going to steal all your code, okay?  Cool. 

I don't think sprites can cast shadows, but I haven't researched that real well.  I think a sprite is a "subMesh" in a way... like a single cell of a wireframed ground grid.  So, you might have-to place the sprites onto panels/boxes.  Those boxes... can cast shadows.  Reminder:  You don't need sprites AT ALL... as BJS boxes have the abilities to have an image on only one side, or only 2 sides, or all sides.  You can put the .png images into the .diffuseTexture channel of the .material of each box.  It might start with a boxmaking func...  boxmaker(boxname, position, textureToUse, scene).

Uncle Mezzorio's Sprite-Simulating Box-Generator v1.0 - the beginning of a legend. 

One of the determining factors for "wrapping" a straight line of panels/sprites... is the camera.fov  (field of view) with a proper camera.fovMode set, too.  Also, the camera-to-sprites distance is important.  Camera distance and horizontal field-of-view... determines how many sprites are .isInFrustum  (within camera view).

Let's pretend we have 200 sprites in a straight row/line.  Let's also pretend that... due-to current camera.fov and distance of cam to sprites... we can "see" 7 sprites within camera view ALL THE TIME.  These numbers can be easily changed, late-in-the-project, no problems.

When user has panned camera left (actually called dolly-left or truck-left) until #1 sprite is straight ahead, you need to have a copy/clone/actual sprites 198, 199, and 200... placed just before (left-of) sprite #1 in the line.  This is so that... when sprite #1 is straight ahead, user still thinks they can truck further left, and are convinced that a wrap-around from #1 to #200 will happen fine... IF they continue to truck-left past #1.  But code is "watching" them try it, and when they do, POOM, the camera is instantly re-positioned to the END of the line... looking straight-at sprite #200.  See diagrams below.

Same happens at s#200, at the end of the line.  Even though the new camera position is looking-at #200, there are "fake", cloned/instanced/actual sprites #1, 2, and #3...placed to the right of #200.  This gives the user the indication that they can continue trucking-right... and they can... but it will SNAP the camera back to looking-at sprite #1, as described earlier.

In other words, when camera @ s1,  and knowing the camera can "see" 7 sprites inFrustum all the time, then we must put a fake s198, s199, s200 on the LEFT side of s1.  User can never truck the camera to the fake mesh, but we fake it... by snapping the camera to s200... SO fast and smoothly... they never even know it happened.

Same at the other end.  We can see 7 sprites at a time, when s200 is straight ahead.  We need to put fake s1, s2, and s3 to the right of s200.  Again, they can't truck the camera to those 3 fakes, but the user thinks they can, and when they try, code sees them try it, and we do that fast cam relocation to s1 again.  User doesn't notice a thing.  A cam relocation takes about what?  1/6000th of a second?  (I have no idea, but I bet it is fast).

Nice part about it?  No need to change position of the panels, or their parent (if they have one)... at all, ever.  It's all done with the camera, and/or with an invisible gizmo mesh that the camera is parented-to. 

The Sprite "line" sort of looks like this...

s198, s199, s200, s1, s2, s3, s4     ...    s197, s198, s199, s200, s1, s2, s3.
 \                              |                   /                \                               |                   /
    \                           |                /                      \                            |                /
       \                        |             /                            \                         |             /
          \         viewing s1    /                                  \       viewing s200   /
       User thinks cam truck-left                      User thinks cam truck-right
             is ok.  It is, but faked.                              is ok.  It is, but faked.
           Move cam to s200 view.                          Move cam to s1 view.

Understand any of this?  I hope so, because I'm just barely hanging-on.    This is ONE way of doing it.  There is likely more ways, but maybe not better ways.  With this method, the "wrap" is FAST FAST FAST, and done with a single line of code, I believe. 

Putting a BJS animation onto the camera... might be the best way to move view from sprite to sprite.  That way, we get the nice ease-up-to-speed, and ease-down-to-stop features of BJS Animation/Animatable class.  That will be a smooth and nice way to move from sprite-to-sprite.  Ground can re-position left/right using the same method, as needed.  Ground MIGHT be parented to camera, and then perhaps that's all it needs.  It moves left/right each time camera does so.  *shrug* 

A spotlight shooting straight ahead of camera, parented to camera, might be cool, too.  The light encircles the sprite straight ahead... and could cause another shadow.  There are other ways to "highlight" one sprite, such as .showBoundingBox, edgesRenderer, highlightLayer, glow effects, you name it.  But putting a single sprite "in-the-spotlight" is kind of cool, too.

I might make one of these "sprite lines", later, if nobody beats me to it.  But feel free to advance this idea, at will, everyone.  I got a bunch of IRL crap to take care-of first, before I can get to this.  Party on!

[brianzinn]

@Wingnut genius idea to take care of wrapping, so you just need to have enough visible on each end to have smooth looping!  Now just need a way to pan/dolly/truck a camera left to right.  It would be easy with GUI buttons to do an animation on camera position - maybe even a bouncy easing function, but I don't know how to do that with click-drag.  Might even be able to use the 3.1 behaviours somehow...

[Mezzorio]

14 hours ago, Wingnut said:

Wow... you guys are doing great!  Shooooot, you're both better programmers than I am, so I'm going to steal all your code, okay?  Cool. 

Uncle Mezzorio's Sprite-Simulating Box-Generator v1.0 - the beginning of a legend. 

 

For one @Wingnut you're a god damn genius haha this helps so much with my understanding of how to approach this, im launching the project changeover on monday, so anything we discuss or build in playgrounds until then is all helping me prepare for monday! especially if you can get a working playground up an running so i can demo the potential to others! 

[Wingnut]

Thanks for the kind words, guys.  Not genius, just... been at this for a while.    Problem is... I'm somewhat old-school, and in being that way, I teach old techniques.  Others are MUCH BETTER coders than I, but, great coders often don't like talking to humans.  They rather talk to computers.  heh.  Oh well.

https://playground.babylonjs.com/#IDDZ4K#8

Progress in-progress.    Nice tight looper, shadows, demo pics, name tag buttons, we're rollin' now, eh?  Control-drag to inspect the troops.  Talk happening in The Wingnut Chronicles... about this, too.  But, its REALLY nice out there today, and I SHOULD be musky fishing right now, ya know? 

Off-topic:  Wanna see a musky-fishing-related parody song, I recently wrote?  I knew ya did!  First, get "Walk Like An Egyptian" fired-up...

https://www.youtube.com/watch?v=Cv6tuzHUuuk

Then visit:  http://webpages.charter.net/wingthing/misc/fight_muskellunge.htm

Use MY words instead of Bangle words.  I think mine are better than theirs, cuz their's are WEIRD!  But my new words are weird, too... esp if you have never fished-for muskies. 

[Wingnut]

Another version of "Project Mezz":  https://playground.babylonjs.com/#IDDZ4K#11

'a' and 'd' keys active, for moving cam left/right.  Wrap active.

Lines 54 and 60 show our "fake panels" on the beginning and end of the array of ACTUALS.    Five extra panels on both ends of the string... enough to fool the user, at current cam distance and fov.

Lines 120-150... a rack of new funcs... with moveLeft() and moveRight() using camera.target.x as a determiner for wrapping.  I suppose a person COULD maintain a currentPanel indexer, and use THAT as the wrap-is-necessary determiner, too.  No currentPanel is maintained, yet.

Besides needing to install @brianzinn's nice alpha/beta/radius limiters, AND perhaps his GUI buttons ideas, I gotzzzz one problem.  Keypresses are FAST!!!  ZOOOOM, the 'a' and 'd' keys just WHIP that camera along "the ranks".   Time for more of Brian's good ideas... like maybe some animations, easings, and bounces... but NOT using keypresses.  hehe.  Those darned high-speed keypresses won't allow enough time for any cool cam-animation... to finish.  Or even START! 

Dolly the camera WAY BACK with the mousewheel, and it's easier to see the wrapping that happens with the A and D keys.  The camera wraps when it is 5 panels from either end.

Fun project!  But, you know, it's starting to smell like Miller Time tm

I caught a big-ass northern pike, and a crapload of smallmouth bass, earlier.  FUN!  No muskies, though.  hmm.  (Wingy looks under the rug for muskies, but finds his dog sleeping there, instead.) 

[brianzinn]

I put an animation on truck left, so 'a' key only.  it needs to account for the edge case, but looks smooth.

https://playground.babylonjs.com/#IDDZ4K#12

[Wingnut]

NICE!!!!  Perfect!!  Or at least damned good!  Coooool.

[brianzinn]

Yeah, not perfect.  You mentioned high-speed keypresses, so what I'm doing is having key-presses during animation ignored, but they could be buffered or anything, really.

[Wingnut]

Thanks for the help!!!  The things you are doing... are the parts of BJS programming that I am terrible-at.  You seem to have them well-mastered!  Love it!

[brianzinn]

I actually messed up the blocking part - fixed it and upped the movement to truck 2 left.  Not far from being usable as a carousel really. Would be cool to get swipe going, but I never got into that... hand.js/PEP.

https://playground.babylonjs.com/#IDDZ4K#13

[Wingnut]

Keep on truckin!  Maybe later, we'll turn on a nice skybox again, maybe some sparkly particles, possibly shooting out of the panel corners!  Perhaps some spherical harmonics with godrays! (click run over and over again)  WOW! 

Perhaps activate that freight-train-grade spotlight... shooting out-of the front of the camera, darken the room, add a little fog, maybe some blood-red-colored CLOUDS procedural texture on the ground (looks like lava, cuz clouds procedural texture is auto-animated). 

Mezzorio would crap his pants, eh?!  It'd be pretty funny.  Hey Mezz... you say you wanted a working prototype?  Well, how about a fire and light show to go with that?  hahah

How about some soft y-axis "floating" of each panel, as if bobbing in water?  Wow 2.0!   Mezz would need the shop vac... to suck-up all his drool. 

[Mezzorio]

hey guys! Being moving house had no time for my babylon fun today!  Just got on to look at your guys work on the playgrounds they look really cool! I have one question, and thats towards wrapping textures around the sides of the objects, can you get it to wrap to the same of an image i want to put onto that surface?

[brianzinn]

Check out this tutorial: https://doc.babylonjs.com/tutorials/createbox_per_face_textures_and_colors

PG with images on sides: https://www.babylonjs-playground.com/#1V3CAT#13

[Wingnut]

On 8/25/2017 at 10:35 AM, Mezzorio said:

can you get it to wrap to the same of an image i want to put onto that surface?

Hi Mezz.  Could you please re-word that?  (I hope the moving went well, btw)

There is no automatic "wrap" feature, in the classic sense... but I think it can be faked.

https://playground.babylonjs.com/#IDDZ4K#14

I made the panels thicker, and set some on-the-side images... based on the " createbox_per_face_textures_and_colors " ref that Brian sent.  Lines 75-91 is where the work is happening.

Single image...

0,1                     .25, 1                                          .75, 1                         1, 1
********************************************************************
**                            |                                                  |                               **
**                            |                        F                        |              R              **
**            L              |                        R                        |              I               **
**            E              |                        O                       |              G              **
**            F              |                        N                       |              H              **
**            T              |                        T                       |              T               **
**                            |                                                  |                               **
**           S               |                       S                        |              S               **
**            I               |                        I                         |              I                **
**           D              |                        D                        |             D               **
**           E              |                        E                         |             E               **
**                           |                                                   |                               **
********************************************************************
0,0                     .25, 0                                          .75, 0                         1, 0

Notice how UV's are similar to percentages?  .25 = 25%, .75 = 75%, etc, etc.  Handy to keep in-mind.

Is this what you mean, Mezz?  SOME of the image... maps-onto the left side, and another portion... maps-onto the camera-facing front side, and another portion... maps-onto the right side?

If this is what you mean, then I THINK it can be done, but it requires some fancy faceUV work.  FaceUV[1], [2], and [3] would NOT be all 0's and 1's anymore.  They would be numbers similar to...

faceUV[2] = new BABYLON.Vector4(0, 0, .25, 1)  //  left 1/4 of image... 0% to 25% of image x-width... is mapped-onto left side
faceUV[1] = new BABYLON.Vector4(.25, 0, .75, 1)  //  center 1/2 of image... 25% to 75% of image x-width... is mapped-onto front side
faceUV[3] = new BABYLON.Vector4(.75, 0, 1, 1)  //  right 1/4 of image... 75% to 100% of image x-width... is mapped-onto right side

Important note:  Notice that images/textures are "mapped" with 0, 0 in lower left corner, and 1,1 in upper right.  "Coordinates"!   Nice word, eh?  If you use that word in USA coffee houses and other public places, people will think you are a scientist.    (Butt hay, we ARE geometry scientists, in a way, right?)

First step, the side images need to be rotated to match the front image.  Line 86-90 is an attempt at rotating the side images correctly, but I wasn't successful at that, yet.  When the two side images are rotated correctly (same as front image)... then we can start playing-with these UV values and see if we can simulate wrapping, as described above.

Although I don't have the rotation adjusted on the left and right sides, let's try a playground with the above faceUV numbers...

https://playground.babylonjs.com/#IDDZ4K#15

As you can see, we DO have a good FRONT image.  Only the center 1/2 of the image is mapped onto the front faceUV[1].  But the image-portions on the sides (left 25% of image on left side, right 25% on right side)... don't look so good.  Still experimenting.   I lost the shadows, too, because I had-to turn-on a hemi light to help light-up the sides of the mesh.  The above-the-cam directional light is poor-at lighting the sides of the panels.

A fix for that MIGHT be changing from .diffuseTexture (uses lights)... to .emissiveTexture (texture does self-illumination).  But we still need a light.... for shadows.  A combination of directional light, and emissiveTexture... sort of wimps-out the shadows (because I need to set the dir light to such a low intensity... to keep the image from "washing-out" from over-lighting.)  Here's an example.   https://playground.babylonjs.com/#IDDZ4K#16

Wimpy poor-color-contrast shadows, and SOME washout on giraffe's clarity.  I think there IS a way to make a light cast shadows, yet NOT affect the colors/brightness of the mesh in its shadowMap renderlist.  I can't remember how to do that, but there is a forum thread about it, somewhere.  Possibly light.excludedMesh array. 

When using the image in the .emissiveTexture channel of the .material, a... "Mister dirLight - please don't change the panel color/brightness" -feature... would be useful/handy.  Then we could increase the .intensity of the dir light again (better shadows), yet not see colors-washout on Mr. Giraffe, due to over-lighting.  In that #16 PG, increasing dir light intensity in line 17... brings back the nice shadows, but washes-out the Giraffe clarity.

Back to UV subject... many people are better-at UV's than I am, but particularly @jerome, who "invented" the texture-per-face system for BJS boxes.  Perhaps he will stop-by to visit us, and lend his wise advice.  But, advice/help from everyone, quite welcomed.  Talk soon.

[Wingnut]

Oooh, @adam showed us a "slerpToRef" over in another thread.  http://playground.babylonjs.com/#UMQ4UR#2

Sweet little ease-in/out animation system, possibly apropos for moving from panel-to-panel, for our project, here.  I like it.  It uses the same type of linear interpolation as the BJS animation system, but without all the frosting and sprinkles. 

[jerome]

not sure to understand what is the question ? if there's a question ... 

[Wingnut]

Hi @jerome, thanks for the interest.  In PG #16, I have tried some experiments in lines 93-98... to rotate left-side and right-side images.  I would like them both to be heads-up, just like the camera-facing Giraffe image (faceUV[1]). 

If possible, can you help us rotate the left-side and right-side images (faceUVs #2 and #3)?  They need to match faceUV[1], rotation-wise.

Thx, J!

[jerome]

ok gotcha ... mmmhh... for now you can't with faceUV

Please have a look at how the images are pinned to the box geometry : https://playground.babylonjs.com/#IDDZ4K#18

On the left and right sides, the images don't have the same basis (bottom/up) than the one on the front side. Why ? just because the initial geometry was done this way for some reasons...

The feature faceUV only allows you to crop a part of a big image and to paste it on each side. At the best, you can even flip it left/right or up/down by inverting the x,z or y,w values but you won't change the orientation.

I have, in my endless todo list, the plan to add an option to build the box with at least 4 successive sides having the same basis. Not done yet ...

[Wingnut]

Ok, thx J.  Well explained, and I expected that reply.  Thanks!

We can still fake it, somewhat easily.  Turn off faceUV system, and position/parent 3 planes... against the 3 sides of the box.  Use a little material.diffuseTexture.uOffset on the side planes, play around... fake the "wrapped look".   No problems.  But, I suppose we should wait for Mezz... to see if I misunderstood objective.    I do that sometimes.

Let's see... if we actually created each panel FROM 6 parented-together planes... um... the shadow generator would still work fine, and we could even meshMerge the 6 planes of each panel, as wanted.  I think that method can work well.  Plus, with a 6-plane box, you can "explode" the box, sending the 6 planes flying... for special effects.    Each plane might cast a shadow as it tumbles-away.  Maybe some sparks/particles/smoke... spraying from verts of tumbling planes.  Cooooool. 

Paul Simon had a song... what was it?  50 Ways to Explode Your Boxes"?   Errrr.  ?    "Ya just blow-out the back, jack.  Cave in sides, Clyde.  Ya don't need a transform, Norm... just listen to me."   etc.