Camera options coming from Blender

[JCPalmer]

Deltatosh,

You are probably going to be only the person able to answer this.  This started, because I am trying to debug my normals calculation for shapekeys.  The bumps.blend, which I renamed multi_group.blend, really has to be viewed from multiple angles to really understand the structures.  (Not complaining, it is a very good test).

 

Thought, I could just define an arc camera after I get it up in BJS.  Next thought was: I already have a Follow Camera check box in TOB ( changes to babylonFileLoader too).  Why not make it a drop down with as many Cameras as doable.

 

Never knew there were so many cameras when I expanded the Cameras dir.  Obviously, Camera & TargetCamera are meant only for sub-classing.  The others I am not familiar with beyond what their name suggests.  Some of them have extra constructor args, without defaults.  Please comment on each that follow:

 

ArcRotateCamera:

        constructor(name: string, public alpha: number, public beta: number, public radius: number, public target: any, scene: Scene)

        - can get target the same way as for FreeCamera & FollowCamera.

        - alpha, beta, radius could be custom properties, but not sure good defaults

 

AnaglyphArcRotateCamera:

        constructor(name: string, alpha: number, beta: number, radius: number, target, eyeSpace: number, scene)

        - same as above for ArcRotateCamera

        - eyeSpace ?  stereo vision?  Why does OculusCamera not sub-class AnaglyphArcRotateCamera?
 

DeviceOrientationCamera:

        constructor(name: string, position: Vector3, scene: Scene)

        - args same as FreeCamera

        -  Could this be to build an accelerometer based camera?

 

GamepadCamera:

        constructor(name: string, position: Vector3, scene: Scene)

        - args same as FreeCamera

 

OculusCamera:

        constructor(name: string, position: Vector3, scene: Scene)

        - args same as FreeCamera

 

TouchCamera:

        constructor(name: string, position: Vector3, scene: Scene)

        - args same as FreeCamera

        -  pointer follower camera?

 

VirtualJoysticksCamera:

        constructor(name: string, position: Vector3, scene: Scene)

        - args same as FreeCamera

       - understand, except for the virtual part

 

Also, what is probably the best camera to go anywhere, ArcRotateCamera or TouchCamera?

[JCPalmer]

Well,  implemented "something" in a new 1.1 version.  Tried the Arc Rotate Camera, and it worked.  Really helped my shapekey development (normals still suck though).  Do not know what are good defaults for custom properties.  See picture for what I picked.

 

Figured out why Oculus not sub-class of AnaglyphArcRotateCamera:  Oculus has no target.  Common ancestor at best.

 

Still questions from first:

- Could DeviceOrientationCamera be to build an accelerometer based camera? or Maybe VirtualJoysticksCamera?

- What are VirtualJoysticks?

 

- What is probably the best camera to go anywhere, ArcRotateCamera or TouchCamera?  Probably will have the answer to this before anyone reads this.

[JCPalmer]

A thought came over me that there might be an issue with implementing more than just Free & Follow cameras:  I might have to alter the order of the objects types loaded in babylonFileLoader.load() in order to support them in a .babylon file.  FYI, the order of load() forces it to stash stuff in "_waiting" variables, one being _waitingLockedTargetId, because cameras are loaded before Meshes.  This is ok for FreeCamera & FollowCamera, but the Arc cameras need the target in the constructor.

 

Not sure that will go over well, and I do not want to be the one to do it.  The initScene() generated in a .js / .ts from TOB has a different order than load(), which does not have this problem, although babylonFileLoader.load() imports more than can be exported by Blender.

 

Bottom line is:  I am not willing to put out a TOB that limits camera types by the output type. This actually coming out is in question.

[GameMonetize]

As far as I'm concerned the most usable camera is the arcrotate because it works with mouse, touch and pencil.

 

regarding loading order, the arcrotate camera can be initialized with a dummy target and be pointed out to the real one right after 

 

Other questions:

 Could DeviceOrientationCamera be to build an accelerometer based camera? or Maybe VirtualJoysticksCamera? Don't get this one. DeviceOrientationCamera uses accelerometer data throught device orientation API

- What are VirtualJoysticks? They are the tools used by VirtualJoysticksCamera (the small circles drawn on top of the canvas to represent your thumb's position)

[JCPalmer]

Ah, target is public.  Using first post as notes, did not go back to source.  Will implement this then.

 

Switching with various cameras, I found arcrotate best too.  Reluctant to make it default though, since would be a change in behaviour.

 

I guess DeviceOrientationCamera might all set out of the box.  Was thinking about the need for more than just a portrait / landscape detection.  I remember an old Android game, where you try to roll a ball bearing through a course with holes to fall through by tilting back/forth/up/down.

[GameMonetize]

DeviceOrientationCamera should take care of everything

[JCPalmer]

Wondering if any of the arc camera properties could be derived using the relation of the camera to the target instead of using UI?  Maybe the radius could be the distance from between, if there is a python function in mathutils to get the distance between 2 3d points.

 

No clue what the alpha & beta are.  Any suggestions?

[Temechon]

Hey, 

 

I think this image can help you : https://camo.githubusercontent.com/7042b97d4eb18b92b1970d475543d27de1b75aba/687474703a2f2f757262616e70726f64756374696f6e732e636f6d2f77696e67792f626162796c6f6e2f6d6973632f61726330312e6a7067

 

From this article : https://github.com/BabylonJS/Babylon.js/wiki/05-Cameras

[JCPalmer]

Temechon,  Thanks.  I also just wrote my own function to do 3D distance in python:

def get_distance_between(vertA, vertB):    xd = vertA.x - vertB.x     yd = vertA.y - vertB.y    zd = vertA.z - vertB.z    return math.sqrt(xd * xd + yd * yd + zd * zd)

Can probably derive all the follow camera stuff too.  This is on the back burner though.  Shapekeys / Automatons is very close to being production worthy, and TOB 1.0.1 supports it already.  I also want to make that commit as small / drama free as possible.  Plan on doing this stuff after that & before working on CocoonJS.

 

This means that initially, Automatons cannot be done with a .babylon.  Have already modified FileLoader for Automatons, but there are mods committed to the repository I do not have as I am working on a fork.  Not sure what to do about it, but just more reason to multi-stage the release.

[JCPalmer]

Trying to put in a dummy target got just too clunky.  First, _waitingLockedTargetId was not at the Camera level like _waitingParentId, so I had to move it from TargetCamera.  I found that I had to actually had to make a dummy Mesh, not just null, because code gets called in the constructor that requires it to exist.

Looked at BabylonFileloader.load().  If thought from the perspective that it is just moving Cameras down past materials, multi-materials, skeletons, geometries, and mesh, is not the same as moving Meshes up before Cameras.  None of that stuff needs cameras.  Tried it & it works so far.

Deleted both _waiting vars.  In process of doing more tests, but it is much cleaner.