Basically normally with an ArcRotateCamera like the one I have, clicking and dragging the mouse will rotate the view around the model.
When the problematic issue happens, suddenly clicking+dragging will zoom in and out of the scene, instead of rotating around the model, it will just zoom in and out, and the only way I find to reset it to the normal behaviour is to reload the entire app
These issues are definitely related to the use of:
which I need to use to stop temporarily this default behaviour of click+drag so that user can draw over the model using click+drag
I have tried to use an alternative by making use of:
camera.angularSensibilityX = Infinity;
camera.angularSensibilityY = Infinity;
which you suggested, but it seems to hurt performance
sorry I cannot create a playground because of the rest of complexity in the app, if this new description suggests any new clues let me know thank you
@MarkBevels @mawa @PirateJC
actually I found out that this problem that I have happens not only in the case I described above, sometimes it also happens right after I load a model, nothing related to what I described before, but the issue is the same,with the arcrotatecamera, in which the click+drag behaviour on laptop, instead of rotating around model, only zooms in and out, and the only way to solve it is to restart the whole thing; again I cannot identify an scenario to build a playground, but seeing this now happen in different places sounds like there is definitely something there… will report if i find anything else about it
is the click+drag behavior for zoom in-out one of your input for another camera or viewport, or you haven’t set anything alike? How many cameras/viewports do you have in the scene? I personally hate it when I bounce into this random type of error that may or may not occur. May be there are just multiple causes. Hope someone will be able to give us a light…
here is a simple playground where you can click a button to detach and re-attach the camera https://playground.babylonjs.com/#XCPP9Y#5432
Perhaps you can build this into something more like your project to show the problem.
Perhaps they might help
and John, what surprised me is that this zoom in-out instead of rotate behaviour of the arcrotatecamera has happened as well outside of the attach/unattach moment, very odd, and once it kicks in, once it happens once, there is no way to reset it unless I reload the whole thing;
thank you very much for creating that playground; if i see a possibility to build it towards my scenario I will do it but at the moment it doesn’t make sense as my app is just too large and complex to reduce it to a few lines,
I keep investigating, thank you again
Yeah, well GL. I’m just happy this one is not mine I suppose you tried a variety of browsers (not just Chrome). I suppose you tried simplify by removing *[pointers] and simply attach and detach controls to check if any different…
@mawa yeah, I tried a few things, will try more, by the way I am only interested in making this work in chrome and ios safari, dont care about the other browsers, so far only tested in chrome, will test safari as soon as I can, but in theory it should all be compatible between both right?
I guess at this point, you should check Safari or any other browser, just to make sure. I had some bad experiences with the updates of Google’s policy and sudden (or announced but disregarded;) changes in the handling of behaviors (and some other stuff too… I guess what you will want now is try eliminate 1 by 1 all the possible causes…
or could it be anyhow related to this recent topic:
Just bounced into this and thought, may be…
@mawa making new tests it seems clear that the problem is related to this
I have to try all the alternatives to those, I already tried the camera sensitivity to 1000 but that hurts performance, what other ways do i have to stop the click+drag rotation behaviour of the arcrotatecamera and reenable it later?
and now, so far, seems that problem doesnt happen!
now explain me why this change helps
@MarkBevels @mawa @PirateJC
so yes, I have been unable to find the problem again since I made that change:
instead of camera.inputs.attached[‘pointers’].attachControl(canvas);
instead of camera.inputs.attached[‘pointers’].detachControl(canvas);
my theory is that I am also in my app doing:
canvas.addEventListener(“pointermove”, onPointerMove, false);
canvas.addEventListener(“pointerdown”, onPointerDown, false);
canvas.addEventListener(“pointerup”, onPointerUp, false);
and maybe there was a collision between both things regarding ‘pointers’
its still odd because I assume that the generic simpler “camera.attachControl(canvas);” also must include the pointers and all, but in any case, it seems to solve the problem
if you have an explanation for why this seems to be a solution let me know, I would be curious
I’m not sure to follow here. Did it work (differently) or not?
I believe there is an explanation for it to work differently. There’s a default handling for pointers. I believe the default is also a safer option if there is not a necessity to change it.
What i mean is that the problem has dissappeared and it does not happen again after switching those statements to the simpler ones:
using those simpler ones, the problem dissapears (at least so far I have not seen it again)
I’m happy to hear that I got this as your last post
So I thought may be you realized only later that it was not working (or incomplete) - I do this sometimes. I quickly check, I think it’s all good and later on I realize it is not;)
In fact, I’m having one of these with SSAO and multicam just right now:(
I will also shortly post about it.
Edit: I believe I also self-translated ‘unable to find the problem’ to ‘unable to find the solution’. Isn’t it so that on these kind of topics where you think you loose your head, when you finally find the solution and then, the solution is so simple, you nearly cannot believe it really is solved
@mawa yes you are right mawa I was expecting that it would be massively complicated to solve the issue, so I couldn’t believe that just switching those statements apparently made it go away
on the other hand, as a software engineer myself I have seen sooooooo many weird bugs and murphy law madness over the years that nothing surprises me so much anymore in that sense, everything is possible when we deal with a mixture of libraries, frameworks, environments etc, wild west
Ya know, this is why I simply luv the philosophy, method and skills of the ENGs here in BJS. This framework is solid and well thought.
@mawa absolutely I have to tell you, I have used a lot of frameworks over the years but I really love babylon.js, first of all the community and forum is the best I have ever seen, the documentation is fantastic, the playground, sandbox etc all these tools are fabulous, and the framework itself of course is really great; when I had to take my choice I did research and read a lot of good things about babylon.js vs three.js and other options and I am so happy that I chose babylon.js finally!
I’m glad you agree with me on that. I have also seen many frameworks in my career, though I mostly hand over the true dev parts to the true ENGs, like you. It could have been you
… but then, I don’t think we need to choose between BJS or three.js. (or oppose them). We have only two for webGL*+. I think there should be enough space for both. But then yes, personally, BJS is clearly my favorite - for all of the reasons you mentioned above.
@mawa you are totally right that we don’t need to oppose them etc, however at the end of the day one has to pick one of them to start coding so unfortunately in life choices are inevitable I guess but yes I agree that there is space for not only both of them but more as well, as you say there are very few choices at the moment and competition as we know is very good and makes the whole area grow in any field yeah