solved Anaglyph cameras and setTarget()

[entropy]

I'm seeing a dependency on setTarget() and how an anaglyph camera generates parallax for the left/right images. For example,

https://playground.babylonjs.com/#TJTYGR#2

generates an image where the front box looks like it's coming out of the screen and the back box is behind the screen:

Now let's change the setTarget to a different position, but keep everything else the same:

https://playground.babylonjs.com/#TJTYGR#3

Now both boxes appear in front of the screen:

I have a couple of questions with respect to this:

1. Is this the expected behavior?
2. If it is, is there a simple way to point the camera without altering the parallax?

[Wingnut]

Hi entropy, sorry for the slow replies.  I think something is broken, but I just started testing, so not sure.

https://playground.babylonjs.com/#TJTYGR#4

Here, I backed-out the camera a bit, and cosine-animated the target.z values.

Watch console.  When target.z values go negative, scene goes to hell.

https://playground.babylonjs.com/#TJTYGR#5

That's with non-anaglyph... just a UniversalCamera.  It's still acting very strange.

https://playground.babylonjs.com/#TJTYGR#7

There's a free camera, non-anaglyph, backed-out even more (and added ground plane).  Still not looking good. 

I would think... there should not be any up/down movement.  I'm not sweeping any Y values on target v3.

*scratch scratch*  I'll keep thinking and sniffing around.  Calling all forum helpers!    (thx)

[Sebavan]

Sorry for the late reply, I am looking at it now (Thx Wingnutt).

[Sebavan]

It is by design (as the code is looking to be doing ? ) and the camera target seems to define the screen plane.

adding @Deltakosh on this one as I am not that familiar with the anaglyph and i wonder if it is intended.

[Sebavan]

So double check with @Deltakosh All good the target defines the focal point so it works exactly as expected.

[Wingnut]

Thx @Sebavan 

https://playground.babylonjs.com/#TJTYGR#7

That's acting normal?  Anyone know?

See console.   I'm ONLY moving target.z.  Why is the cam moving up/down?

Did I accidentally bend an eyeball, somehow?

Info welcome, thx. 

Perhaps not pertinent to original issue... sorry.  But maybe.

[Sebavan]

Just an optical illusion : https://playground.babylonjs.com/#TJTYGR#8

You can see that looking further or closer on the same plane, it gives the feeling that things are moving around.

[entropy]

Thanks for all the replies. I've done some addition testing and come to the same conclusion as @Sebavan: setTarget() sets the plane of the screen. What was originally confusing to me is I'm using getTarget() of one camera as the input of setTarget() of another camera...something like:

camera2.setTarget(camera1.getTarget());

The problem was that getTarget() always returns a vector that is one unit away from the camera position. This was resetting the screen plane of my anaglyph camera. Now what I scale the target vector like

var v1 = camera1.getTarget();
var v2 = v1.subtract(camera1.position);
v2 = v2.scale(20.0);

before using it to set the target of the second camera. It all works as expected, now!

[Wingnut]

 

@Sebavan - I changed the link in your post... to #8 (it WAS #7 - same URL I reffed).  I think #8 is what you actually wanted to show us.  And it showed me what I needed to know... thx!

But, I probably should have asked... before moderator-editing a URL.  Sorry if I crossed a line, or if it wasn't supposed to be changed to #8.

Meantime...  https://playground.babylonjs.com/#TJTYGR#9

That (#9) is what I was expecting.  But, I had the camera Y = 3, so it was tilting down as the target neared the cam.  My mistake.

Ok, cool, thanks for the help/research, @Sebavan, and thanks for the anaglyph research/tests, @entropy .  A thread that's also a tutorial... love it.

[Sebavan]

Thanks for the link change @Wingnut You did well by changing it I do not mind at all (that s the full power of the community ? )

 

[Wingnut]

11 hours ago, entropy said:

The problem was that getTarget() always returns a vector that is one unit away from the camera position.

Yeah, entropy, I'm not sure, but you may have found a bug in core, there.

Let's say you set scene.activeCamera = cam1.  Then you set cam1.target to some world vec3 point.  Then switch to cam2.

After that, console.log(cam1.getTarget()) is located 1 unit in-front-of cam1.position?  (which I think is default position when creating the cam - before target setting)

I don't know if that's good/right.  Cam1 is not holding-onto it's .getTarget() setting, after it goes inactive?  Or at-all?

Seems wrong.  Tests... watch console.  https://playground.babylonjs.com/#TJTYGR#10  hmm.  Likely, Wingnut mistakes, as usual.  

It seems... SOMEWHERE, I should be able to get a console log of vector3(1,2,3) ... target1.  I don't ever see it.  hmm.

The PROPERTY .target seems to work ok, so far... but get/set targets... seems to be grumpy or maybe used for some other purpose.

Here's a test PG using NO get/set... only .target setting. https://playground.babylonjs.com/#TJTYGR#11   Looks pretty good, as best I can tell. 

[entropy]

3 hours ago, Wingnut said:

The PROPERTY .target seems to work ok, so far... but get/set targets... seems to be grumpy or maybe used for some other purpose.

That might be a more elegant solution. For whatever it's worth, the API documentation states that .getTarget() "Return the current target position of the camera. This value is expressed in local space." Perhaps the "local space" means that it is normalized relative to the camera position. Also, the target property doesn't seem listed in the API documentation...maybe that's why I missed it!

[Wingnut]

32 minutes ago, entropy said:

Also, the target property doesn't seem listed in the API documentation...maybe that's why I missed it! 

Oh that's not good.  That's a Wingnut mistake, then.  There is no .target on uni-cam or its ancestors touch and free.

That means... I over-loaded the universalCamera class.  I accidentally added my own .target property... which BJS will surely completely ignore. 

Ok, don't use .target.  That was a Wingnut mistake.  Good catch, E.  Ya better go back to .lockedTarget, I suppose.

And yes, that local space note... is pertinent.

Now it makes sense that getTarget() and setTarget() don't do anything with a .target property.   heh

I should check the code more often.  Sorry about that.  I'm an idiot. 

I hope you got your issue solved.

[entropy]

14 minutes ago, Wingnut said:

Oh that's not good.  That's a Wingnut mistake, then.  There is no .target on uni-cam or its ancestors touch and free.

That means... I over-loaded the universalCamera class.  I accidentally added my own .target property... which BJS will surely completely ignore. 

Ok, don't use .target.  That was a Wingnut mistake.  Good catch, E.  Ya better go back to .lockedTarget, I suppose.

And yes, that local space note... is pertinent.

Now it makes sense that getTarget() and setTarget() don't do anything with a .target property.   heh

I should check the code more often.  Sorry about that.  I'm an idiot.

Are you sure? I just checked...the target property seems to work in the PG.

[Wingnut]

You mean for https://playground.babylonjs.com/#TJTYGR#12  and similar?

Yeah, it will appear to work fine... for storing a vector 3 that we stuffed into a we-created property on universal camera.

The camera will never use it (automatically) for anything.

Let's see if I can show more...

https://playground.babylonjs.com/#TJTYGR#13

Line 9 reporting undefined.  No such property on universalCamera.

I just forced it to exist, forced a value into it.  The camera isn't using it at all, but it is storing it, for us. 

It stays the same thru camera switches, because... BJS system ignores it and never uses it.  Nothing changes it, except us. 

It's simply a property I created and stored a value into it... I think.  I don't think the camera will use it... ever... at all... until we use .lockedTarget instead.

At least that's how I see it.  But we KNOW how wrong I can be.    We're certainly ALLOWED to make our own camera.target property and put anything we wish... into it.  But... BJS system will likely not use it for anything.  But values set via setTarget()... do SOMETHING important... but likely having NOTHING to do with our "invented" .target property.

With me?   It was a HUGE Wingnut-caused wild-goose-chase I sent us on.  Sorrrrrry.

[entropy]

 

26 minutes ago, Wingnut said:

You mean for https://playground.babylonjs.com/#TJTYGR#12  and similar?

Yeah, it will appear to work fine... for storing a vector 3 that we stuffed into a we-created property on universal camera.

The camera will never use it (automatically) for anything.

Got it...it's more of the way JavaScript works. I'm more used to the way c#/.Net does things, which would have thrown an exception in such cases. My apologies for the ignorance...appreciate the explanation, though!