2
$\begingroup$

I'm writing a CAD program in vulkan. In my current design, I have line paths represented as large vertex buffers for rendering. I would like to implement an algorithm for extruding the path outwards, based off of cross products. Ideally I would like to implement this algorithm within a compute shader, using the vertex buffer in place of a storage buffer. The algorithm would work like this: for each vertex in original path, calculate cross product based off of the two surrounding vertices in the buffer, then normalize and multiply by a scalar.

I'm fairly certain that this could be done by copying the vertex buffer to a storage buffer temporarily, but I doubt that's optimal, unless it's not actually physically copied. I don't see why I should move large chunks of data from VRAM to VRAM like that. It would probably, be faster to implement this algorithm locally on the CPU in that case. I don't have much experience using compute shaders; any input is appreciated.

Improve this question
$\endgroup$
2
  • 3
    $\begingroup$ I don't have experience with Vulkan, but in OpenGL there's nothing to stop you binding the same buffer as a a vertex array buffer and a shader storage buffer at the same time, you just need to set memory barriers appropriately. I'd be surprised if Vulkan didn't let you do this. Presumably though you'll want to make a fresh copy of the data in the compute shader anyway? Like reading your original buffer and writing to a new one? Otherwise you'll be cross-producting vertices that may have already been transformed. $\endgroup$
    – russ
    Jul 13, 2018 at 10:38
  • $\begingroup$ Vulkan allows buffers to be created with multiple uses in mind. So (keep in mind I am not checking the spec for compartbility here) you could potentially use VK_BUFFER_USAGE_VERTEX_BUFFER_BIT | VK_BUFFER_USAGE_STORAGE_BUFFER_BIT when the buffer is created. Then you can use the same buffer for both uses, but it is also up to you to make sure you don't step on your own toes. I have done something similar with images and it worked. A lot depends on if you plan to write an equal number of output for each input, and if you want to save the original data. $\endgroup$
    – pmw1234
    Aug 2, 2020 at 22:59

1 Answer 1

Reset to default
1
$\begingroup$

You will need a new chunk of memory for the new surface anyway, so why not read from the original and store directly in the result.

Having precomputed normals will reduce a lot of the computation requirements though (especially needing to find&read each neighbour), the user action of the extrusion will probably be interactive so you will have multiple frames with different extrusion amounts but the normals of the original surface won't change. Having the normals be around will likely be helpful for other operations as well. You could make the temporary transformed geometry just a vertex shader trick as well and only commit the result once needed.

Computing normals is much simpler by going face per face and then summing the the non-normalized normals per vertex and normalizing after.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.