• Content Count

  • Joined

  • Last visited

About Hanesu

  • Rank

Profile Information

  • Location

Recent Profile Visitors

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

  1. Oh, thank you, it's good to know that instances are not depth tested. To remove the remaining artifacts which are caused by the nontrivial geometry of the three cylinders, I split up each cylinder into two, like here https://www.babylonjs-playground.com/#FFZ9HL#3 Is it possible to move the center of the bounding sphere of each half cylinder to the outer cap? Then all the overlap problems at the three touch points should be gone.
  2. I need 3 cylinders in a geometry like the one here https://www.babylonjs-playground.com/#FFZ9HL#1 with transparency. But once the alpha value is below 1 (change line 14 in PG) the alpha blending doesn't work properly, the cylinder on the right goes in front of the cylinder in front. I know that there are some artifacts for alpha blending, but from the initial view direction the center of the bounding sphere of the cylinder in front (which should coincide with the center of this cylinder) should be closer to the observer than the centers of the two other cylinders. Am I missing something? In general, I figured out that for this specific problem the depth test and alpha blending should work perfect if I divide each cylinder in half and place the center of the bounding sphere at the middle of the end cap for each of the 6 half cylinders. But how can I do this?
  3. That's it, the second PG does exactly what I need. Thank you so much, you made my week!
  4. By monitoring camera.radius you immediately see that scrolling directly changes the radius.
  5. Thanks for the examples, very helpful. I will check out the actionManager stuff. One thing that still bothers me is when I zoom with the arcRotateCamera through mouse scroll. When I scroll the mouse wheel nothing happens (of course, because the mouse button is not pressed). Then, when I press the mouse button, the scrolling motion happens, it is somehow remembered and the action is delayed. This behavior is not useful, so one way around it would be an "onScroll" event analogous to the "onPointerDown", but this event does not seem to exist. That is why I thought it would be simpler and more general to check for motions in the camera, like camera.alpha/beta/radius changes. How could I check for changes in those parameters and only render in case of change?
  6. There is a very good reason why I want to stop rendering if there is nothing new to render: I have complicated meshes (scientific data) to visualize with millions of triangles. If they are re-rendered 60 times a second, the cpu load goes up to 100%, my laptop gets freaking loud, crazy hot, and runs out of battery after one hour! If I have means to stop rendering, like for example with the simple solution by @aWeirdo above, the cpu load goes down below 5%, my laptop is quiet, keeps cool, and runs for eight hours on battery!
  7. Thank you, this is a nice and simple example, but the functionality I a bit limited. How could I extend it to render as long as the camera or some object is moving?
  8. Making the renderer stop rendering when there is nothing to do - this is something I would like to implement as well. Do you have any PG for this? I cannot find any full example above. Thanks lot!
  9. Whooo, that "beta-fix" creates weird stuff that was not there before. But thanks for the PG showing the override of the camera, I'll try my luck to implement a trackball version based on this.
  10. Yeah, at the poles are the coordinate singularities where the nasty stuff is happening. This is why one needs to get into the guts of ArcRotateCamera to create a different behavior. I wonder if any other camera gives us the control over the transformation matrix.
  11. That's good to know, removing the BetaLimits feels already much better, it gives more freedom to the camera controls. But if one comes close to the poles the controls react a bit "nervous". More importantly, there are still many orientations of the target which are not accessible.
  12. Hi there, I'm new here. First of all: Thank you to all of you guys contributing to Babylon.js, it's an amazing project! I'm using it mainly to set up interactive 3D visualizations for scientific purposes and it works like a charm! Here's my question: So far I mainly use the ArcRotateCamera. There's nothing wrong with that camera, but the restriction that I cannot rotate over the 'north/South Pole' is something that bothers me, because it limits the exploration possibilities of the user. Further, although one can see the target from any position around it, one cannot see the target in all possible orientations. I would like a camera with trackball-like controls for the rotation around the target, meaning that in whichever position the camera is, I want to be able to rotate it around the two independent directions orthogonal to the line connecting target and camera position. Is it possible to create such a behavior by customizing the UniversalCamera? Or if not, what would be the simplest way to implement such a camera? Another idea would be to use a static camera and to attach custom mouse controls to rotate the target in the preferred way. But I don't know if this creates any drawbacks in terms of rendering performance. Does it? Thanks a lot!