Basic Math Knowledge for Video Games

[Dad72]

I have a little problem with lookAt .I use a plane with a texture and I have a rotation of 3.14 minimum so that the textures display correctly (otherwise she is black). But if I use lookAt so that the plane look the camera, the texture becomes black when I turn around

 

I made:

engine.runRenderLoop(function(){                   scene.render();                  parentCamera.lookAt(cameraFree[0].position, 3.14);            });

[neoRiley]

dad72 -  I could be wrong but I thought that the correction angles were in degrees rather than radians

[Dad72]

 /// <param name="yawCor" type="Number">optional yaw (y-axis) correction in radians</param>

 

This is in radians of what I see

 

[ProfessorF]

Dad72, do you have this example linked to your website so I can take a look?

[Dad72]

I am sorry ProfessorF, all my project is in place on EasyPHP in local. But I am going to try to make an example to reproduce the probleme.

I have point out also that the lookAt does not look from above or downwards with one plane who look at FreeCamera.

I you dispatches an example of problem as soon as I finished

[Dad72]

the link : Teste.zip
 
Thank you ProfessorF

[ProfessorF]

Is it because you only have one directional light?  If you add more lighting sources, it should make the dark part lighter.  Could you try:

 

    var LightDirectional = new BABYLON.DirectionalLight("Sun", new BABYLON.Vector3(-1, -2, -1), scene);

    var LightDirectional1 = new BABYLON.DirectionalLight("Sun", new BABYLON.Vector3(1, -1, 1), scene);

    var LightDirectional2 = new BABYLON.DirectionalLight("Sun", new BABYLON.Vector3(0, -1, 0), scene);

[Dad72]

Yes, it is much better, but in the diagonals of the terrain the textures remains black one moment. But it is a lot better with more light.
Thank you very much for your time ProfessorF.

Otherwise by attaching (with parent) a light point in front of the camera, it could not completely resolve the problem. It is an idea.

[Wingnut]

Hi gang.  Just a quick (off-topic?) comment.  BABYLON.HemisphericLight ROCKS!  It works so good, it lights up scenes on other people's hard drives! 

[Dad72]

Yes but HemisphericLight does not cast shadows.

[Wingnut]

True.  Good point.  neoRiley is working with sun and moon.  Shadows are important.  I should learn to read. 

 

Spotlights do not cast shadows either, as I found out the difficult way, this morning. 

 

I have SO much to learn.  Good luck on your projects, friends.  I enjoy reading about them.

[GameMonetize]

Hemispherics lights are not used by shadowmapping because I would need to use a cube map render target in this case which is way too expensive!

[Wingnut]

Hi friends.  Does anyone (other than me) have an issue with the name 'lookAt'?  I don't really like it.  That is a name for a camera method, imho.

 

FreeCamera has a method named setTarget(), but no .target.  And should IT have an optional yaw, pitch and roll, like mesh.lookAt() ?

 

ArcRotateCamera has a .target, but no method named setTarget().

 

And I recently discovered...  spotlight.direction = BABYLON.Vector3.Normalize(to.subtract(from));  (After a week of studying - yay!  I am starting to understand .direction... finally.  Phew.) 

 

That simple discovery above... is a future setTarget() or lookAt() method... for spotLights, directionalLights, (and maybe hemisphericLights).  Such a method would make teaching .direction in the lighting tutorial... much easier.  And, I think such a method would be super handy.

 

To summarize, should we get consistent and standardized?  Should lights, cameras, and mesh, ALL use .setTarget()?  If so, they would each be different methods, but would have a common name for all.  Maybe?  Thoughts?

 

I would prefer using .setTarget for everything.  Not the same method functionality, just the same names and maybe the same parameters for each scene item type.  Maybe not possible.  Maybe not like other engines.  I am still learning, and will be doing that for 1061 more years. 

 

Thoughts?  Too many questions in one post?  Sorry.  Thanks for comments!  I hope I get some comments.  The forum has been looking like a ghost town, recently.    Come back, everyone!!!  PLEASE!!  I am lonely! 

[neoRiley]

@Wingnut - I can see where you're going with setTarget() rather than lookAt() and I can't say I totally disagree or agree.  However, in every other 3D engine I've worked with, lookAt() has been used to describe a method that points one object on it's forward axis toward the pivot point of another object.  I've used setTarget() as a method for several different types of work and so I think setTarget is a bit too generic.

 

Since lookAt() seems to be widely adopted and used and setTarget() is more generic, I'd suggest staying with lookAt()

[Dad72]

totally agree with neoRiley

[Wingnut]

Yeah, we gathered that you did, d72.  sigh.  Got grounds (logical reasons) for your agreement?  Care to tell us what they are?

 

Anyway, http://tinyurl.com/m8gujw3  ThreeJS, Away3D, Ogre,  Object3D, Cinder... all camera.lookAt().  *shrug*

 

NeoRiley, could you tell me which engines you worked-with... that used mesh.lookAt().  Thanks.

 

It looks like ThreeJS might have a .lookAt() for both meshes and cameras.  And it looks like an engine called Irrlicht... uses a setTarget() on their cameras... like we do here.  http://en.wikipedia.org/wiki/Irrlicht_Engine

[neoRiley]

Papervision3D, Away3D, Sandy3D, Three.js, Babylon.js, Unity3D

 

I was a founding member of Papervision3D and did the first AS3 port and helped design much of the forward facing API.  LookAt is very common as you can see.  To change it would cause more pain than to leave it.

[Wingnut]

Looks like papervision's lookAt() allows a mesh or camera.  Interesting.

 

http://snipplr.com/view/13579/papervision3d--lookat/  .

 

Oh well.  Thanks for the information, NeoRiley.  I guess I'm rowing against the current. 

 

I really have no problems with mesh.lookAt() existing, but I think there should be one on freecams.  I have been working on the basic series camera tutorial.  These 'lookAt' and 'setTarget' and 'lockedTarget' things are kind of important to me, because I need to try to explain how they all work... to old people.

 

Now we have a total of 7 types of cameras in BJS (although some are derivatives of free and arc).  I think I am going to have a nervous breakdown.

 

You type fine English, NR.  Want to help write tutorials?  Currently, the rate of additions to the BJS framework is easily outrunning my abilities to even catch-up, speak nothing of keep-up.

[neoRiley]

If I remember correctly, Three.js and PV3D's camera's and meshes inherit from a base classes like Objec3D/DisplayObject3D, which of course includes lookAt()

[gwenael]

As far as I'm concerned, I would use lookAt to tell the camera to look at the object but NOT to lock it as a target. By this, I mean that if the object moves, the camera won't look at it anymore and at some point we won't see the object anymore. Whereas I would use setTarget to tell the camera to look at the object and lock the target: if the object moves the camera is updated to still look at it.