|
Mr Margaret Scratcher, Sr. Member
Posted: 12 July 2012 03:16 PM Total Posts: 344
If I have a cube and make it ‘lookat’ a vector, which of its faces will be facing the vector?
Or to put it another way. If I have a 3d arrow,and put it in an objectcontainer3d, and tell the objectContainer3D to look at a vector, what initial direction would the arrow have to be facing in order to look at the vector?
|
mmix7, Newbie
Posted: 12 July 2012 05:18 PM Total Posts: 9
[ # 1 ]
/** * Rotates the 3d object around to face a point defined relative to the local coordinates of the parent <code>ObjectContainer3D</code>. * * @param target The vector defining the point to be looked at * @param upAxis An optional vector used to define the desired up orientation of the 3d object after rotation has occurred */
It’s relative to the mesh’s local coordinates. When you load a cube into 3d world space it has it’s own local coordinates, a transform of (0,0,0). That is then to say that the mesh has a normal-facing direction defined by the modeling program it was made in.
So when you tell your cube/arrow to look at another object(used as a rotation vector ranging -1 to 1 ie. -180 to 180), these coordinates are rotated from that “normal” facing position. So to put it simply, the mesh’s faces that will face the target, are relative to it’s original rotation.
If you are trying to get an arrow to face a target object (to point at it, visually speaking), then you may need to offset the target vector or post-apply rotation to it, depending on how the arrow is positioned in world space originally visually speaking when loaded into scene. Better: just apply rotation to the mesh itself that’s inside the objectContainer3D once it’s loaded, so that .lookAt performed on the container won’t need to be rotated a second time each time you call lookAt. Perhaps it’s already facing a visually-proper direction, and you won’t need to. But i presume that is not the case
|
Richard Olsson, Administrator
Posted: 12 July 2012 06:11 PM Total Posts: 1192
[ # 2 ]
Unless I’m mistaken, the axis that will be aligned to “look at” the target object is the positive Z axis, i.e. the one that normally points into the screen.
|
Mr Margaret Scratcher, Sr. Member
Posted: 13 July 2012 04:12 PM Total Posts: 344
[ # 3 ]
Right, I’m now really confused, in an effort to try to see what’s happening, I decided to try
var zeroVector: Vector3D = new Vector3D(0,0,0); trace (zeroVector); memberContainer.lookAt (zeroVector);
which results in the members (elongated cubes, at present) not being drawn.
Is this a bug?
if I change that vector to anything other than (0,0,0), for example (1,0,0) then the members are drawn, but they are all parallel to each other.
if I change the vector to
var N_Jpos:Vector3D = new Vector3D (N_Jx, N_Jy, N_Jz); memberContainer.lookAt (N_Jposr);
Then all the members face different directions, as expected..
If I keep that the same, but change
N_Jx = 10;
N_Jy = 10;
N_Jz = 10;
Then all the members are parallel again…
I am really confused here, hopefully I’m just doing something silly, usually the case…
|
Richard Olsson, Administrator
Posted: 13 July 2012 04:22 PM Total Posts: 1192
[ # 4 ]
What is your scene set-up? Note that the lookAt target vector should be defined in the “looking” object’s parent space. So if you put your objects in their own containers, and move the containers, using the same vector for all of the cubes will actually have them line up in parallel because they are all looking at that point within their own parent’s space.
The lookAt(0,0,0) issue might be a bug. If you conclude that it probably is, please go ahead and file a bug report on GitHub: http://github.com/away3d/away3d-core-fp11/issues
Thanks
|
Mr Margaret Scratcher, Sr. Member
Posted: 13 July 2012 05:16 PM Total Posts: 344
[ # 5 ]
Not totally sure I totally understand - I’d have thought that if you have a number of objects in various positions, getting them all to lookat the same point would result in them all being rotated differently in order to do so.
Previously my setup was
View.scene ->latticeContainer -> MemberContainers (new one for each mesh->memberMesh
I then tried getting rid of the latticeContainer (I was using it as an easy way of repositioning all of the members) and adding all of the memberContainers straight into view.scene
I’m doing the lookat on the membercontainers.
|
Richard Olsson, Administrator
Posted: 14 July 2012 08:40 AM Total Posts: 1192
[ # 6 ]
Thank you for clarifying. Yes, if all of the objects that you are doing lookAt() on sit directly in the exact same container, executing lookAt() with a common point for all should have them “cross” each other’s “line of vision” to look at that point. They should not be parallel.
Can you paste the full code of a minimal working example where you are seeing the issue?
|
Mr Margaret Scratcher, Sr. Member
Posted: 14 July 2012 03:57 PM Total Posts: 344
[ # 7 ]
Hi there, attached the whole project (flashdevelop), there’s two lines that can be commented around line 468 which will swap whether the individual members all point to the same vector or not. In the mean time, I might try making a simpler example with just some randomly placed cubes and see if I get the same result..
Like I say, it’s most likely something silly I’ve done somewhere, but it’s got me stumped…
Thanks in advance
File Attachments
|
John Brookes, Moderator
Posted: 14 July 2012 04:54 PM Total Posts: 732
[ # 8 ]
Forum doesnt allow rar..annoyingly
There is a bug.
If you do yourMesh.lookAt(yourMesh.position)
LookAt will fail and the mesh disapears.
But you really would never do that.
When you tell an object to lookAt something, your telling it to lookAt a poistion in its loacal space.
Meaning the space that its added to.
If your object is parented and that parent is located at say 0,0,500 and you tell the child to lookAt 0,0,0 it wont be looking at the origin.
It would lookAt where its parent is located (0,0,500).
And if your object doesnt have any offset from its parent it will fail. As your telling it to lookAt itself.
With the above example you would need to tell your object to lookAt 0,0,-500 for it to actualy lookAt the origin.
|
Mr Margaret Scratcher, Sr. Member
Posted: 14 July 2012 10:28 PM Total Posts: 344
[ # 9 ]
Okay, recompressed as a zip…
I understand what you’re saying about lookat being dependent on any offset/rotation of a parent container, but now I have literally eveything added straight into view.scene, with the exception of the mesh which is added to the container that I’m doing the ‘lookat’ on. I tried to use lookat directly on the mesh, but that didn’t seem to do anything…
I pulled the latest version of Away3D from github just to check, but still the same..
File Attachments
|
Richard Olsson, Administrator
Posted: 14 July 2012 10:30 PM Total Posts: 1192
[ # 10 ]
Please provide a simple single-class test case without any dependencies on assets or anything else other than Away3D if you can. That simplifies testing immensely and increases the chance of us being able to look at this any time soon.
|
Mr Margaret Scratcher, Sr. Member
Posted: 14 July 2012 11:57 PM Total Posts: 344
[ # 11 ]
Soooo…. As I went through commenting out all the bits that pulled data from an array, and adjusted it to arrange a number of randomly positioned cubes, I found that I did the ‘lookat’ and then, and then a little while later I positioned them where they needed to be…
Very silly, as I suspected, I won;t be making that mistake again..
Many apologies, but thanks for motivating me to properly dissect my code.
Also can I complement you on how active you are on the forums- it got a bit quiet a while back, I assume as you were hard at work on the new release, but since then you guys have done a great job at making sure all the questions get answered.
TOP WORK!
|
Mr Margaret Scratcher, Sr. Member
Posted: 15 July 2012 01:07 AM Total Posts: 344
[ # 12 ]
Okay, so maybe I will be making that mistake again… BUT THIS IS THE LAST TIME!
Expect a donation for your help on this one..
|