Dal

Members
  • Content Count

    182
  • Joined

  • Last visited

  • Days Won

    5

Everything posted by Dal

  1. Dal

    Dynamic Terrain

    @jerome looking *really* good! Any chance of an example of a game-style terrain? Something with a first person character running around on grassy hills with a far view distance + fog so we can see how it performs in a more real-world use case.
  2. Keep at it! Terrain is a tricky topic but you're smart so I'm sure you will get it Could you make an example with the terrain view distance of about 1km? I'd love to see how this performs on larger scenes.
  3. Woo! This looks really nice. The speed seems really good although I'd like to see how this looks with a high detail terrain with texturing and far view distance - thats where my implementation started to show it was slow.
  4. Cool. Thanks for the articles I've kinda given up on this myself, but I am happy to share the typescript code I have if you feel like trying to make it awesome, Babylon is still lacking a decent terrain engine.
  5. Dal

    London, UK

    Used to be, but I've moved now, soz
  6. I think I'm going to move away from Babylon for now... I can't get this working well enough to make my game, so I think I'll try an engine that has a working terrain already.
  7. Dal

    Trex

    Ah he follows the camera... nice
  8. The only way I can think of is to write some "fake threading" code that gets called every frame, reads a fixed number of bytes each frame, then saves where it was up to and yields.... then the next frame it picks up from that point and continues. So your large import can be gradually built up over a number of frames without freezing. Would be good if someone could write such a loader for Babylon
  9. @NasimiAsl You are always making such amazingly smart stuff that I feel I would love to use but I have no clue what I could use it for I could imagine this could be evolved into a very pro (expensive) tool for building designers and architects to prototype, since they can quickly sketch layouts and ideas for new malls and business parks. Maybe you should develop it in that direction and get rich Btw you could incorporate this browser-based SVG editor into your tool if you like - its open source so you could modify it to generate exactly what you need to build the 3d directly: https://github.com/SVG-Edit/svgedit
  10. Hey guys, is there a way to remove the input delay on the free camera? I find it doesn't seem very responsive, it seems to react with a noticeable delay even when the framerate is high. I've tried various settings on the camera but I can't seem to solve it.
  11. Hmm, so why not then? I'm just thinking, if we have a huge scene with lots of different meshes, players, lights etc. and we want to move the whole thing (e.g. so we can have an infinite world size without worrying about the numbers getting too huge), it seems more natural to me to parent them all to a root:Node rather than a dummy empty mesh.
  12. @adam Cool, that works,... but then if Node is the base class of Mesh, Light and Camera, and all of those have a position, why don't we just define position on Node instead? Then instead of an empty mesh, we can just have a named base node, which would be cleaner wouldn't it?
  13. All the children of Node have a position, but Node itself doesn't, so how can I just attach lots of things to a Node and then move the parent?
  14. Gah... I can't seem to solve the loading lag... even with threading and everything it just seems to take too long to add the children, I wish it was possible to see exactly which line is causing the issue
  15. Just in case anyone is testing/thinking of testing this, the version in git is a bit broken now because I am working on some breaking changes at the moment to hopefully address performance issues.
  16. Ok the good news is I've just made a major performance breakthrough and backported the change to webgl and it works much better now. The bad news is that it's introduced holes in the terrain, but I have a rough idea how to solve that... fingers crossed.
  17. OK, I've got the CPP target running quite fast Still lots of bugs though with the Haxe version.
  18. Hmmm, yep, seems with the JS target the performance is about the same. I don't get what is sucking up all the performance. What I need is someone who's really good at profiling... who is best at that on this forum?
  19. Actually I am only guessing that it's faster - I can't figure out how to display the FPS in @babylonhx
  20. Well... Haxe port is now complete. Initial indications are that it DOES run faster... although i'm not sure it's working exactly as intended at the moment. @babylonhx Am I right in saying there's no debug layer available in BabylonHx yet?
  21. Yeah that's roughly how my first approach worked... but I couldn't get it right. How would you texture it? You'd need a "logical" texture as well... so perhaps that means having a huge texture in memory, or you split it into smaller ones, but then when you "slide" between 2 different textures you need to load in 2 textures and pick some data from each... and maybe you could be on the border between 4 different textures at once, so you need to load and sample 4 textures.... The height data could be a similar issue... you have to fit the entire world into memory, even if you don't render all of it. For my first try, I was keeping the mesh static and setting the vertices in the shader. It runs fast, but then the positions aren't stored in the mesh itself, so it starts getting tricky for physics and height picking and doing stuff like placing trees only where it is not too steep etc... really that calculation needs to be done in JS side I think, which is why I ended up coming back to the quadtree concept. My latest approach loads a large amount of data but doesn't render all of it, it misses out more triangles the further away you get. That lets me have fairly big terrains, but I still can't load a really huge world into memory at once. A terrain that is 2km big, say 2048 x 2048, with vertex per metre, that's still 4.2 million vertices. Even if I don't triangulate them all, its still a heck of a lot of verts to load in, and they have to be updated as you move around. I've tried to reduce it so it uses a quadtree to only update the needed verts, but its still not efficient enough - that's the bit I guess I need help with. We need to do some low-level stuff there to do better culling and use of buffers to do only the very minimum of recalculation of LOD each frame.
  22. That's kinda what I have... but with squares not circles. All the possible verts and heights are precomputed and it just calcs which indices are used based on the distance... The thing is, the size of the data is too large to store the large terrain all in memory at the same time... so I page in chunks of terrain as we move around, allowing practically infinite size. The big problem is that even just calculating the indices interating a quadtree seems too slow in my implementation. I don't really want to start again at this stage - the theory for this one seems solid enough and is widely used in games out in the wild, I think there's just some inefficiency in the implementation that needs solving.
  23. Interesting approach.. I haven't seen that done before. It would be tricky to page in the data though... with the approach I am using, it loads in new squares of terrain as you move around, and it will load in splat maps for each region in the same way. With your approach it would be hard to split out the heightmap/splatmap textures into distinct tiles, so you'd have to do something like work out which squares your circle covers and then load multiple textures and pick some of the data from each... might end up being more heavy.
  24. I'm porting it to Haxe at the moment.... perhaps in the process it might end up running faster and I can also see how fast it runs under a C++ target for comparison.