Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

3 Neutral

About Ugly

  • Rank

Personal Information

  • Interests

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Ugly

    How to start 3D game programming

    Yeah, Unity has bad PR, specifically because you only see its logo on unlicensed stuff, which usually sucks. Most people aren't game developers, and among the crowd that are, many aren't more than hobbyists, so their opinion on such things isn't really worth a damn anyways.
  2. Ugly

    How to start 3D game programming

    Unity is a fully featured game engine, and is definitely not "only good for the basics"! If you were looking to learn how to make a 3d engine, you can start with learnopengl.com for a renderer.
  3. 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

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!