Jump to content


  • Content Count

  • Joined

  • Last visited

  1. With the ellipsoid set to a height of 2, the camera towers over structures with a height of 3, so I concluded from that it must be a radius rather than a diameter. Hence I set it to 0.75 to get an overall player height of about 1.5m, which has seemed to work up until now. If it is a diameter (and I'm sure you're right about that... you would know!) why is the setting of 2 allowing the camera to easily look over the top of objects with a height of 3?
  2. After I manually diff'd all your changes, I was able to dramatically reduce the amount of distortion, thanks! I did not make the ellipsoid change because a 4m meter player is problematic for other reasons. 🙂 The distortion is still there (regardless of camera height), but it's much smaller and you kind of have to be looking for it. The factor that seems to have the largest effect on it seems to be the line you added to kill the wind: this.matSea.windDirection = new BABYLON.Vector2(0, 0) That makes a huge difference, though with no wind the result appears perfectly still; more
  3. The current skybox size is 2048. Is that a good size? After stripping out and refactoring as much as I could, the playground should be: http://www.babylonjs-playground.com/ts.html#RTY6WT#2 Hopefully this code is relatively easy to follow. Issue #1: Poor FPS with reflections With both ground mesh and skybox reflections enabled, I'm getting about 26-28fps in the playground. Commenting out the skybox reflection only (line 54) doesn't seem to change this. (Nor does removing it completely.) Commenting out only the ground mesh reflection (line 55) but leaving the skyb
  4. OK, I made that change; it added a few FPS according to the meter, but having the water in view still renders the entire system choppy and hard to use. I'll really try to get this into a playground soon. This may also be helpful, I'm adding a screen grab showing the distortion. There are a couple of different issues. First, the water seems to be reflecting at the wrong height (visible farther away as the water reflecting more of the island than is above the surface. This is probably not that serious. Second, the reflection calculates correctly most of the time, for both the s
  5. Hi all, I am still working on this, though life continually interferes. 😕 Everything continues to run very smoothly, with the single significant exception that my experiments with WaterMaterial are having really brutal effects on the frame rate, cutting it from a very smooth 56-60 down to a very choppy 30 if (and only if) I have it reflect my ridiculously huge terrain. (It's choppy enough to make me question how accurate the 30 is.) There are also some weird graphical glitches. It's not super clear if I've just hit the limits of the hardware, or if I've made some mistakes along th
  6. That is what I would expect as well, and yet it does not. It sits comfortably at 58-60fps when the player is on the terrain mesh.
  7. Did you make other changes than reducing the subdivisions? (Is there a way to see a diff between different versions of a Playground? I looked and Google'd and didn't find one.) My "real" project uses a 2048x2048 heightmap with 2048 subdivisions and for some reason I don't understand it handily outperforms my playground version based on the 512x512 heightmap. So right now I don't have any real reason to reduce subdivisions in the real project, since it performs well and I want the most detailed terrain I can get. But I would sure like to understand the why it performs well and the
  8. Seems like (not surprisingly) you were right about that. Although a value of -1 for scene.gravity prevents all movement, and -2 prevents all climbing (like the original -9.81 value), I tried some more intermediate values between -1 and -2 while trying to make an updated PG and they did work much better. For now, I've settled on -1.1. It seems to allow climbing some reasonable slopes, but not walking up cliff spaces or blatantly soaring into space. And the limited downward sliding that occurs also seems reasonable. This should work for what I need right now. The latest PG is here
  9. These are some good leads. Thanks! Have I possibly misunderstood what a "subdivision" is? I thought it pretty much referred to the polygon density. I.e. if you set 100 subdivisions, you get a mesh that is 100x100 quads (or 100x100x2 triangles). So if you do 200 subdivisions on a 512x512 heightmap, aren't you losing a lot of the terrain precision? I did as you suggested and flipped to wireframe, though I had to drop subdivisions to 64 in order to be able to stand walking along the edge and counting polys. That did seem to reduce the mesh to 64 quads (128 tris) per side.
  10. OK, I had an opportunity to make a playground: http://www.babylonjs-playground.com/ts.html#IIFQWH#2 This demonstrates three of the problems I've run into: 1) Can't navigate uphill at all. 2) Framerate is terrible when moving. 3) Calling GroundMesh.optimize( 64 ) makes the terrain disappear completely. Prior to starting I thought I saw at least one thread on here about movement on terrain, but now I can't find that. Everything I can find in the way of how-tos is about moving on perfectly flat surfaces. If anyone knows the thread I'm referring to, or another reference
  11. So, I got a bit of time to work on this tonight. Building on the checkCollisions discovery, I went back to the original 2048x2048 terrain heightmap. Still 50-60fps. I added a colormap diffuseTexture on it. (No splat map yet.) Still 50-60fps. I added a textured placeholder building with collisions (that's all I have so far), still 50-60fps. It may be an effect of having even a rudimentary texture on it, or else I somehow accidentally fixed the 8-bit heightmap issue, because the "anti-aliased Minecraft" look is gone as well. So I turned collisions and gravity back on and I
  12. Aha, got it, thanks again! The documentation is a bit sparse on what that actually does, but I can always read the source code and hope my brain doesn't explode. Or it may become apparent what it does after I spend a bit more time learning about octree generally.
  13. Aha, I was looking for something specific to terrain. Looking at the reference page for Mesh, I see an optimizeindices method, but that takes a callback, not a number. Is it that, or something else, hiding in a base class maybe? I think I'm going to try to load the bigger terrain again tonight, and I will try both octree and optimize in conjunction with that.
  14. Wow, cool! I just have to step back for a moment and say that Babylon.JS is not only an amazing piece of high-quality open source code, it also seems to be a really well-run project. The playground feature was impressive before. With Typescript support? Even better! I'm also very grateful for how welcoming and helpful the posts here have been! Thanks to everyone!
  15. Thanks for the responses, all. My understanding is that I cannot do a PG because I am using Typescript for my project, is that correct? (I have a background in programming, but both Javascript and 3D are fairly new to me.) @jerome I looked at your flight simulator twice, and it consistently runs at 56-60fps on this system (almost always at 60fps). It is very smooth and I would love to get to that point. There are only three meshes in this scene at present: the terrain mesh, the water plane mesh, and (sometimes) a skybox. That's it. So based on what I read about those suggest
  • Create New...