• 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
NotTakenSN

Store G-buffer in render target or structured buffer?

2 posts in this topic

What's the best way for creating a g-buffer? Most of the documentation I've read suggest rendering the scene geometry normally and then writing to multiple render targets. A drawback to this method is that render targets have to be in the four 32-bit value format. This could waste memory space and bandwidth if you're not writing a multiple of four 32-bit values. Also, it restricts the geometric data alignment to single rows (where each row starts at xmin and increases to xmax with the same y value), when small tiles might be better for coalesced memory access later on in a compute shader.

 

Is it a better idea instead to write to a structured buffer? How would you go about doing the depth testing to ensure that the final value written into the structured buffer is actually on top? I would think one method would be to explicitly read the depth buffer, compare the values, then write to both the depth buffer and g-buffer if the test passes. The other option would be to define the earlydepthstencil attribute so that only fragments that pass the depth test can invoke the pixel shader (which writes the value to the g-buffer). Does this actually work? Are there major setbacks to this method?

0

Share this post


Link to post
Share on other sites

. A drawback to this method is that render targets have to be in the four 32-bit value format.

 

What makes you think that this is the case? You can choose whatever formats you want for your G-Buffer render targets, including those that have less than 4 components or that don't use full 32-bit precision for each component.

At any rate, I've never tried using a structured buffer as a G-Buffer and I don't know of anyone else that has. I think it should work okay, though. You definitely want to use the [earlydepthstencil] attribute, since this will not only ensure correct data in your G-Buffer but it will also enable the same optimizations used when rendering to a render target. The one major drawback that I can think of is that you would not be able to use MSAA with this setup. I would also suspect that it will not perform as well, due to specific optimizations in the hardware and driver used for writing to render target textures. But that's something you'd have to profile on different hardware to know for sure.

2

Share this post


Link to post
Share on other sites

What's the best way for creating a g-buffer?

I completely understand where you are coming from with this question, but there is almost always no good answer to a 'what is the best way...' question when it comes to real time rendering - especially on a PC where the hardware varies from machine to machine.  To extend MJPs comments, if your particular situation calls for a very small G-buffer format, then you could probably use a smaller pixel format and save lots of memory.  Or, if your data is very large and you don't need coherent access to it, then a structured buffer might make more sense...  there is no good answer that is valid for all situations.

 

The best advice is to design your system accordingly so that trying out different methods for doing the same thing is easy.  In this case it wouldn't be such a big change, mostly some HLSL changes about how you write and access the data.  Try building the two methods in parallel, and then set up a specific test case that should exercise the usage that you expect to behave differently between the two.  You will learn more about the behavior of the algorithms this way, and then you will have data to back up your decisions.

2

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