Results 1 to 10 of 86

Thread: voxel game

Hybrid View

Previous Post Previous Post   Next Post Next Post
  1. #1

    voxel game

    edit: public repo is here: https://github.com/laggyluk/brick_engine
    or engine. or both, anyways i'm working on it. current state is a bunch of cubes that can be edited, saved and loaded. Doesn't look pretty yet, need to add some lighting/shading. made in lazarus and opengl
    http://www.youtube.com/watch?v=svjcsXlwQSQ

    Last edited by laggyluk; 25-05-2017 at 12:56 PM. Reason: You can post YouTube videos right in your posts! :)

  2. #2
    It looks smooth. What kind of optimizations have you used?

  3. #3
    not many, map is divided into 32x256x32 chunks, each has it's own vbo. then I'm sending only centre of each cube to the gpu instead of all the verts and cube is created in geometry shader. in the alpha channel is encoded info which faces are actually visible and since I'm planning to use deferred rendering then alpha is not much of use anyways. and I do frustum culling on chunks, 'radar' in right bottom corner shows which of them are rendered. runs pretty smooth on my laptop, we'll see if it's still smooth with lighting

  4. #4
    attempt to implement deferred rendering when knowing opengl so little wasn't a smartest move. after few days of struggle I decided to do usual lighting for starters and yay, it works:
    forward rendering.jpg

  5. #5
    deferred + ssao


    btw anyone knows if this sort of 'shading' is ssao or some other technique?
    22.jpg
    Last edited by WILL; 14-02-2013 at 03:47 AM. Reason: You can post images and video right into your posts here! :)

  6. #6

  7. #7
    Quote Originally Posted by laggyluk View Post
    ... then I'm sending only centre of each cube to the gpu instead of all the verts and cube is created in geometry shader. ...
    Would you still take this same approach? (or use Tessellation shader) From what I can find online is very conflicting if this is smart or not.

    Of course I would love to use CPU for other things, but then again the results can be buffered and only redone when the map info changes.
    Last edited by Thyandyr; 27-05-2017 at 07:14 PM.

  8. #8
    Quote Originally Posted by Thyandyr View Post
    Would you still take this same approach? (or use Tessellation shader) From what I can find online is very conflicting if this is smart or not. What I do have in mind I will need my CPU for other things than tessellating, so I might take this same approach.
    I see from the project code that you dropped the idea of voxelifying/tessellating in the geometry shader. Any post mortem comments?
    Last edited by Thyandyr; 27-05-2017 at 07:14 PM.

  9. #9
    PGD Staff / News Reporter phibermon's Avatar
    Join Date
    Sep 2009
    Location
    England
    Posts
    524
    Benchmarking is your friend. This task is exactly the kind of thing geometry shaders were intended for - IE input a point, spit out a cube - but I'd personally benchmark generating the cubes in a geometry shader vs instancing cubes vs a hybrid instancing approach that can render identical groups of voxels.

    The implementation of such a hybrid approach would likely be a balance between identifying groups of voxels to collapse into a single, instanceable data set and marking sets at generation time - modifying generation to implicitly generate known identical groups (the simplest being a completely filled cube of say 16x16x16 voxels) - these groups can be flagged and split into their individual voxels as and when they are altered - lowering the number of draw calls / instances for large continuous areas in many cases.

    Tessellation would not be a good match for this problem - you define patches that are tessellated by feeding them into a control shader (which are then evaluated in the evaluation shader - basically a vertex shader that's patch aware).

    The simplest possible patch being a triangle and the simplest possible group of patches to construct an enclosed volume would be a triangular pyramid - these are ill suited for tessellation into cubes - so the simplest possible geometry would be a cube - which is what you want anyway - ergo tessellation is not going to allow you to benefit when it comes to just throwing individual voxels at the GPU.

    *but* if you go for the hybrid approach above - you could use tessellation on any continuous cube of voxels (say 16x16x16) *if* you needed the actual individual voxel's surface geometry on the surface of that amalgamated cube - for example per vertex lighting which you may be using with SSAO for a more pixellated feel.

    This would mean you could have a single draw call / instance for a group of 16x16x16 voxels input as a single cube - but still be dealing (at least on the surface of that cube) with the geometry and positions of the individual voxels by the time you reach the evaluation and pixel shader stages.

    You could further optimise this by having vertex data instances that represented 16x16x16, 8x8x8, 4x4x4 etc groups of voxels - then instead of splitting the entire group into voxels when it gets altered - you could just split it like an oct-tree. (really you'd just use a cube patch at different sizes + tesselation levels on the GPU and only treat it like an unbalanced oct-tree on the CPU)

    The scheme you use will be heavily influenced by visibility / culling - I expect there's a sub-division level where just throwing individual voxels at the GPU is faster than feeding in a dynamic oct-tree like set of data and acting on it conditionally (actually I know there is at least on the hardware I have because I've already done all this)

    Of course there's still the issue of colours/textures that could differ across voxels in a group - there's many ways you could handle this but in the scheme I propose it's rather tricky without using a ton of memory - you will hit memory bandwidth vs shader performance trade-offs pretty quickly with large 'worlds'.

    Hope that provides some insight - have fun!
    Last edited by phibermon; 28-05-2017 at 01:11 AM.
    When the moon hits your eye like a big pizza pie - that's an extinction level impact event.

  10. #10
    Quote Originally Posted by Thyandyr View Post
    I see from the project code that you dropped the idea of voxelifying/tessellating in the geometry shader. Any post mortem comments?
    Yeah, I've tried generating cubes from single point in geometry shader and performace was awful, way worse than using separate verts for each.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •