The Case of Blender and Arc Rotate Camera Export

[gryff]

So with the PG updated,  I can Append now colourful .babylon exports from Blender, I thought I would try exporting the ArcRotate camera from Blender.

I added a constraint to the camera in Blender using the "Track To" option. See images below. I did try the other two options but the resulting .babylon files on export contain this for the camera settings:

"cameras":[],"activeCamera":"Camera",

ie. no camera.

The camera in my scene is set up to look along/across the white plane towards the various objects. The "target" object is the sphere. (Settings for the constraint in lower right corner of second image).

The exported file using "Track To" option contains the following camera settings:

"cameras":[{"name":"Camera","id":"Camera","position":[0,1,-10],"rotation":[0,0,0],"fov":0.8576,"minZ":0.1,"maxZ":100,"speed":1,"inertia":0.9,"checkCollisions":false,
"applyGravity":false,"ellipsoid":[0.2,0.9,0.2],"cameraRigMode":0,"interaxial_distance":0.0637,"type":"ArcRotateCamera",
"alpha":-1.4389,"beta":-1.5708,"radius":10.0876,"lockedTargetId":"Sphere"}],"activeCamera":"Camera",

It specifies an ArcRotateCamera, with data for Alpha, Beta and Radius values - everything looked good

So here is the PG I get: Arc Rotate Camera

Instead of looking along/across the plane - the camera is looking down at the plane. It appears to be an ArcRotate camera as it seems to rotate around the sphere.

If you activate line 14 - everything seems ok. Why do I have to change the "beta" value from -1.5708 to 1.5708 to get what I feel is the desired outcome?

Is/are there some setting(s) in the constraint options that need to be tweaked? I tried a couple but no improvement.

cheers, gryff

[Wingnut]

Hi G!  It's cuz stuff is broken. 

http://www.babylonjs-playground.com/#20D3LG#2

Ok, check that out.  I set beta to -blah... and sent the camera obj to the browser console, where we all clicked on that 'object' to open our object inspector that is built-in to our browser dev tools.  (yay)  The camera object reports .beta of 0.01 (looking straight orthogo-plane) (same symptom as pg #1)

What does this tell us?  That...

"beta":-1.5708

... is unhealthy, and BJS converts that unhealthiness to 0.01.  Maybe that negative value is less-than the camera's .lowerBetaLimit.

Sooo... did ya accidentally flip your Blender camera upside-down or something?  Did you try to use Blender to make raspberry smoothies?  What's that -Z button in the object constraints panel?  Did it get approval from the +Z button... before it activated?  I think you should keep exporting and exporting, using different constraint buttons... and no constraints, and other options too... and see if you can get that negative symbol on the .beta... to go away... and never come back. 

As far as BJS arcCam's go, there is no such thing as a negative beta UNLESS... .allowUpsideDown is set true... and .upperBetaLimit is set null... and .noRotationConstraint is set true... and not even then.  But... the LOWER beta limit?  hmm.  http://www.babylonjs-playground.com/#20D3LG#4

Uh oh, that turned the whole situation on its head, huh?  Now we have a mystery.  Sherlock Holmes, and the Case of the Topsy-Turvy Camera Operator.

And Gryff, as always, there's a 38.3% chance that I have no idea what I am talking about.    Thank goodness you are kind and forgiving.

[gryff]

14 hours ago, Wingnut said:

I think you should keep exporting and exporting, using different constraint buttons

@Wingnut : As I mentioned above I have tried that and have 18 different .babylon files so far  with no expected result.

Interesting that BJS turns the negative beta into a posiitive one - thanks for that demo. 

14 hours ago, Wingnut said:

Sherlock Holmes, and the Case of the Topsy-Turvy Camera Operator.

Love it!! And as for that 38.3% chance - seems way to precise, and vastly over estimated

Maybe I will start from scratch again with a new file.

cheers, gryff

[Wingnut]

Oh man... really... 18, and every one of them produces negative .beta values, no matter what you have tried?  erf!  What the heck?

53 minutes ago, gryff said:

Interesting that BJS turns the negative beta into a positive one - thanks for that demo.

That's because of the .lowerBetaLimit.  It is set to 0.1 by default, and -1.5708 is less than that, so the import uses the default value.  (proper functionality, I think)

So, I notice that your cam is near .beta = -PI/2.  It's nearly parallel to the ground... belly-flopped in the dirt (within Blender).  Have you tried lifting it up a bit?  Probably, eh?

Can you rotate the camera around ITS z-axis? (so a Blender-render from that camera... is upside down)  Then export that way, and see what .beta looks like THEN.

And, what happens when you place the camera on the opposite side of the scene.  Sure, the .alpha will be PI-amount different than before, but I wonder if the .beta will become positive THEN.  hmm.

Just thoughts.  Did you notice "Camera Operator" ... operator having double meaning?  - + / *  (operators)  and negative is topsy-turvy from positive.  Wow, huh?  Accidental.  I'm not smart enough to do that... intentionally.    Gryff, you are definitely fun to work issues-with.  You're quite good with a magnifying glass... snoopin' around in the BJS objects!

Didja get that object inspector to open in the corner of the dev tools area of Firefox? (maybe IE too).  Sometimes ya need to drag the horizontal divider bar upward, making the dev tools area be half-screen high.  There's all sorts of cool knobs and levers in there.  Got it workin'?  Use it much/ever?  It's a virtual magnifying glass.   

Just send ANY object... to console... such as console.log(camera)... then RUN, then click on the word "object" in the console panel.  It SHOULD open the object inspector along the right side of dev tools area (f12).  There, you can scroll up/down through the camera object properties and spy stuff.  Not so elementary, my dear Watson. 

[Nabroski]

@JCPalmer
Hello 

basically i dont care, i work currently on something totally different, i also looked at the source code of the blender exporter 3days agp. I also understand only 2% of all the logic behind it, so this all is just a idea, a theoretical suggestion. Maybe an if else statement for parent objects and childs will help ? It is also a question of performance, if you could create just a mark in the json file - parent.child.xy and let babylonjs recompute the thing, to save download size when too many frames, ect. are provided.

http://blender.stackexchange.com/questions/26108/how-do-i-parent-objects

[Wingnut]

How's it goin', Gryff?  Making any discoveries?  Need medical services? 

[gryff]

5 hours ago, Wingnut said:

How's it goin', Gryff?  Making any discoveries?  Need medical services? 

@Wingnut : Well I started again with a new file - 36 exports using all the "To", "Up" and with/without the "Target Z" checked (see the image above)  ... and nothing different - still a negative beta.

I was getting in need of medical services - I checked each in the Sandbox - hoping the next one would be different. But ...

Then I decided to do something daring - look at @JCPalmer 's code

And I found this in camera.py where he calculates the beta value:

        xApart = 3 if not targetFound else self.position.x - targetMesh.position.x
        yApart = 3 if not targetFound else self.position.y - targetMesh.position.y
        zApart = 3 if not targetFound else self.position.z - targetMesh.position.z

        distance3D = math.sqrt(xApart * xApart + yApart * yApart + zApart * zApart)

        alpha = math.atan2(yApart, xApart);
        beta  = math.atan2(yApart, zApart);

Now I don't know if at this point the axis have been changed (Blender Z becomes BJS Y and vice versa) but if one of the target mesh Z or Y positions are greater than the camera Z or Y then it seems to me the value of beta becomes negative.

So ... a new file and playground:

New File

Scroll out, note the blue cube - the camera position,  and the red sphere - the target. As long as the camera has a greater Y value than the target - it works. The only snag - that is considered the "Back" view in Blender and I always model from the "Front", Right, Left, and sometimes the "Top" view.

So I could try to alter Jeff's code ... or I guess change the beta value from - to + .manually in the .babylon file or through code.

11 hours ago, Nabroski said:

basically i dont care

@Nabroski : Well I have to disagree. If you mean you "don't care" about @JCPalmer 's work on the exporter, I find that sad. as over the last two years Jeff has done some amazing things with it. If you mean you "don't care" about my problem then that is sad too. On this forum, over the last two and a half years I have tried to help people who had problems - none of which were my problems. But my efforts pale when I look  @Wingnut :  he is amazing with his help - tries to help anyone he can, or @Deltakosh and the way he brings the right people to answer questions, or @Luaacro, @NasimiAsl., @Sebavan, @dbawel  and a host of others. Are we just stupid - or don't you believe in the community spirit?

cheers, gryff

 

[Nabroski]

i dont care = i mean don't feel any pressure

import bpy
a = []
for ob in bpy.data.objects[:]: 
    if ob.parent is not None:
        a.append(ob.name)
       
print(a)

was in within the 2years any attempt to convert cycles to hlsl ? 

[dbawel]

@gryff,

I doubt @Nabroski intended on his comment being in any way an insult or to lessen @JCPalmer's amazing work. However, thank you for giving credit where credit is due as @JCPalmer dedicates so much time to writing tols which alow us all to work within external APIs and port them to BJS; as well as to help us all with issues where his expertise really comes through. It's rare to see such dedication to quality when writing for open source and to be concerned about the slightest perforance boost. But he, you, and others  - some of which you listed - truly care about where this journey ends for all of us, and are fighting to ensure the journey will continue for years to come. So again, thanks for giving out the respect.

I just wanted to point out that the last playground scene you posted graphically displays a z-axis up world space in a y axis up babylon world space... which might be confusing for some users - especially newbies. I know I wrote about this in detail on the "Spaces" topic, but I should cover again as it's important to understand why some applications and frameworks are z axis up world space and some are y axis up world space. So I will do my best to seriously look at contributing to the BJS doc site in covering this very important difference. It's about time for me to give back a bit more, as I've been a bit abscent lately.

And in looking at the existing sensors in mobile devices today, as well as what is coming in the near future, it's important to understand why most follow a z axis up world space - which in a nutshell, exists as a model of the Earth's magnetic field in which the z axis on the physical Earth is pointing up in the positive from anyone's position on the Earth's surface. This then must orient the Y and X axis' to cover longitude and latitude. And only in understanding this and why Erath's axis is represented in this manner (which is a Newtonian Physics model as well as the old standard Cartesian model), can anyone know that there is a reason for this and that as developers, we must adapt this orientation for most sensors we work with on mobile and other devices.

However, this is contradictory to more than 50% of 3D and other applications which require the use of cartesian space and represents the world axis as Y up world space - including babylon.js. So if anyone woud benefit from this understanding, or has any more specific questions, I'll be happy to answer as this is the rare experience I have which might assist others - as I certainly don't have the coing chops to compete with mot developers on this forum. So I try and offer what I now is generally unique in my background. And if the forum in general is interested in learning more about both history of this and how it applies to usage today, then I will certainly make such info more easiy searchable and accessible on the doc site - which I promised DK I would look at doing almost 2 years ago now. So if this and some of the basic Linear Algebra algorithms to calculate accelleration, velocity, etc. which are certainly useful in BJS are less known than I assumed, I need to try and contribute more as I often answer questions on orientation and z axis up from Unity, Blender, etc. I just assumed most everyone had this foundation already.

Again, thanks for recognizing some of the invaluable members of this forum, and I wouldn't take @Nabroski's comment in any negative way - at least that's not what I read. I'm sure he'll see this and respond, as well as recognize the dedication and quality work @JCPalmer provides us all. Sometime even I think he's pushing the smallest details a little far... but on this I'm always wrong, as he continues to write and give us amazing tools.

Cheers,

DB

[Wingnut]

Hi guys!  Yeah, the phrase "I don't care" has gained a negative connotation somewhere along the line, hasn't it?  When I saw " i work currently on something totally different", I knew what was meant.  Darn English, eh?  Words and phrases carry baggage with them, and not everyone knows that these "satellites of connotation" are in orbit around these phrases and sayings.  Gryff probably should have asked for a clarification before coming to arms for Team BJS... but it's all good.  Gryff only dusted-off the Team Spirit cannon, and fired a few test shots into the air, and Nabs clarified... and it all resolved.  The "misunderstanding correction system" is still working nicely.  We should all be as proud of that system...as we are of BJS.

Gryff, what do you drive?  Windoze?  Heck, I wouldn't bother with the sandbox.  I'd put a notepad shortcut on the desktop, drop the .babylon files onto it, and look at the camera beta value there.  Of course, the sandbox is a much more beautiful method of checking.  Also, you can use the same playground #series over and over... just change the name of the .babylon file being loaded, test, save, paste URL to campfire gathering (us, here). 

I noticed that your test scenes are getting more pretty each time, too.    Be careful.  That COULD be subterfuge ... trying to steer Holmes off the trail of his cunning adversary.    You might find the orient.jpg image to be handy.  Maybe not.  Seen here.  If we do more testing on those two atan2 lines, you might find that your test .blender file ONLY has the orient.jpg texture on a ground plane (backface culling off), along with an arcCam, a hemiLight with .groundColor gray, and a target of origin/little-box.  *shrug*  Simple test scene, rolls thru the exporter fast. 

That green thing...?   Did a daisy... mate-with a tractor gear... in some romantic junkyard somewhere?  heh.  (Hey, we're allowed to make fun of models, right?)

8 hours ago, gryff said:

The only snag - that is considered the "Back" view in Blender and I always model from the "Front", Right, Left, and sometimes the "Top" view.

Oooookay, that's the closest statement to answering my "What if" questions, so far.  (Such as "What if you put the camera on the opposite side of the scene, in Blender?") 

8 hours ago, gryff said:

alpha = math.atan2(yApart, xApart);
beta = math.atan2(yApart, zApart);

Those two lines are definitely interesting, and could be insufficient to handle the situation.  They might need some if/then helpers.

8 hours ago, gryff said:

As long as the camera has a greater Y value than the target - it works

There... is a fine and interesting deduction, and an answer to my "What if you lift-up the camera a bit?" query.  In my opinion, this is not proper functionality.  The range of .beta +1.57 to +3.14... places the camera below the target.  This also points to a potential insufficiency in those two atan2 code lines.  hmm. 

Sherlock Holmes - behind the scenes.  The Making-of the Blender Exporter Test Suite - Chapter 1 - Bugfind 2. 

What the heck was that stuff, Nabs?  Is that a shader-maker app within Blender?  Bet so.  And you are pondering an exporter to hlsl from that?  Cool!  Probably worth a new thread.

I hope nobody wanted any profound wisdom or jaw-dropping solutions from me... regarding the .beta problem.  I'm just barely awake/alive.  Coffffeeeee.  Neeeed more coffffeeee.

[Nabroski]

yes, a language barrier, thank you  @dbawel @Wingnut

No, new tread on this. i have only 40bucks left on my cash account, so i have to travel a bit though germany doing a Medicine show.

When i get back, who knows, i got some nice ideas on a cycles babylonjs support
 

[JCPalmer]

This thread is too long for me to read all.  I have known about the difficultly about getting python / blender to calculate the right beta to match the scene for a long time.  Switching the sign on beta fixes sometime & breaks it for others.  Alpha seems to be right.  If someone knows the right conditions when to switch sign for beta, let me know.  I did not make that calculation.  Swiped it off a web search, so I do not understand it.

I do not even know what to make of your comments, @Nabroski.  It is almost like a separate conversation.  You are the first to mention 'parent'.  I am doing nothing with the JSON exporter (barring exceptions being thrown) till my own exporter / animation system is done.  As far as animation out of Blender, all my cycles are devoted to skeleton pose libraries & shape keys for my system.  I am not doing any more improvements for BJS's animation system.

The scene JS file & skeleton Pose library JS file generations themselves are done.  The only thing I am contemplating for python is making an option to combine multiple materials.  My effort to downsize textures turned out really well.  If this could be extended to combining textures, draw calls could be reduced since no multi-materials. But, this does not need to be done right now.

[dbawel]

@JCPalmer - If you have a new and/or updated animation / blending tool, I'm really looking forward to keeping up with versioning on this, so that I can follow the "Genesis" of the immense task you are undertaking.  So please post any updates you might have, so that I and others can follow the progress, as well as test and provide any feedback if you request at all. Otherwise, it's simply of great interest to me, and I'm certain will be welcomed by the entire community.

Again, thank you for your past and current work to contribute to the growth and quality of the BJS framework. You deserve the respect you've received - especially for buildig the tools no one else was even considering.

Cheer,

DB

[gryff]

@JCPalmer

17 hours ago, JCPalmer said:

If someone knows the right conditions when to switch sign for beta, let me know.  I did not make that calculation.  Swiped it off a web search, so I do not understand it.

Well Jeff, your code in "camera.py" is :

xApart = 3 if not targetFound else self.position.x - targetMesh.position.x
        yApart = 3 if not targetFound else self.position.y - targetMesh.position.y
        zApart = 3 if not targetFound else self.position.z - targetMesh.position.z

        distance3D = math.sqrt(xApart * xApart + yApart * yApart + zApart * zApart)

        alpha = math.atan2(yApart, xApart);
        beta  = math.atan2(yApart, zApart);
		

        if self.CameraType == FOLLOW_CAM:
            self.followHeight   =  zApart
            self.followDistance = distance3D
            self.followRotation =  90 + (alpha * 180 / math.pi)

        elif self.CameraType == self.CameraType == ARC_ROTATE_CAM:
            self.arcRotAlpha  = alpha
            self.arcRotBeta   = beta
            self.arcRotRadius = distance3D

If I change the line :

self.arcRotBeta   = beta

to:

self.arcRotBeta   = abs(beta)

it seems to work no matter where I place the camera and target.

But I don't claim to be much of a programmer in javascript, let alone the dark mysteries of python

cheers, gryff

[Wingnut]

@JCPalmer... would you remember where you saw a use-case that went broken... when disallowing negative .beta values?

No big deal.  I can order Gryff through a gauntlet of demented test cases.  He's my puppet.  heh  (j/k, of course)

Gryff... are negative beta values allowed on that camera... as far as Blender is concerned?  CAN a user set a negative beta value... IF they DID want an upside-down arcCam?

This might be the "breaks it for others" that Jc mentioned.  If Blender allows an upside-down camera (via using a -.beta value), then BJS should do so, too.  But now... we got trouble... right here in River City.  We'd need: if neg beta, then null BJS upper/lower beta limits, set cam allowUpsideDown = true, ... you know... try to duplicate the Blender-render.  (Thx for being my Blender question answerer, Gryff)

[gryff]

9 minutes ago, Wingnut said:

I can order Gryff through a gauntlet of demented test cases.

Only case where the above code change has broken is when I look directly down the X-axis. It returns a value of beta = 0 . A slight movement off that X-axis and it works again.

But I will try some more tests.

cheers, gryff

[JCPalmer]

Ah, not allowing negative via abs, good idea.  I was putting a ' * -1' on the beta calculation. I looked at my scene where doing that failed.  Beta is already positive, so I just made it negative.  I simply ran out of time working on this.  No one reported it as a problem, so I just ripped the ' * -1' back out.

5.0.4 incoming

[gryff]

@JCPalmer : I've run some more tests and the only failure I have had is when I look directly down the X-axis (either from -ve to +ve, or vice versa.) So essentially when the y value (= 0 in Blender) for the target and the camera are the same

I tried above and below as @Wingnut asked - works except when looking along that X axis.

Will run a few more tests.

cheers, gryff

 

[Wingnut]

Something smells fishy, yet.  Quick review... in BJS, arc cam beta is 0 when camera is over north pole, looking straight down (toward origin/target)..  beta is +1.57xx when cam is over equator, looking toward origin, and +3.14 when directly under south pole, looking up (toward origin). 

Gryff, when you change the beta for Blender arc-cam... from 0... to +3.14, does the camera move from north pole looking down, to over-equator looking sideways, to south pole looking up? 

I don't know if you can "spin" beta values through a range like that, in cam properties, in Blender.  Just curious. 

It almost feels like we have a 90 degree rotational transform to do.  Maybe Blender thinks beta should range from -1.57 to +1.57... but bjs wants 0 to +3.14. Thoughts?  Should I shut up?  Not sure.