Viewport position of a minimap on second camera


I’d like to know how is the position of the mini maps in this playground calculated?

I tried to implement in a project with no joy grasping the logic and no success placing a mini map in the corner of the screen for good.

Hiya @ilia, welcome to the BJS forum.

I’m the author of that playground (with help from many)… so I can help ya.

A little better. :slight_smile: In the #14 playground, all 4 “renderTargetTextures” (rtt) and a black plane called butback … were parented to the main camera. That is why they seemed “stuck-to” the camera. They are difficult to position when that parenting exists.

In the #70 playground… line 71 shows that monitor #2 (the minimap plane) is still parented to camera. This method of keeping the mini-map in upper corner… is not real good. We have had reports of trouble… when using assorted/varied canvas sizes (or resizes). In line 57, I ATTEMPTED to position monitor2 based-upon the current canvas size. This may need tweaking, or maybe needs to use a different method.

There is another way to make mini-maps, and that is… using a “viewport”.

I am far from a pro. Here is a playground search for ‘minimap’. It returns a few demo scenes. You should tour them.

A search for ‘minimap’ on our previous forum… returns many hits.,29,30,31,38

Again, my 4-renderTargetTexture playground/methods might not be the best way to do a minimap. I suggest touring-around for better methods. Viewports are very nice. They do well with canvas resizes… but they are a challenge to put a border-around.

Once, I made a 3-viewport playground, but then I added two more viewports… just for drawing blue divider lines.

The 2 blue lines… are actually cameras/thin-viewports… aimed at a blue plane, which is placed far away from main scene. I made this PG a LONG time ago, before the invention of layerMasks. LayerMasks could probably prevent the need to move the “blue line camera” far away (hide it).

During your experiments, you will work-with three “camera directives” that are each quite important and adjustable:

  • somecamera.attachControl(canvas) // you can do this to many cameras… or one.
  • scene.activeCamera = somecamera; // always one camera
  • scene.activeCameras = [camera, camera2, camera3] // array of one or many cameras. The ORDER of the cameras MIGHT matter (I can’t remember). You’ll often see cameras pushed into this array, but feel free to force it however you wish.

It will take some time and experimenting… to get your cameras the way you wish. In the #70 demo, notice that line 10 is disabled. Instead, in line 134, I CONSTANTLY set camera2.alpha (orbital spin) = camera.alpha. This way, main camera can move freely, but minimap camera2 can only spin, and never tilt or mousewheel-zoom.

Ok, I hope this helps. Stay tuned for more comments and likely some great mini-map demos.

1 Like


Thank you very much for this answer - seems like a good load of work to compile!

Saw the viewports but from what I’ve read decided they need be always adjacent… Will try now/in the morning and keep you posted.


Best regards,

1 Like


Hello again!

Here is what I’ve got so far:

Generally it’s working, just a couple of questions please:

  • in my app the selection of the any of the three blue objects (they are even more actually) works every time, but in the playground linked it works from time to time and only if the object is roughly in the center of the viewport - how to fix this?

  • the axis drawings (the lines) are rather anemic - what’s the best way to make them thicker and have “arrows” or other reasonable top end?

  • finally, the whole idea of this “minimap” is to give the user a simple orientation how a data graph is presented in the 3D space - is there a better way to do this?

  • “optimized” a little bit the “_camera_point()” function - line 168 - should I even bother with such efforts?

Thanks again!

And here are some further developments about the first question/problem:

As I have some context menus in my app, they do not work on the first object that has position (0, 0, 0). It turns out, this object is “hidden” by the axis drawing in the other viewport and receives no events.

Removed all the axis drawings a left but a sphere - it hides the click on the first object. If you comment out lines 261, 262 - no click on the first object is possible. With the 2 lines ON, the sphere is away from (0, 0, 0) and the first object is perfectly clickable.

@Wingnut Please advise!

Hi again, i. Phew, tough issue. Let’s invite EVERYONE to participate, because this depth/alpha-testing/pickable problem… is at the edge of my intelligence levels.

Just goofing around with the layerMasks, trying to determine WHY clicks are being blocked. I disabled one of the axis-label planes… so I could click past the planes on the big view… testing.

Also playing with a thing called renderingGroups. (mesh.renderingGroupId)
It can be 0 (default) or 1, 2 or 3.

I’m not absolutely sure that there isn’t a core-level bug involving picking/layerMasks.

I’m not a pro on this “How mesh are rendered” stuff… especially when alpha is involved.

But your plain black sphere test… has no alpha involved.

As soon as I set black sphere.isPickable = false… things start working.

SO… maybe… issue involves minimap items being set .isPickable = false.

I’m a little slow today… not highly motivated… but I will think and test.

Let’s invite EVERYONE to help. And everyone… please tell/teach the things you learn. (thx)

Happy to help but could I get a simpler PG to make sure we eliminate all side effects?
What is the problem with this one?

Hi DK, thx for help!
In PG #11, disable lines 261 & 262, and then picking object 0, won’t work.

Set s.isPickable = false; … then works. But is it on a different layerMask than 3 objects? I’m a bit confused.

Ok gotcha. But this PG is really too long for me to quickly check. That is the problem I tried to underline.
I can easily fix a simple PG between two meetings during the day but if they are not cleaned enough it will delay my answer because I have to dig into the non problem related code.

Hope that makes sense :smiley:


Completely understandable, for me. I think Ilia and I have more reading/learning to do… before we can present a more-simple testing playground. We’ll try. It “feels like” we need a layer.isPickable heh.

But this time I found it :slight_smile:
It is definitely a bug where the ray caster considers meshes on the wrong layer.
Stay tuned folks!

It will be fix for next commit

1 Like

[mega-HUG]. No hurry, of course.

(I should not speak on behalf of Ilia, though)

And Super-Thanks!

Guys, you’re are amazing! No hurry at this end too, have enough to do, plus can always offset the initial point of my drawings.

Thanks again!

1 Like

Not sure, but I think you need to build your own axes arrows… from mesh (two cylinders per arrow). Stay tuned for more comments on that. You could use Uncle Wingnut’s Air-Cooled High-Performance Racing Arrows. errr… maybe not. :slight_smile: If you use it/them, wear a safety helmet, because they REALLY POINT POWERFULLY. heh. (ahhh, geo-comedy) :slight_smile:

Do you see a ‘scene explorer’ on the left-side of canvas? I love that thing. I think the entire debugger/inspector is a BJS extension, so you can use it in personal projects. Not sure, though. I LOVE having “drill the scene graph” as a handy tool, though. I have little info about it all.

Also, here is a cool ground texture for beginners… called orient.jpg… which I once made (use it freely). Set it as ground texture (like seen), and set ArcCamera.alpha = -Math.PI/2 (aimed +z). This makes it easy for youngsters and noobs to “get their orientation”.

Yeah, why not? Have fun… perhaps present different versions to your friends/co-workers, get their “feelings”. Camera-moving… is “art”. Ask any camera-person. :slight_smile:

Stay tuned for more/better comments.

It will be fixed in a couple of hours (just the time for the build to finish and get published)

1 Like


It’s fixed now, thank you!


Thank you for you help!

1 Like