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.
Maybe related to Addition of Camera type that matches 3D applications.
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.
@PirateJC to see how we could help here between doc sample or a new behavior/config ?
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.
Adding @Deltakosh and @PolygonalSun as well as it might be a nice focus area for the next release
Let me know if you want input.
I have opinions and (more importantly) some code written for FreeCamera.
What about doing PRs? If you have code that is worth improving the engine I’m all for adding it
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)
well we do allow that with a very simple line of code:
Customizing Camera Inputs | Babylon.js Documentation
You can also use the UniversalCamera which comes with all the options
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.
I like the ideas
I do not think they will end up in the framework (not directly) but they could definitely extensions as camera behaviors