JLHolmes

Thanks Wayne.!

So I'll answer my own question in case someone else hits this. Somewhere in the code, I had used MeshBuilder.CreateSphere(), but I had admitted the last parameter... the scene. It still worked, however... been working for months... UNLESS you happen to re-init the engine without refreshing the page from scratch.

Hey guys... need some help here, I'm getting this error: babylon.js?98a3:20 Uncaught TypeError: Cannot read property 'globalPosition' of null at Function.t.BindEyePosition (babylon.js?98a3:20) Now... I only get this error after I've reinitialized the engine a second time on a whole new canvas, while previously shutting down the old instance with engine.dispose(). The scenario that inits the scene is complex enough... and part of another project... so creating a playground would be difficult. (The playground seems to rebuild the whole dom and init anyways). This appears to be coming from the MaterialHelper class, and the activeCamera variable appears to be null... not sure why, though. Any leads on what this might be before I start digging?

Thanks, Wing... I went ahead and a fell back (ahead? back?) to my old method. I'm assuming the lack of the picked point is an optimization thing. The other advantage to scene.pick() is that you can tell when the user doesn't click on something.

Hey guys... while refactoring some code, I ran off down the path of changing my old picking method (Raycasting, etc) to use actions... specifically OnPickTrigger with ExecuteCodeAction. But... I was a bit confused when I could not find the picked point on the mesh in the event data. Am I missing something?

Yep... tried that. It doesn't matter how far out I set the radius. The camera is still locked in place. I'm trying to simply the scene to get at it more.

I'm trying to repo it in the playground... it does not seem to happen in simple scenes... only when there's an object much larger than the camera's radius. How do I determine what type of collision is being used? Well... since I have not done anything special to pull in collision I assume I'm using native.

Hey guys... it's been a while, but things have been going pretty smooth with BJS. That is, until I upgraded to 3.0. My scene just up an disappeared! Digging into it, I found that it was when I set checkCollisions to true, the scene for that camera would just lock up the camera.... unable to move it at all. So.... sceneState.camera = new BABYLON.ArcRotateCamera("ArcRotateCamera", 0, 0.8, 1000, new BABYLON.Vector3(0,0,0), sceneState.scene); sceneState.camera.speed = 5; sceneState.camera.checkCollisions = true; sceneState.camera.ellipsoid = new BABYLON.Vector3(2, 5, 2); sceneState.camera.upperBetaLimit = Math.PI/2; sceneState.camera.wheelPrecision = .1; sceneState.camera.lowerRadiusLimit = sceneState.togScene.gridSize * 2; Fails... but... sceneState.camera = new BABYLON.ArcRotateCamera("ArcRotateCamera", 0, 0.8, 1000, new BABYLON.Vector3(0,0,0), sceneState.scene); sceneState.camera.speed = 5; sceneState.camera.upperBetaLimit = Math.PI/2; sceneState.camera.wheelPrecision = .1; sceneState.camera.lowerRadiusLimit = sceneState.togScene.gridSize * 2; ... is just fine. Thoughts? Did I miss some other setting or change with regard to moving to 3.0? (Actually, v3.1-alpha)

@Wingnut Yep... when bugs just "go away" I get nervous, too. I was not nearly as exhaustive as your suggestions. It's really easy to reproduce... revert to 2.5... voila... problem is back on any touch device (but not desktop), problem goes away with 3.0.0-alpha. I have not dug into why, however... and have not tested how stable it is. It a couple weeks, our project goes out for a round of concept testing across a wide range of devices... so I may end up diving back into it.

Hey there guys... I wanted to update this thread with my testing results. So... I was completely unable to nail down this behavior... it was working differently based on various touch devices. Then I decided to reconstruct the problem in the Playground... and I found I could not reproduce it. So after days of narrowing down my code vs. Playground differences, still with no luck, I did find one difference. I noticed that the playground was using BJS 3.0 alpha. So, I switched my code to 3.0 alpha, and bam... the problems went away. Not only that, I was having a POINTERTAP vs POINTERDOUBLETAP issue... and that went away, too. @Deltakosh, @Wingnut... did I just stumble across a fix?

Hi there... one quick way to do this is using observables... like so: scene.onPointerObservable.add (function(evt) { var pi = evt.pickInfo; },BABYLON.PointerEventTypes.POINTERDOWN); The pickInfo of the event contains a lot of information about the event (PickInfo) You could also use scene.pick(), which takes X,Y coords you can grab from a standard mousedown event from addEventListener.

Thanks @adam, I'm working with it... my quick attempts haven't been unable to reproduce the issue so far. In the real case, the problem is occurring several layers into a React.js application, so there may be some shenanigans in react that are causing me to make assumptions. I'll keep you guys updated.

Hmmm... well... @Deltakosh, the playground doesn't seem to give you control over the HTML layout into which the BJS scene would be rendered... unless there's some trick I don't know about. This situation arises when the canvas is being tucked into a small area of the web page. I'm pretty well convinced that the problem arises when the canvas width and height properties are different than the actual canvas size... which seems to occur in flex box models because the element "flexes" in response to the content, which seems to be after BJS has made some decisions about the canvas dimensions. I've tried explicitly setting the width and height properties, using engine.setSize(), but it was still off. I'm going to try @Wingnut's lead on establishing width and height properties before I even setup BJS on the canvas and see where I get. On an ironic note, we got feedback results today from testers over the week... and no one seems to like having the canvas area restricted, so there's a push now to just let BJS have the entire window and lay the interface over it (which make our web designer twitchy ). That would make the issue moot for one of our projects, but still outstanding in another where we show product details in 3D in a small outset.

Ok... forgive me for talking to myself in this forum... but maybe I'm on the road to the source of the problem. I notice that in all the playground examples the width and height attributes exactly match the actual size of the canvas. So... I am doing something to short circuit BJS's ability to get that correct, perhaps?

Ok... so here's an update... and it may speak more towards a fundamental lack of understanding of what BJS is doing with the canvas. I realized there's one fundamental difference all the examples, including @Wingnut's, and our application. Our implementation of BJS is not fullscreen, rather it's constrained to a box which floats around and resizes itself according to flex-box rules. There are certain cases, depending on screen size/orientation, when the offset occurs. I can take an ordinary BJS scene that's rendering correctly, change my screen size (like with Chrome device toggle), and then we're in bad territory... even when I refresh rather than allow things to just "move around." It could possibly be that I need to detect when "things move" and then do an engine resize()? I keep noticing that the width and height attributes that BJS forced onto the canvas are always slightly different than the actual canvas size. Not sure what that signifies... but I did observe that the more those numbers stray for the actual canvas size... the more pronounced the error is.