Page 9 of 9 FirstFirst ... 789
Results 81 to 86 of 86

Thread: voxel game

  1. #81
    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.

  2. #82
    Quote Originally Posted by laggyluk View Post
    If you still want to try it you'd need to download the source, install lnet and dcpCrypt components and then run the brickUI project. It crashes on the line with rendering context creation in my case.
    For now I just removed "Inet" and "cdpCrypt" from Required packages and try to compile "brickUI.lpr" and I end up with bunch of "Duplicate identifier" errors. It seems that all of them are withing conditional define blocks like

    Code:
    {$IFDEF CPU64}
    int = int64;
    Long = uint64;
    {$ENDIF CPU64}
    {$IFDEF CPU32}
    int = integer;
    Long = longword;
    {$ENDIF CPU32}

    Now I have very little experience with Lazarus especially with conditional defines so I would be grateful if someone can explain how can I get rid of these errors properly.

  3. #83
    Quote Originally Posted by SilverWarior View Post
    For now I just removed "Inet" and "cdpCrypt" from Required packages and try to compile "brickUI.lpr" and I end up with bunch of "Duplicate identifier" errors. It seems that all of them are withing conditional define blocks like

    Code:
    {$IFDEF CPU64}
    int = int64;
    Long = uint64;
    {$ENDIF CPU64}
    {$IFDEF CPU32}
    int = integer;
    Long = longword;
    {$ENDIF CPU32}

    Now I have very little experience with Lazarus especially with conditional defines so I would be grateful if someone can explain how can I get rid of these errors properly.
    I tried to $DEFINE CPU64 and $UNDEFINE CPU32 but that didn't help, so I just manually removed all CPU32 parts. That helped.

  4. #84
    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.

  5. #85
    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.

  6. #86
    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.

Page 9 of 9 FirstFirst ... 789

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
  •