Jump to content
  • Advertisement

jesta

Member
  • Content Count

    8
  • Joined

  • Last visited

Community Reputation

133 Neutral

About jesta

  • Rank
    Newbie
  1.   That's the part I don't understand. My grid can be up to 200x200 visible tiles. Are you suggesting I do 40k draw calls?   I'm not trying to challenge your idea here, I just genuinely want to understand your approach.
  2. I ended up following MJP's advice, but with very tight packing inside a uint. This creates a very small buffer at the cost of code complexity (lots of bitwise operations). I'll benchmark my implementation against a more naive approach using uints for states to see if there are real benefits with packing.   Here's a glimpse of the vertex shader code to unpack the uint buffer:     Benchmark results to come.
  3. @dpadam450 I think we're not talking about the same thing here. My question is not about the appearance of the grid. In fact, I do have a texture with the + shape and everything. What I need is an efficient way to send each tile's state (green, yellow, red) to the shader and THEN use this for shading. Or maybe I misunderstood your solution?   Edit: Right now I do have the same exact grid as SC2 visually. What I don't have are the tile colors matching the states (free, obstructed, etc).
  4. @MJP The buffer would typically be 100x100 elements. I'll try packing the states in a uint[], with 16 2-bit states per uint. Then I'll send that to the StructuredBuffer.   @NumberXaero Correct me if I'm wrong, but I don't see how storing and updating vertex colors would be more efficient than sending states as a bye[] in a buffer. In both cases I need to update a buffer, which would be larger if I choose vertex colors.
  5. I'm trying to render a grid similar to Starcraft 2's build grid. I want each tile to change its color as efficiently as possible using a single shader for the whole grid.       On the CPU side, I have a byte[] (C#) which contain the state of each tile (free, occupied, conflict, etc.). These states change each time the player moves a building over the grid or builds it. My idea right now is to send this data to the GPU through a StructuredBuffer, submit a procedural drawcall, and somehow change the color of the tiles based on the data and the vertexID.   I have two potential problems with this: There is no 8 bit scalar type in HLSL (like byte). Should I convert my byte[] to a uint[] and pass that to the buffer instead? I don't like the idea of having a duplicate of my data array. Is there a way to "fake" an 8 bit scalar in HLSL? I'm using Unity, and the only way to update a buffer on the CPU side is to set the entire array of data. This could be done frequently (each time the player moves the building to another position). I wonder if there is a more GPU-centric approach to fetch the state of each tile in my grid. I know this all sounds like premature optimization, but my main goal here is to learn new ways to think about these kinds of problems.   Thanks for any ideas.
  6. I'm trying to apply data oriented design to my engine's main systems, including the renderer. This is easily done for things like particle systems and agent simulation, but I'm having a hard time applying it to mesh rendering.   Before DOD, I had a "Mesh" class with its vertices, normals, texcoords, etc. My renderer also had arrays of vertex and index buffers. This was your typical "Array of Structures" pattern.    Now, I'm trying to convert this to "Structure of Arrays" but I'm hitting a wall when it comes to sending mesh data to the shaders. My vertex shader uses a StructuredBuffer for all the vertices. Here's how it looks like: struct Vertex { float3 position; float3 normal; float2 texcoord; }; StructuredBuffer<Vertex> vertexBuffer : register(t0); This encourages the "AoS" pattern. Before issuing a draw call, it forces me to upload a buffer of "Vertex" on the CPU, which is the opposite of what I want. Would shader performance be the same if I split the buffer in the shader into 3 StructuredBuffers, one for each vertex attribute? Am I doing all this for nothing in the end?
  7. Well I feel quite dumb now, your solution works perfectly. Thanks!
  8. I'm trying to port an old terrain renderer to d3d11 and to make the switch to instanced drawing. The number of instances, which in this case are terrain patches, is calculated with a quadtree on the CPU.    I have a list of positions for each terrain patch, and I'm trying to send it as a Buffer to my shader so that I can recover the positions with SV_InstanceID. I use DrawInstanced for the actual drawing. However, since my list is constantly changing, I can't create the buffer with a fixed size at the beginning and I guess creating a new one and setting its data each frame is a bad idea.   What would be the best approach here?   Thanks
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!