• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
jajcek

Spliting terrain vertex buffer into 2 buffers

7 posts in this topic

Hello,

 

I am currently working on a terrain generation (so common problem that you're probably bored already :)). I have recently read on gamedev.net topic (can't find it anymore :/) that there's a possibility to have one buffer containing X and Z positions (which is always the same - real positioning will be done later by using translation) and send only Y values to the shader. I was wondering about such method for a while, but I can't find any way to merge these buffers in a shader. If I sent to shader only Y values how can I obtain X and Z values?

 

One thing that came up to my mind while writing this question was to send X and Z values through the constant buffer. Is this the correct way?

 

Thank you for any help.

0

Share this post


Link to post
Share on other sites

If you are using D3D11, then you don't need the XZ / XY buffer at all since you can reconstruct the position from the vertex index (check SV_VertexID). Also, under D3D11/10 you may store the height data inside a texture and use vertex shader texture read with the same vertex index. So practically you don't need any vertex buffers for height map terrain rendering! With the hardware tesselator, you don't even need an index buffer. 

 

Otherwise, to answer your question, you'll need to define your vertex declaration to read data from 2 streams, ie. the stream 0 with XY/XZ position and height from the stream 1. 

 
Something along these lines
 
 D3D11_INPUT_ELEMENT_DESC TerrainVertex_desc[] =
    {
        { "POSITION", 0, DXGI_FORMAT_R32G32_FLOAT, 0, D3D11_APPEND_ALIGNED_ELEMENT, D3D11_INPUT_PER_VERTEX_DATA, 0 },
        { "HEIGHT", 0, DXGI_FORMAT_R32_FLOAT, 1, D3D11_APPEND_ALIGNED_ELEMENT, D3D11_INPUT_PER_VERTEX_DATA, 0 },
    };
   
This declaration assumes first buffer to contain a 2-component vector and a 1-component data from the second stream.

The input structure for the vertex shader:

struct VS_INPUT
{
    float2 vPosition : POSITION;
    float Height : HEIGHT;
};
 
Inside the shader to create the position vector:
 
VS_OUT PS_Main(in VS_INPUT Input)
{
float4 LocalPosition = float4(Input.vPosition.x, Input.vPosition.y, Input.Height, 1.0f);

...
}
 

Cheers!

Edited by kauna
2

Share this post


Link to post
Share on other sites

I really really appreciate wasting time to answer my question and giving the example smile.png. The SV_VertexID looks very promising.

 

I actually shouldn't put my data to a texture as I am generating an infinite terrain, so I think sending a texture to the shader will be heavier than sending an array of Y values (and additionaly I would need to sample the texture inside the shader).

 

I am pre-calculating index buffers and switching between them if it's neccessary when creating LOD effect (unfortunately it has popping effects).

 

But still I am wondering what the performance impact will be during translating the chunks (from my investigation translation will be called like 50-100 times). I think the best way will be to use constant buffer to put there some origin position and add it to the final vertex position in the shader, but I would need to update constant buffer 50-100 times during one frame or maybe put there 100x origins at once, but which origin use for which chunk... aww! I don't know now I will try to find the best way smile.png

Edited by jajcek
0

Share this post


Link to post
Share on other sites

Hi,

 

Updating a vertex buffer or updating a texture will have approximately the same effect, you still need to upload data to some GPU resource. Using a texture as heightmap gives you advantage of taking multiple random samples inside the shader (good for normal generation in the shader). A typical hardware won't take any performance hit from using vertex shader texture fetch. 

 

For the translation of chunks, you may collect all the visible terrain tiles at once and update your constant buffer once per frame. You may create a several buckets based on which indices you need to use with each tile. SV_InstanceID helps you to use correct translation with each tile. 

 

Cheers!

2

Share this post


Link to post
Share on other sites

The terrain tiles are not instanced*, every tile has its own vertex buffer, so SV_InstanceID won't help me, but I will play with that and check different approaches.

 

*I don't even see the point of instancing it as every tile has another geometry, altough number of vertices is the same,

0

Share this post


Link to post
Share on other sites

Hi,

 

- the point of instancing is pretty clear. You may reduce the amount of draw calls by some hundred easily (depending how your terrain is tiled). 

- the advantage of using a texture is clear too - it allows random access and allows you to use instancing with a terrain.

- as you stated - the grids share a certain amount of geometry, and the meshes are "different" but the shader code to draw them is the same regardless of the terrain form. 

 

With tesselator hardware, I'm able to draw all my terrain from zero - infinity with 2 draw calls (because I use 2 different shaders for different detail levels). 

 

Cheers!

1

Share this post


Link to post
Share on other sites

I wonder how do you do the frustum culling with only 2 draws? In shader? It must be inefficient to cull by a vertex.

0

Share this post


Link to post
Share on other sites

Frustum culling poses no problems, since every frame I collect all the visible terrain nodes / tiles and add their drawing parameters to a list (or two lists in this case). The visibility test is done on CPU and the data is put inside a std::vector container.

 

The data is uploaded to a constant buffers and then I execute an instanced drawing command. Nothing special here.

 

Cheers!

Edited by kauna
1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0