• Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

3 Neutral

About Ugly

  • Rank

Personal Information

  • Interests
  1. If you really want to save results, you could store the resultant transforms in an SSBO (or a texel storage unit or something) on your first pass, via vertex index, and grab them on your second. However, I get the feeling that the memory writes and reads will be slower than a few matrix multiplications, and that's not to mention you would need to have one of these objects per instance of your animated mesh. This approach also introduces a dependency between shadow map passes and your general pipeline. If you don't do this, both shaders can be executing at the same time. Typically, the majority of objects in a scene are not undergoing skeletal animation. For your general use case, I wouldn't worry about recalculating animations. Vertices are processed pretty fast. Don't worry about it. pcie x16 transfers at a rate of 4 GB/s, so ~67 mb/frame for a 60 fps target. A matrix is 64 bytes, and you're passing bone transforms. if we go ham and say you have 500 bones per model (YEESH!), you could still pass 10,000 full skeletons and have more than half of your PCIE bandwidth left over for the frame. I'm also a bit confused here. If you do the model transforms on the cpu, you have to pass not only a bunch of transformed verts, but now you have to pass every instance of a transformed mesh as a -separate mesh-, meaning you can't do instancing for that mesh now. yes. Edit: usually you have some float weights and integer bone indices (corresponding to the weights) per vert. You can store these as attributes (vec4+ivec4) or put them in a buffer and get them from a vert index attribute. I personally have used the second to keep my mesh format consistent and to make attaching arbitrary vertex data less of a horror for future development, obviously at the cost of a bit of performance
  • Advertisement