How to create plot-like camera controls?


I’m new to BJS. I’m glad to see an active community providing friendly support!

I’m interested in customizing camera inputs for managing the view of a single Lines mesh representing 2D plotting data. Initially, I’m able to specify camera.ortho* by using lines.boundingInfo() to create an initial view of the data. However, as a user zooms/pans, I’d like to modify ortho* to zoom in/out while maintaining the aspect ratio of the screen, ensuring that there’s an accurate project of the data to the screen.

Here’s a simple example that I’d like to add camera controls to: Babylon.js Playground

What’s the best approach to implement custom mouse controls for this? I’d appreciate any insight folks have to point me in the right direction!


1 Like

Hey, welcome to the forum FBA! Good to have you with us.

You ask good questions, and I’m not qualified to answer. I have a question, if I may.

Are you seeking a classic “quad-view”, eventually? Something like… ?

Alternatively and “back in the olden days”, they (the modeller programmers/designers) sometimes used stuff like this… (run it a second time… to make dragging work)

I once made a simple “tri-view”… using BabylonJS viewports. (it’s actually a 5-viewport canvas, because the 2 blue divider-lines are also viewports).

If you ARE headed-towards 4-view (any of them can be told to go full-screen, of course)… then… hmm… maybe it would be best to think-about “custom viewport class” (a u-code-it extension of BJS viewport class).

4 sub-types/classes… ortho-left/right, front/back, top/bottom, and 3D. When any of the 4 types… is “focused”… THAT is when camera keypresses, camera mouse pans/drags, click/picks, and single/multi vertex drag/drop… turn “specialized”. All those things… get special “behaviors” for that type of viewport and mode. For vertex/vertices-dragging (and don’t forget snapping/quantizing - ahem), “selecting” is very important. Commercial modelling packages put heavy work into making their vert/edge selecting… powerful, as you likely know. FFD-box and space-warp ops, too. Beefy vert-wrangling stuff.

Custom behavior-izing 4 customized viewports… trying to make them portable and arrange-able on screen, and “focus-able” (to activate ITS behaviors)… I don’t know if that is the wise move, or not. It is just an idea, and it might be the direction that I would pursue… if I ever wanted to build a quad-view modeler in webGL.

Are we out-to make Blender’s and 3dMax’s quad-view/editor-panes… cry? hehe. Their quad-views are pretty nice. You could have a big task ahead… IF you wish-to make them ashamed to exist. :slight_smile:

We could just blatantly STEAL the likely-Python quad-view from Blender… and… umm… nah, that won’t pay-off. hmm. :slight_smile:

I sort-of complex-ified your basic questions, didn’t I? Sorry. I needed to know if you are going selecting and vert dragging in these views. Camera nav, keypress-nav, and vert-dragging… all sort-of need to stay in close-communication. I figged maybe… it was a wise time to ask “how big are we going, flybyair?” :slight_smile: Sorry for so much yapping.

Stay tuned, surely LOTS better answers/ideas… coming soon.

Not quite what you are after but this sample PG leads to a question - is this similar to the effect you want but with the ortho camera?

Thanks for the thoughtful reply!

These are all great ideas! I’d like to point out that my use case is to work primarily with 2D scatterplot data, so there’s no need to project data into different views. So, in a way, I am wanting to customize the behavior of the single viewport so that the user can zoom/pan around with the data.

I thin I’ve been able to get the key mechanism implemented:

Right now, I’m just creating a derived class of FreeCameraMouseInput and changing the _pointerInput method to map mouse offsets to the orthographic planes instead of, in the case of FreeCameraMouseInput, the rotation of the camera. I imagine that I’d want to create a separate class that implements ICameraInput<FreeCamera> so that I don’t have a tightly coupled solution.

I think this is the direction I need to continue pushing in! Let me know if you have any other ideas that are related to this problem.

Thanks again!

1 Like

Thanks for sharing that example!

I’m interested in using an orthographic camera since my use-case is to plot data, so camera position/orientation is less relevant for rendering.

I was able to implement the basic mechanism for my use-case:

I should be good to go! Thanks!