Jump to content

Slight0

Members
  • Posts

    5
  • Joined

  • Last visited

Posts posted by Slight0

  1. Collider(86 faces): 8ms

    Collider(135 faces): 14ms

    Collider(146 faces): 15ms

    Collider(31 facecs): 3ms

    Collider(107 faces): 10ms

    Collider(142 faces): 14ms

    Collider(70 faces): 8ms

     

    Those are some times to generate colliders. It ranges from around 3ms to 20ms.

    The time taken to generate the mesh ranges from 0ms to 1ms.

    Chunks are 16x16x16

     

    Thanks and holy ****! I was expecting more from bullet physics. In the thread I posted in the OP, a chunk with about 1500 triangles takes about 6ms to generate a mesh collider for. Mesh generation is always under 1ms, usually like 300 microseconds.

     

    Are you using RigidBodys or static colliders? Make sure you did it with static colliders as those should be faster.

     

    I don't think my CPU is that amazing either; Intel Core i7-2670QM @ 2.20GHz 4 cores (8 threads).

     

    This does not bode well because I'm thinking about integrating Bullet physics into Unity.

     

    A 200x200 grid plane takes around 20seconds to generate a collision, 100x100 is from .4 to 4 seconds.

     

    Interesting, but without the exact number of triangles there's little one can do with that information.

  2. There is a free demo on Steam but like DerRidda mentioned its LUA only. This means you don't get access to Mutex and Threading libraries, however the rest of the engine is fully accessible (unlike the other game engine you mentioned). C++ version adds templates for VS (or CB on Linux) option when creating a new project.

     

    Yes, I'm aware. Threading is paramount to what I'm doing. Secondly, I'm a programmer and, though lua is nice for quick prototypes or games like garry's mod and world of warcraft, it's not a good game development language. I'd cite Natural Selection II as evidence of that. Not that it's a bad game, but a real pain to modify (hint: a lot of the game core is written in lua). No types, no good IDEs, debugging is challenging, no classes, it's just too flexible to keep organized with.

     

    Unity has a 30-day full featured trial that you can email them and have extended for another 30 days, after that it's still usable, just without the advanced features that you really don't need for core development. I prefer Unity's limited model to this model because I can do everything I need to do, then buy the engine when I'm nearing a public release and work in the relevant advanced graphics/animation features.

     

    Leadwerks does look promising with a superior editor toolset to say the least, but switching from lua to C++ is non-trival.

     

    I've implemented a voxel engine in Leadwerks, and I can say that it can be done, but I've found that the time it takes to generate the collision is quite long. I've had a lot better luck in Unity. From what I've found, Leadwerks is faster to generate the mesh, but Unity is faster in the collision, but not that much slower in gerenating the mesh, so Unity is a better option IMO for a voxel engine. Hope this helps smile.png

     

    Would you be able to tell me the timing it takes you to generate the collision mesh for a single chunk in your engine as well as the number of triangles in said collision mesh?

     

    I'm not completely familiar with this subject, but isn't the speed at which the collision is generated dependent upon the physics engine used? If so, I know that others have replaced the standard physics engine that comes with leadwerks with one that was more suited to their needs.

     

    Right, but replacing the physics system is something I can do with other engines like Unity. It's a bit of work and if I have to do it, I might as well do it in the engine I'm already familiar with.

  3. Appreciate the response.

     

    It's not really possible to make a time-limited C++ trial.

     

    Perhaps a free version of the engine is in order then? One with restricted advanced features like Unity3d does? Afterall, what does limiting engine access really get you anyway?

     

    I think the collision mesh creation would be trivial relative to the other calculations. It's not easy to split the physics off onto a separate thread, but I always assumed it wouldn't be an issue for Leadwerks with this type of game. Can't really say for sure since I've never tried it though.

     

    How many polygons do you reckon an average chunk consists of?

     

    As long as the collision mesh, I assume the class is btBvhTriangleMeshShape, doesn't access other objects like the world object or what have you, whilst the Bounding Volume Hierarchy optimization and other caching is taking place, threading should be trivial. I don't need to simulate physics in another thread, just to create the object and then pass it to the main thread.

     

    I'm benchmarking with about 1536 triangles per chunk, but the actual geometry will probably yield about 400-800 triangles per chunk. This is without any sort of mesh optimization applied.

  4. I've built a prototype voxel engine in Unity using threads to do mesh generation and voxel data generation. My main goal is generation speed. I've run into issues with Unity's MeshCollider as I cannot generate it in a thread due to Unity's single-thread nature and it is a time consuming task to create each MeshCollider.

     

    Here is my thread with more details if you want specifics.

     

    Anyway, I noticed Leadwerks has a Surface class which I presume will let me control meshes from code. What about collisions? Chunk generation speed is my priority so how fast is the creation of collision meshes? More importantly, can I offload this process in another thread so that the main thread is unhindered by collision mesh creation?

     

    Any info is appreciated.

×
×
  • Create New...