Hi everyone, I’m exporting a Blender scene with just some lights and a camera in .babylon format. Since I want to rotate/zoom/pan the camera, I’ve set the CameraType to “Arc Rotate”, and added the target object with “Track To” constraint.
However, when I load the whole scene - using SceneLoader.Load() - the camera doesn’t allow panning, I can only rotate and zoom. If I create the camera via code, it works fine, but my intent was to try to export it from Blender.
How can I enable the panning to the imported camera?
Because the arcRotateCamera revolves around a center target, panning the arcRotateCamera is equivalent to moving that target. In the env-camera.babylon file, you have this item that is locking the target of the arcRotateCamera to something called “Empty.” This means that it does not allow the canvas control to change the target and therefore does not allow it to pan.
I’m not sure where this comes from, perhaps it’s related to this comment:
But that’s the culprit. If you remove this item from the .babylon file, it works just fine. So it looks like the export/import is working correctly, but you’ve added some type of constraint in Blender that’s adding this target lock.
adding @JCPalmer for visibility and to make sure I’m interpreting this all correctly.
JC, if this is the case, then it seems that there has been a change to the loader. You do have a choice which object in your scene is to be arched around (Panning is a real deceptive term for an archrotate camera, use rotate or arched). I was using a track to constraint in Blender to tell which one, like so:
@JCPalmer - Just checked with the team, not changes to the loader at all. Doesn’t this indicate that it’s working by design though? If you give it a target lock, then you’re essentially saying that you want the arcRotateCamera to lock it’s target to that object right? In other words, if you put the constraint in, isn’t the exporter and loader respecting it the way that it’s supposed to?
If you constrain to get the camera oriented correctly, then remove the constraint (in Blender), then it will unlock panning because it won’t export a target lock correct?
Ok, I ran one of my old scenes exported last in 03/2018. It still ran and rotated. Compared JSON files. CameraType is set to UniversalCamera in the new file not ArcRotateCamera.
Something probably happened in the Blender 2.80, exporter version 6.0. It was practically a rewrite, because Blender changed so much from 2.79 to 2.80. I’ll look into it this week.
By removing that line I can correctly pan the camera. That line I think comes from the TrackTo constraint (I read about it here Blender Tips - Babylon.js Documentation). But, if I try to export the camera - set as ArcRotate - without that constraint, the resulting babylon file is unusable - in fact the “camera” array is empty:
"cameras":[],"activeCameraID":"Camera"
and get this warning:
WARNING: Camera type with mandatory target specified, but no target to track set. Ignored
So the situation is: if I use the constraint, I can’t pan the camera, but if I don’t, the resulting file is wrong (missing camera). Or am I missing something?
I mis-diagnosed the problem. I re-did my little scene shown in the above picture, because I never saved the .blend. The exporter this time did write ArcRotateCamera, and the cube rotated & zoomed. Must have screwed it up first time.
I checked the ops zip file, the .babylon look as I expected. Double clicked the html file, in Firefox, with an option allowing local texture files to load with file: url. It runs, and rotates & zooms.
So I went back to the original post, the op says
I assume by panning this meant off centering left, right, up, and /or down using the arrow keys. I did not know an arc rotate camera did that. I tried taking out the lock target, but still no pan, just rotate /zoom.
Checking the file index.js. There was a commented out way to create the camera. It did not work when I made the line live, but they are:
// camera created via code works
var cameraCoords = newScene.getMeshByName('ROOT_Camera').position;
var camera = new BABYLON.ArcRotateCamera("MainCamera", 0, 0, 11, BABYLON.Vector3.Zero(), newScene);
camera.setPosition(new BABYLON.Vector3(cameraCoords.x, cameraCoords.y, cameraCoords.z));
camera.attachControl(canvas, true);
I wonder if FileLoader way, just directly assigned position, and using setPosition() did something to turn it on. I put in the following line, and the mesh initially appeared much smaller, but no panning.
By reading the messages, I notice I made a (big) mistake. As JCPalmer said, by panning I mean the possibility of centering left/right/up/down the view (you may think you are moving the object up/down/left/right on the screen) with right mouse button (not arrow keys, which let you rotate around the target). I’m sorry for that! In the PG you shared you can do that (I just added a light).
Therefore what I mean is:
when I create the camera via code, I can move the view with RMB (below the code, similar to your PG):
// camera created via code
var camera = new BABYLON.ArcRotateCamera("MainCamera", 0, 0, 11, BABYLON.Vector3.Zero(), newScene);
camera.setPosition(new BABYLON.Vector3(10, 10, 10));
camera.attachControl(canvas, true);
when I set the camera in Blender I can’t move the center of the view (if I click RMB the view is frozen, I can only rotate and zoom):
// enable the camera inside babylon file
var camera = newScene.getCameraByName("Camera");
newScene.activeCamera = camera;
camera.attachControl(canvas, true);
In this new zip there are 2 projects: camera-babylon (camera created via code), and camera-trackto (camera exported from Blender). Just to show you the difference between the two.
In conclusion, my question is why I can’t move the view when I export the camera from Blender. I expected the same behavior as when the camera is created via code.
If lockedTargetId is changed to Target it “pans”. Spent too much time on this topic. None left for me to change exporter right now. Edit your small .babylon for now.
BTW, this is not moving the camera. You are moving the target mesh. As soon as you have more than one mesh in the scene it is obvious. Did not have time to get a .babylon with more than one mesh, but tried it on one of mine.
