entropy

Members
  • Content Count

    27
  • Joined

  • Last visited

About entropy

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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!
  2. Are you sure? I just checked...the target property seems to work in the PG.
  3. 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!
  4. 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!
  5. 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: Is this the expected behavior? If it is, is there a simple way to point the camera without altering the parallax?
  6. Yes, I think those changes were made, in part, due to bug reports I filed here: I wanted to make sure that this latest issue I was seeing was not due to a misunderstanding on my part before bothering Deltakosh! Edit: I should also mention that I tried to look at the source code to find where any changes in perspective might arise. I can't seem to find any difference in the rigging between the different cameras (but I'm very much a novice in TS/JS, and its hard to find all the possible locations in the code where it might be set).
  7. Thanks for the replies so far. This leads me to another point of confusion: if we play the same game using the UniversalCamera (switching between the regular and anaglyph versions), there is no change in perspective. In the following PG, you can switch between them on lines 5 and 6: https://playground.babylonjs.com/#TJTYGR#1 Overall, UniversalCamera, AnaglyphUniversalCamera, and ArcRotateCamera all render the scene from the same perspective (all other things being equal)--only AnaglyphArcRotateCamera is different. The main reason I created this topic is that I'm seeing rendering differences between AnaglyphUniversalCamera and AnaglyphArcRotateCamera, so I'm trying to decide if the difference stated above is a feature or a bug. I was trying to create a scene where I can switch between AnaglyphUniversalCamera and AnaglyphArcRotateCamera to study the rendering differences in greater detail, but noticed this change in perspective when placing them in the same position.
  8. I'm confused about what, exactly, the position of a camera means. It seems like this would be straightforward, but I'm seeing strange results when I switch between camera types. Here's a playground that illustrates: https://playground.babylonjs.com/#TJTYGR In the above PG, line 5 creates the camera (in this case, an AnaglyphArcRotateCamera). I confirm that it is set to the proper position and target by logging those parameters in the console. So far, so good. Now, switch to the regular ArcRotateCamera (comment out line 5, uncomment line 6). The same position, target, radius, etc., produces a different point of view--the camera is placed closer to the boxes. The console log confirms all of the camera parameters are the same. Is there some reason for this behavior?
  9. I came across a couple of strange behaviors with different properties of anaglyph cameras. The first one involves AnaglyphUniversalCamera: its rotationQuaternion can't be animated. To illustrate, check out the PG demo below. The default code uses the regular Universal camera, but you can switch to the anaglyph version via lines 7 and 8. In either case, animations of position and rotation are applied to the active camera. Note that the regular camera animates its position and orientation (as intended), but the anaglyph version only translates. https://playground.babylonjs.com/indexStable.html#WR9PXQ The second issue involves how the interaxialDistance (iD) setting affects the rendering of the scene. The behavior of this property is different between AnaglyphUniversalCamera (AUC) and AnaglyphArcRotateCamera (AARC). Here's how I'd describe it: Positive iD with AARC: It's hard for my eyes to interpret the scene...I think closer objects are rendered *behind* farther objects (in a depth perception sense). Negative iD with AARC: Everything looks fine. Close objects project forward into the space between my eyes and the screen, while distant objects appear behind the scene. Positive iD with AUC: It looks okay, except objects only appear behind the screen and never in front of it no matter how close they are to the camera. Negative iD with AUC : It looks like the entire scene is compressed into the space in front of the screen...again it's hard to interpret visually. My preferred rendering is a negative iD with AARC since objects appear correctly both in front of and behind the screen. Regardless, the iD behavior between the cameras is inconsistent. You can try playing with the sign of iD and switch between the two types of anaglyph cameras in the following PG: https://www.babylonjs-playground.com/#CURCZC#11
  10. @jerome Here's the solution that I employed. Instead of using transformNode, I just used BoundingInfo and directly set its world matrix. Fortunately, the Matrix class has all the functionality needed to generate the necessary information. Here's the PG: https://playground.babylonjs.com/#C7K3Q1#1 Lines 60 through 62 contain the relevant new code. Everything works great...thanks for the help!
  11. I think the main problem is that you had an emissive color turned way up (this was overpowering the lighting effects) and you needed to adjust the positioning and falloff of the spotlight: https://playground.babylonjs.com/#SJYUM3#2
  12. @jerome One (hopefully quick) question. I think the transform node method is the most promising, but I can't seem to associate a bounding box to a node. E.g., look at lines 33 and following: https://playground.babylonjs.com/#FL6VBL#1 Could you elaborate a bit how to make that association?
  13. Those are some excellent suggestions. I didn't even consider the physics engine approach! I'm slowly but surely learning...
  14. @logunov As I mentioned, I'm a novice when it comes to Babylon.js. In another thread I learned about transform nodes from user Jerome. They can be used to define centers of rotation, among other things. Perhaps that would be a better approach(?): https://doc.babylonjs.com/how_to/transformnode
  15. Thanks for the picture. That's much clearer to me now. The method I described above is likely your best option: you need to update the camera's position and rotation simultaneously. Your initial quaternion should be qi = (0,0,0,1), which represents no rotation; qf should represent a rotation about the desired axis (like you had in your example). Here's how to rotate a vector: 1. Write the initial position of the camera qpos = (x,y,z,0). 2. Let qs be the slerped quaternion between qi and qf for the current frame. The new position of the camera would be the x,y,z components of qs*qpos*qsc (where qsc is the conjugate of qs). Note the multiplication must be in that order. 3. Adjusting the orientation of the camera may be as simple as setting the target to the same point as you move the position. You might also have to rotate the up vector in a manner similar to step 2, or the look direction. Unfortunately, I'm a little unfamiliar with the babylon.js syntax, so I can't advice specifics. The API may already provide a more elegant solution, but this is the method I would try.