Borders for the Rendering Canvas

Demos and projects
1

Hi gang. I have a weird idea/challenge that I want to learn about, and experiment-with.

I wish to surround the edge of the render canvas… with mesh sticks/boxes/tubes… and have them scale length-wise… perfectly, no matter the canvas scaling/sizing (and no matter the cam FOV). (edging)

What are the chances?

I have a difficult time thinking-up the many ways a renderCanvas CAN be resized. The playground is definitely a non-full-screen canvas.

  • It (the browser) can open F12 dev tools, and a horz drag-able divider demarcates the dev-tools subwindow… which resizes the canvas.

  • The browser’s window can be restored and drag-sized at that point, too… while the devtools window is open or closed.

  • Firefox history or bookmarks sidebar can be opened at any time (such as in playground) and that resizes the canvas.

  • BJS cam FOV can be live-set - not a canvas-resize thing, but still a pertinent consid, and I like these little bullets. :slight_smile:

All in all, what are the possibilities for mesh-as-borders for the renderCanvas? Know? I would REALLY like this to be completely air-tight… where ANY method of resizing… dragging, bottom-panes, side-panes. mobiles, phones… CANNOT disrupt the length and placement of these “border tubes” or “edging”.

Thoughts?

Do you think BJS could continuously maintain some values FOR US… perhaps on Scene object… of the 4 - 8 values needed?

Is it a calculation? Edges of frustum? An angle between camera and frustum edge… that needs unprojecting? HELP!

Note: Parenting mesh to cam… has already shown to be inconsistent and easily thrown-off by various resolution changes and similar torture.

I would LOVE to accomplish this… for placing 3d borders and particle sprayers around the edges of the render canvas… and have them rock-solid and precise, no matter what type of resizing ever happens.

Extra credit for VR consids. Use mesh border available in GUI 3D full-screen mode? (that’s a weird idea, huh? I’ve never used GUI 3d… yet… especially trying to mesh-border the entire ADT.)

Stereo cam-rigs might need left edge removed for right eyepiece, and right edge removed for left eyepiece. erf. Not sure about that (or about much else).

Thanks for your thoughts, fellow experimenters.

2 Likes
2

2nd orthogonal camera using layermasks is the way to go. The ortho cam is in front of the scene camera.

2 Likes
3

Thanks Jeff… I’m going to move in that direction. Generally, this topic fell dead on the floor… but I don’t care… I’m going to pursue it, and narrate that pursuit. :slight_smile:

Early tests of parenting mesh borders… to an ortho cam… are working pretty good, so far. I have NO experience with ortho, but this “mode” seems to be keeping its children’s positions… holding-solid… thru many canvas resizing torture-tests.

SO, let’s wire-up a particles-along-the-edges demo, and see what she looks like:

https://www.babylonjs-playground.com/#DK44MZ#4 (try #6, too)

Purrrrrdy. The border mesh are still set visible, though they don’t need to be so. I like the effect.

It feels like I am Spock or Kirk or “Bones”… about to jump thru a time portal… found in an ancient library. :wink:

Now Jeff (or anyone)… about this layerMasking and one camera in-front-of another… can you please expand on that a bit… maybe show me/us what you’re thinking? thx! ANY comments/experiments welcome… from everyone.

6 Likes
4

Cool effect @Wingnut :sunglasses:

1 Like
5

Thx integra, and other likers. Here’s a fresh test.

https://www.babylonjs-playground.com/#DK44MZ#10

I’m starting the layerMask stuff that Jc told-of.

Camera1 is the ortho freecam on layer 010… at a z-pos of -40. Four invisible border edge-mesh are parented to this cam, and being used as particle emitters.

Camera2 can be a free or arc (change at line 16) on layer 001… at a z-pos of -15.

When free cam, there is a problem when down-arrowing further away from origin. (I can see another particle frame)

When arc cam, there is a problem when orbiting 180 degrees, away from origin. (I can see another particle frame)

Line 32… force-sets scene.activeCameras array. Changing order of cams in this array… seems to have no change in mentioned problems. (likely normal)

Only camera2 is “attached” to canvas.

Interesting! (for me, at least) Still testing. Learning… the early years. :slight_smile: Versions/ideas/comments welcome, of course.

3 Likes
6

Nice effect!

You simply forgot to set layerMask of the particle system, that’s why it is also rendered by camera2:

var ps1 = new BABYLON.ParticleSystem("ps1", 20000, scene);
var url = "https://cdn.rawgit.com/wingnutt/misc/master/star.jpg";
ps1.particleTexture = new BABYLON.Texture(url, scene);
ps1.layerMask = 0x00000010;
1 Like
7

NICE CATCH, EP! Thanks! (for the kind words, too).

Yeah, I think there’s some interesting things that can be done… with edges like this. I may try some godrays (VLS) a bit later.

Also, I’ve been watching you on the forum, and I want to say THANKS for being a helper and contributor. You seem hot hot hot, tech-wise, to me. Don’t ever leave, ok? We’re lucky to have you hanging-out with us, and I’m lucky to have you look at these demos… and nail the issue at-hand! (hi-5)

PG#11 includes EP’s fix.

Particles from vertices might be fun… too… maybe with some rotations of the edge-mesh. I might be able to get some cross-hatch/lace patterns… made from particles streams, along the edges. (moire patterns/interference). coooool. I didn’t code the particles-from-vertices thing, but I think it uses normals as particle emit direction, so… normals become the particle spray nozzle targeting system (animate the normals?). Custom start and update funcs in the particle systems… could likely do the same, without using nomals/verts as emit points.

The “canvas border” system is actually more versatile than particles or godrays, though. Later, when math-generated borders REALLY get popular, mesh like this is possible. The great “see who can code the coolest dynamic borders” competition will take-off big-time, and become a worldwide hobby/obsession (I predict). Thoughts? @dad72 is an edges carpenter/craftsman, I hear. :wink:

1 Like
8

Thanks for your kind words!

I’m going to need to earn some money in the near future, however, so I may have to put aside my 3D playing for a while. Life is hard sometimes!

9

Did not see that you were asking about layermasks without directly @ing me.

@Evgeni_Popov was right about the layermask, but he did not know something I put in or had put in, which makes it more elegant. That is by default the layermask is 0x0FFFFFFF. This leaves 4 special ones in the high range. See one of the few docs I did.

Why this is elegant is you just need to change the layer mask for anything associated with the 2nd camera to one of these height ones, without screwing with the entire scene. This makes popping this on any scene easy.

Also, must say this 2nd camera approach is not WebXR / WebVR friendly. You cannot have it all. Do not think that is a problem though. The spatial gear like Hololens / Magic Leap it would both kind of ruin the effect & FOV is kind at a premium. Your Occulus / future apple device where you can not see through it would probably not look right either.

To do it on those devices, you could not use a 2nd camera, which means that you would have to be moving the particle system where ever the camera pointed / went. Not near as easy.

2 Likes
10

Yeah, monetary “or else” (extortion) is a regular happening, eh? Cost of living terrorism. Sorry to hear it’s happening to you atm, EP. (Let’s try to help him out yet stay in 3D land, fellow forumers!)

In the USA, we thought we beat the “or else” extortion when Elliot Ness busted the “pay up or else” happening in Chicago… with the terrorist mobs. No such luck. “Or else” is rampant… run-away levels… right now. Sad.

Wingy snoops the cleanliness of Deltakosh’s office at MS… to see if the janitor needs replacing. (Hey, it’s a foot-in-the-door for ya, at least). :slight_smile:

11

I don’t want people to loose their job ! :open_mouth:

1 Like
12

I think you’d be promoted to core prog team… in about 8 minutes. :slight_smile:

13

@JCPalmer - Thx! Care to make one from PG 11?) (hug)

As I understand: Camera 1 and normal mesh… all live-on layer 0FFFFFFF by nature/default… so no need to set. Only need to set camera 2 and “extras”… to something other-than 127… thus making the effect a bit more portable. (I think I said that right) :slight_smile: Adjust my understanding at will, guys. thx.

14

The scene camera, & scene meshes (ground & sphere need no layermask). https://www.babylonjs-playground.com/#DK44MZ#13

In this particular example, still many, but real scenes have more than 2 meshes.

1 Like
15

I think you have it.

https://www.babylonjs-playground.com/#DK44MZ#14

Removed the layerMask for the objects living in the default scene and set 0x10000000 for the border objects and the ortho camera.

[Ah, @JCPalmer has just beaten me to it!]

1 Like
16

Thanks guys. Yeah, I had a little confusion as to WHAT was camera2 and what was “second camera”. Good good good. (WIngy dances a bit)

17

One final thing from a packaging perspective. The 2nd camera should be the border. Meaning with a scene that someone has already established, then they add your extension to get a border. In that case, the ortho camera is defined 2nd not first.

Because you have invisible meshes, it might not matter what order, but you might want to experiment with meshes visible & stuff in the scene off to the side, to check for problems.

When you have multiple cameras, scene.activeCameras array is used & has more than one. you might need to switch the order of them to effect your ortho stuff being written last, since this is sort of like a post process.

1 Like
18

As I thought, if you switch to the freecam instead of the arc rotate using that switch in your PG, you will see that the definition of the ortho camera being first is a bug. Makes adding afterwards of the ortho later the right way as well.

19

Thx for info, Jeff. Well done.

https://www.babylonjs-playground.com/#DK44MZ#17 (gettin’ some ‘bog’) :open_mouth:

Just another toy… early tests of godrays. I have a test GR in the center of screen, using the gr.mesh provided by default (a billboarded sun-like mesh). When you set the 4th param to null (like line 138), a mesh is provided FOR US… and positioned at origin. That default mesh needed to be brought-aboard the correct layerMask… in line 149.

Four more GR’s get fired-up, too… one for each border-mesh piece. You can see the borders glowing in GR.mesh.material.texture colors… but I suspect the “rays” are dithering along the edges of the ortho cam (camera1) frustum. Thus… not much “effect”… (or “affect”… one of the two… or maybe both) :slight_smile: No photonic angularity. (huh?) :wink:

I have tried using camera2 (the non-ortho cam) as the camera for the godrays constructors, but that fails. Perhaps I need a godrays.pretendTheCameraNotOrtho = true; :slight_smile: Good fun, all in all.

Get a little movement happening on the borders (via the renderLoop)… and things start to come-alive, and bog even more. [seizures warning]

1 Like
20

Hi again. I’ve been thinking more about “things to make canvas borders-with”… and I revisted the eye-drool-inducing particles-from-normals system that somebody coded.

https://www.babylonjs-playground.com/#2A4NUR#55 (a bit perf-heavy)

TWO particle-emitting gizmos, there… attempting to make a moire or interference pattern (similar to what happens when two water-waves “interleave” with each other). HOURS of fun can be had, in this PG, in lines 103-166.

Sort of like a loom… fabric weaving. Fun.

What I’m REALLY seeking, though… is 4 “racks” of steerable particle-emitting spray nozzles (spray bar), one for each border of the canvas. Maybe… oh… 100 program-steerable spray nozzles along each border, and particle system gravity… is always pulling outward.

ie. Left border-edge sprayer rack… has gravity set -5, 0, 0, top spray-rack - gravity 0,5,0, right rack - 5,0,0, etc, etc. All particles spray toward center of canvas, and they gravity-fall towards outside… towards out-of-frustum.

https://images-eu.ssl-images-amazon.com/images/I/31I7z7C7oQL.jpg

I need the center sprayer-bar thing… but with each spray nozzle… program-steerable… and the whole bar steerable, too. Would I use a mesh (spray-bar) on each border of the screen, or a “virtual spray-bar”… which is an array of positions and directions for particleSystem customStartPosition() and customUpdate() functions to use? Hmm. Thinkin’. :slight_smile: Purrrrdy