Question about making meshes for spritesheets

Started by
6 comments, last by Hashbrown 5 years, 1 month ago

I have a spritesheet that consist of seven 50x37 pixel frames. I'm rendering the image onto a 1x1 unit quad. This is one of the frames outside of my engine:

ex.png

Everything is animating correctly but he looks thinner in my engine:

ex2.png

In order for my character to look the right proportions: I have to instantiate the quad mesh wider...since each frame is greater in width (50x37).


const model = Model.IndexedQuad(1.3, 1);

Only then everything looks great, still I eyeballed that 1.3 value.

ex3.png

 

My questions:

1) Does this mean I have to make a quad for every sprite that has different dimensions? For example, if I have four 50x20 characters, and three 20x30 characters: I'd need two quads for those different sizes?

Or should I use one 1x1 quad for all sprites and scale its transform relative to the frame size afterwards?  Not sure how to do this though. It's easier for me to instantiate a mesh for different sizes, but doesn't that mean binding more meshes?

2) Again, I'm eyeballing the size of the quad, but is there a way I can calculate the right size of the quad in normalized units? Considering that my character is 50x37 (in pixels). Maybe dividing width/height.

Oh and almost forgot to mention, I'm rendering each frame by passing a texture matrix to my shader. I'm not altering the uvs on the mesh.

Thank you very much for reading, hope I made sense!

 

Advertisement

You need to scale your quads to the actual pixel size of your screen. 1x1 in render space is not necessarily square on your screen.

This may be in part a repeat of what Irusan said (I'm not sure).

Assuming I'm understanding your question correctly (which I may not be), you don't need to rely on eyeballing to get the results you want. You can compute exact dimensions (e.g. for mesh data or transform scaling) by computing the aspect ratio of the source graphic and creating quads with the same aspect ratio (your mention of dividing width by height hints at this). That may seem obvious I suppose, so apologies if I'm misunderstanding the question.

Quote

 

Does this mean I have to make a quad for every sprite that has different dimensions? For example, if I have four 50x20 characters, and three 20x30 characters: I'd need two quads for those different sizes?

Or should I use one 1x1 quad for all sprites and scale its transform relative to the frame size afterwards?  Not sure how to do this though. It's easier for me to instantiate a mesh for different sizes, but doesn't that mean binding more meshes?

 

There are various ways you could do it. You could use multiple meshes, as you mentioned. That could result in multiple small meshes and an increase in the number of draw calls, but that might not be an issue, depending on the circumstances. Another approach that's fairly common (as far as I know at least) is dynamic batching with streamed mesh data.

53 minutes ago, Zakwayda said:

This may be in part a repeat of what Irusan said (I'm not sure).

Er, actually, I misunderstood slightly. Listen to Zakwayda :)

13 hours ago, Irusan, son of Arusan said:

Er, actually, I misunderstood slightly. Listen to Zakwayda :)

Thanks for you answer Irusan, it's appreciated.

 

14 hours ago, Zakwayda said:

This may be in part a repeat of what Irusan said (I'm not sure).

Assuming I'm understanding your question correctly (which I may not be), you don't need to rely on eyeballing to get the results you want. You can compute exact dimensions (e.g. for mesh data or transform scaling) by computing the aspect ratio of the source graphic and creating quads with the same aspect ratio (your mention of dividing width by height hints at this). That may seem obvious I suppose, so apologies if I'm misunderstanding the question.

There are various ways you could do it. You could use multiple meshes, as you mentioned. That could result in multiple small meshes and an increase in the number of draw calls, but that might not be an issue, depending on the circumstances. Another approach that's fairly common (as far as I know at least) is dynamic batching with streamed mesh data.

Excellent, making individual meshes is what I thought was a good idea. Thanks a lot for your answer.

I never heard of dynamic batching with streamed mesh data. I'm googling it right now, but I'm not sure what I'm looking for to be honest. Would have a link to some good documentation? Thanks again!

Quote

Excellent, making individual meshes is what I thought was a good idea. Thanks a lot for your answer.

Just to cover myself here, some people might argue against creating meshes (buffers) with very small amounts of data (like a quad). Also, if you have a lot of quads (e.g. hundreds) and are making a draw call per quad, that might have some performance implications, depending on the context.

That said, if the number of quads is modest and/or you don't encounter any performance issues, you might be able to get away with doing it this way.

Quote

I never heard of dynamic batching with streamed mesh data. I'm googling it right now, but I'm not sure what I'm looking for to be honest. Would have a link to some good documentation? Thanks again!

I don't have anything handy, but of the terms you could search for, 'sprite batching' might yield the best results :)

5 hours ago, Zakwayda said:

Just to cover myself here, some people might argue against creating meshes (buffers) with very small amounts of data (like a quad). Also, if you have a lot of quads (e.g. hundreds) and are making a draw call per quad, that might have some performance implications, depending on the context.

That said, if the number of quads is modest and/or you don't encounter any performance issues, you might be able to get away with doing it this way.

I don't have anything handy, but of the terms you could search for, 'sprite batching' might yield the best results :)

Excellent! You're right, in fact I added sprite batching opengl and I get tons of results.

Thanks again Zakwayda!

This topic is closed to new replies.

Advertisement