I think the camera control in babylon is not particularly good. I compared the threejs editor with the babylonjs playground camera. The threejs editor has the following differences in camera control:
No inertia,
Will not reverse the angle of view when passing through the object,
Use the mouse wheel to zoom in on the target, the closer you are to the target, the slower the camera moves.
When using the mouse to drag the camera angle of view, the closer you are to the target, the slower the camera moves.
I know that ArcRotateCamera provides enough parameters to control these, but when I use the Playground, I want to quickly construct an editor scene to show my 3D content, I want to be able to immediately get an editor similar to the blender The camera experience, not in the playground, when I scroll or drag the mouse, the object appears in a weird perspective. And in every example of threejs, the camera control is more comfortable.
Iām not trying to belittle Babylonjs or say that threejs is better. On the whole, I think the functions and documentation in Babylon are more detailed and comprehensive than threejs. But whenever I use this camera, I have an urge to switch my project to threejs.
When I simply show the examples in threejs and babylonjs to my boss and customers, they will not hesitate to choose threejs, because its display effect is better and the camera control is more comfortable. But as a programmer, I would choose babylonjs because the documentation is more comprehensive, and the 3d control functions are more and easier to use.
I know that the input manager is currently rewritten, I will let @PolygonalSun comment on this one (but itās thanks giving week, so be a little more patient than usual).
Presets which explicitly mirror other projects would probably ease adoption.
Camera customization in general is a bit obtuse for any layman just due to all the 3d math and manipulations involved. Iāve found bjs camera customization to be fully robust if a bit apparently scatterbrained in all its default implementations at a glance.
Yes, as my said, bjs camera has enough option to custom a camera control as you want, but this requires enough knowledge and time to research and debug. For those who just want to start babylonjs, they may have used software such as UE, Unity, Maya, Sketup etc before, and these software often have the same camera movement. The camera control behavior is only slightly different in the keycode input. When they open the bjs example and start to understand and learn, the control of this camera will make them very uncomfortable. Bjs just lacks a similar camera behavior that allows beginners to integrate better.
Hey @11123. I think youāre raising a good point here.
As with all software, there is an initial learning curve. I canāt tell you how many times I picked up Blender and abandoned it because I couldnāt get used to right click to select (thank goodness for 2.8+).
On one hand I think that with anything, you eventually get used to how the offered cameras work in Babylon.js. However on the other hand, I totally see your point that it would be nice to have a camera that functions more like in a DCC tool like Blender. I think this is a solid idea to look intoā¦thinking about a few more pre-constructed camera options.
It could also be a good topic for a future video, how to make your own type of camera. Definitely something for us to think about. Thanks for the suggestion!
Thank you for your interest in this topic.
For people who have never used other 3d applications, the camera control of bjs is easier to understand and get started.
Inertial movement and the target crossing the flip angle of view will not make the target disappear in their field of vision, simple mouse input can control the field of view.
But on the other hand, for people who already have a wealth of other 3D experience, this non-mainstream camera control behavior will bring a sense of discomfort. I often use Unity and SketchUp, and occasionally use Blender. When I need to turn to a perspective to view the details of a corner of my 3d target, this is easy to do in these three applications. Of course I need to learn how to control the movement of the camera before. But when I use Bjs, in order to better observe the details, it is uncomfortable to just use the default control of ArcRotateCamera. I have to learn enough mathematics and BJS documents to change the options of ArcRotateCamera achieve some functions.
I simply set some ArcRotateCamera options to mimic the camera behavior in SketchUp, but it is far from the needs of my art colleagues. It does require some patience to debug these things. If possible, I will share or ask more about the details of camera control.
As another end user, I agree with this.
Most of my code contributions to Babylon so far have revolved around camera control.
Iāve used Babylon for 2 personal projects so far and both times iāve been surprised by the lack of camera control functionality.
Iām not trying to pick on Babylon here; Itās a great project.
But camera control is a weak area.
Cameras are something everybody uses. Any improvements here benefit /every/ user of Babylon.
They are also one of the first concepts a new user needs to work out so a simple set of defaults would help catch new users.
A case study:
~2-3 months ago i picked Babylon up again to demo a concept i was playing around with.
Getting the cameras right took as much time as the rest of the demo. By default you have to use a clunky combination of mouse and keyboard to get around a Scene.
I submitted Mouse wheel control for FreeCamera and derivatives. by mrdunk Ā· Pull Request #9056 Ā· BabylonJS/Babylon.js Ā· GitHub which adds MouseWheel support to the FreeCamera and derivatives.
This made my demo and everyone else who uses FreeCamera from now on more usable but there is still very little customization available for other aspects of this camera.
I still wanted other non-standard inputs; An interface not unlike online map programs: Mouse or Touch Screen drags will move the camera over a map, irrespective of the camera angle.
Iāve had to write my own from scratch. I presume everyone has to write their own camera control code at some stage of their project.
For anyone thatās interested, hereās my FreeCamera controll code: flowing-terrain/freeCameraPointersInput.ts at master Ā· mrdunk/flowing-terrain Ā· GitHub
Itās highly configurable; You can make any axis of a pointer device control any axis of the camera.
Iād like to submit it for inclusion in babylon but it still needs work on getting the UI intuitive enough.
ok.
Let me get what i have for FreeCamera into a PR.
Itās functionally very useful but i donāt have a good way of providing the full matrix of options in an understandable UI.
We can discuss taht as part of the PR process.
Iāll but out of this thread now and let other people express opinions.
Hey @dunk, when you put your PR up, can you tag me on it? Iām curious to see what youāve got and Iād like to know more about your perspective on things. I know that thereās some room to improve on camera controls so itād be good to pick your brain about it.
I agree some common way to invoke an at least workable camera for not only mouse and keyboard but also gamepad, touchscreen and (AR/VR) would be nice :]
It feels a but strung together at present. (ofc itās mixed with inputs)
Excellent work. I donāt have much time to learn the babylon source code, but I will try my best to make contributions. My project needs a camera behavior similar to traditional 3d applications.
Excellent work. I donāt have much time to learn the babylon source code, but I will try my best to make contributions. My project needs a camera behavior similar to traditional 3d applications.