entropy

Members
  • Content Count

    19
  • 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. 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
  2. @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!
  3. entropy

    Let there be light...

    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
  4. @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?
  5. Those are some excellent suggestions. I didn't even consider the physics engine approach! I'm slowly but surely learning...
  6. @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
  7. 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.
  8. I have a project where I have a collection of solid particles that I need to test if they intersect. I have a simplified demo of the project here: https://playground.babylonjs.com/#C7K3Q1 The particles themselves will have a box shape (as in the example) and I need to know if they physically overlap. According to the documentation for SPS, particle.intersectsMesh(otherParticle) uses less precise metrics to establish whether meshes intersect. Indeed, in the above playground, a collision is registered (red color) even if the actual meshes do not overlap. So I found the following line in babylon.solidParticle.ts located at https://github.com/BabylonJS/Babylon.js/blob/master/src/Particles/babylon.solidParticle.ts#L173: return this._boundingInfo.intersects(target._boundingInfo, false); In my local version of the script, I tried changing the "false" to "true" to force the more precise collision detection, but that seems to have no effect (I can't demo that in the playground, obviously). Is there a way to force the more precise calculation (even if it's on my local copy of babylon.js)? Or, perhaps there's some better way of achieving this? P.S. I realize this is an expensive CPU operation, but I only need to test for collisions once since the particles are stationary.
  9. Just to make sure I understand correctly, you want to rotate the camera around the blue line so that the box now appears at the end of the green line?
  10. It will, presumably, rotate around both. How does one rotate around a local axis and not rotate around a global axis? Or vice versa? When you say you are trying to rotate around world axes, do you mean you are trying to restrict the rotation about a particular world axis? Or, if you are trying to rotate an object around a point in space (say, the world origin), you'll need to update (simultaneously) the rotationQuaternion of the mesh (to change it's orientation) and the position vector of the mesh (to change its...well...position). The mesh's position itself is just a vector, and you can use quaternions to rotate that as well. Edit: I think I understand your question better. When you assign a quaternion to a mesh, it applies the quaternion to the coordinates of the mesh (which are probably defined relative to a local origin...I think...not certain, though). To rotate around a global origin, you're probably back to updating both the orientation and position, as previously described. Edit 2: I just checked, and I do believe my statement is correct: it rotates around the local origin based upon how the mesh was originally defined. You can check here, https://www.babylonjs-playground.com/#IKU2U#1 where a cube is created and then shifted along the y-axis by a unit of -1. Then, when the cube is clicked, it still rotates around the local center of the cube, and not about the global origin. However, if before the rotation you cube.bakeCurrentTransformIntoVertices(); then the initial translation, in effect, gets baked into the vertex locations. Now it rotates around the global origin: https://www.babylonjs-playground.com/#IKU2U#2
  11. A common way to smoothly transition between two quaternion-based orientations is to use spherical linear interpolation (slerp, for short). I think this will do what you want. The quaternion object in Babylon.js even has a slerp method built-in: https://doc.babylonjs.com/api/classes/babylon.quaternion Edit: here's the Wikipedia article on slerp: https://en.wikipedia.org/wiki/Slerp
  12. As the title suggests, I think there's a strafing bug with this camera. Using the left/right arrow keys to strafe also causes the camera to rotate. Forward motion also behaves strangely. This makes for very confusing controls when simultaneously moving the mouse to pivot the camera. I've tried this in both the stable and latest versions. https://playground.babylonjs.com/indexStable.html#U2754M#1 I also provided a Universal camera to show the difference in behaviors.
  13. Thanks for all the help so far. @jerome...I've been looking at and trying to interpret the "Turbo SPS" code that you linked to earlier. Please let me know if the following explanation is correct. In your vertex shader, you assign the following attributes: "position", "uv", "translation", "scaling", and "rotation". Typically, I would think of the last three attributes as instance attributes. In other words, they would would get updated only once per instance, so all of the vertices of the same instance would automatically have the same "scaling" parameter, for example. Instead, it seems like you are using those as per vertex attributes where you simply repeat the same "scaling" value for every vertex in the instance, etc.? @JohnK...that's very clever. That does mimic the behavior of my intended application, more so than my original example. What kind of performance are you getting with that second example with 20000 spheres? I only get about 10 fps.
  14. Unfortunately, there's no way to model my exact situation in the Playground. I'm using Babylon.js (running in a CEFSharp control) as a 3D viewport in a C#/WPF application. The positions/orientations of each particle are determined on the C# side of the code based upon user inputs at runtime. Basically, I'll need to do something like for (var p = 0; p < SPS.nbParticles; p++) { SPS.particles[p].position = data[p]; } where data[p] is information ultimately derived from C# code. I think, ultimately, you're probably right. The code (as is) is already way faster than my previous solution (using native WPF 3D)...now I'm just getting greedy for performance. 😁 Here's a more realistic case that I might have to deal with: https://playground.babylonjs.com/#H8ZQMH#5 I'll primarily be animating boxes, not spheres. On my system, I can animate ~10k boxes and maintain 60 fps. Anything more than that and the frame rate plummets. For the most part, 10k boxes will be sufficient for my purposes. But offloading translation/rotation to the GPU will give me extra headroom for those fringe cases (and/or it will allow me to use more detailed meshes). @jeromeWow, that seems to work smoothly! I've tried downloading the code, but can't seem to get it to run on my local machine. Any tips on integrating this into a Babylon.js project?
  15. Yes, @JohnK summarized what I was trying to say quite elegantly. I did find an example on the three.js website: https://threejs.org/examples/#webgl_buffergeometry_instancing_interleaved_dynamic If you look at the code, you'll see a vertex shader similar to the one in my previous post. In the three.js case, the offset and orientation information are passed as per instance attributes to allow the GPU to do all of the vertex transforms. While the tutorial that JohnK referenced doesn't do quite what I was hoping, it does illustrate the power of the technique. Here I've modified the example from the tutorial to animate 10000 sixteen-vertex spheres: https://www.babylonjs-playground.com/#1OH09K#86 Compare that to the pure SPS solution in my original post that struggled to animate 2000 smoothly. (Granted, the latter is only applying a texture without lighting effects, so it's not a direct comparison.) All that's missing is per instance variables...is that possible to do while using SPS? I hope I don't sound too querulous. I'm coming from programming 3D in the WPF realm, and Babylon.js is already performing one or two of orders of magnitude faster!...and it's much easier to use.