I am optimizing my 2D mobile game. There are many sprites with POT size all over the game and I have filled their Packing Tag to enable batching and also checked their Generate Mip Maps checkbox. All these sprites have uniform scales in the game and most of them are (1,1,1).
What I intend to do is to minimize the number of Batches in the game.
What I want to figure out is how mipmaps affect the number of batches in a 2D game?
This is what I have tried:
I copied two sprites several times with different but uniform scales and reported the number of batches.
The circle has POT size and mipmap enabled; The square is not, it's just a sprite; Both have the same packing tag, so they reside in different atlases.
Also checking or unchecking Static for these game objects does not change anything.
3 batches when two different sprites are drawn
7 batches when two different sprites are drawn but in a little bit different positions
1 batch when only one mipmap sprite is drawn
1 batch when only one non-mipmap sprite is drawn. the positions of the game objects are the same as 1st test case where there were 7 batches.
Related
I am creating a 3D reservoir model which looks like this.
It's made of hundreds of thousands of cells with outline. The outline is needed for all cells underneath, because there is an IJK filter used to hide cells on any level and thus show the rest. Once the model is rendered, it shouldn't need to be updated in terms of position or scale.
That's enough about the background. The approach I'm using is creating one large geometry, which stores all vertices cross the reservoir in one triangle strip. It also stores IJK index for each cell, so the IJK filter works in shader level. This should create the mesh part. Then I create another object to draw all outlines using one THREE.LineSegments.
The approach works pretty well for small amount of cells, but for large data set, frame rate drops.
I'm proposing another way of doing this by barycentric outline and instancing drawing. Barycentric outline drawing removes the extra LineSegment object, since it draws outline in fragment shader. However, it comes with drawbacks. Because of the missing of geometry shader in WebGL, I have to use full triangle rather than triangle strip to store barycentric coordinates for each vertex. I'm ok with this extra memory usage, if instanced drawing can boost the performance.(?) That's to say, I draw a cube with outline, and I create as many instances as I need and put them in right position.
I am wondering if this approach is indeed gonna increase the performance theoretically. Any thoughts are welcomed!
Ok I think I am gonna answer this question myself.
I implemented the change based on above ideas and it works pretty good compared to the original version.
Let's put the result first: this approach has no problem rendering hundreds of thousands of cells at reasonable frame rate. My demo contains 400,000 cells, with the frame rate at 50 fps in worst case, running on my Nvidia 1050Ti card and 4k monitor. For comparison, if I draw 400,000 cells in the previous version, the frame rate could drop to 10 fps.
This means using instanced drawing for a large object is faster than composing a single large geometry. For rendering performance, the instanced cube is rendered only one side, while triangle-stripped cube is two-sided. Once I can draw a single unit cube with ideal outline, I can transform it to any places in "any" shape in vertex shader. But of course instanced drawing comes with its restrictions: each cell doesn't have to be at same shape, but has to have same number of vertices, faces, etc; I lost control to change vertex color...
As for memory usage, the new approach actually use less. I provide position for 8 vertices, instead of 14, in each cell. Even though the first unit cube has 36 vertices, I can use its unit position as index, for subsequent instances. That is, for 36 unit vertices (0/1, 0/1, 0/1), I only need to provide 8 real positions.
Hope this helps for people who want to implement the same optimization.
I'm having trouble with the performance of A-Frame and all I tried had no effect. On the A-Frame website in Best Practices - Performance the following is mentioned:
Limit the number of faces and vertices on models.
This model has nearly 100k vertices and 30k faces. How can I reduce the number of faces and/or vertices? It is a requirement that the user can interact with every box in the model separately, e.g. by changing its color or transparency or position. Is there a way to create a mesh or whatever and still having full interaction with every element on its own?
Besides that, I have no idea how to improve performance. The scene has no lights, textures, collisions, raycasters and all the other heavy stuff. These are just some boxes ...
The problem in this scene is not the number of vertices or faces (100k and 30k respectively are fine), but the size of the scene graph and the number of GPU draw calls. There are 2400 <a-box/> elements, each requires a separate draw call, and that is too many. The number of draw calls should be as low as possible, ideally < 100.
To keep all 2400 boxes interactive, you'll need to either (1) create a custom component that puts all boxes into a single THREE.BufferGeometry and changes vertex positions and colors within geometry.attributes.position and geometry.attributes.color, or (2) use a technique like instancing. Both will require some custom JS, not just HTML markup, as they're not built into A-Frame as components.
I have to draw a great collection of spheres in a 3D physical simulation of a "spring-mass" like system.
I would like to know an efficient method to draw spheres without having to compile a display list at every step of my simulation (each step may vary from milliseconds to seconds, depending on the number of bodies involved in the computation).
I've read that vertex-buffer objects are an efficient method to draw objects which need also to be sometimes updated.
Is there any method to draw OpenGL spheres in a way faster than glutSolidSphere?
Spheres are self-similar; every sphere is just a scaled version of any other sphere. I see no need to regenerate any geometry. Indeed, I see no need to have more than one sphere at all.
It's simply a matter of providing the proper scaling matrix. I would suggest a sphere of radius one centered at the origin for your display list or buffer object mesh. Then you can just transform it to different locations, using a scale to set the new radius.
I would like to know an efficient method to draw spheres without having to compile a display list at every step of my simulation (each step may vary from milliseconds to seconds, depending on the number of bodies involved in the computation).
Why are you generating a display list at all, if the geometry you put into is is dynamic. Display lists are meant for static geometry that never or only seldomly changes.
I've read that vertex-buffer objects are an efficient method to draw objects which need also to be sometimes updated.
Actually VBOs are most efficient with static geometry as well. In general you want to keep the number of actual geometry updates as low as possible. In your case the only thing updating are the positions (and maybe the size) of the spheres. This is a prime example for instanced drawing. However this also works well, with updating only a uniform or the transformation matrix and do the call drawing a sphere.
The idea of Vertex Arrays and VBOs is, that you draw a whole batch of geometry with a single call. A sphere would be such a batch.
I'm deciding if I want to create a map of multiple textures of my entire scene into several 1024x1024 texture atlases. Is it much of a gain at all to have fewer, larger textures so that you can make less GL render calls, albeit with the same number of overall triangles? Is this something that's common?
In my case, I'm targeting an iPad with about a 5,000 triangle scene with 16 textures. Given the distribution I'm looking at around 5x more calls to glDrawArrays if I don't combine.
I come from a 2D animation background and so when ever I us an animated sequence I prefer to use a sequence of images. To me this makes a lot of sense because you can easily export the image sequence from your compositing/editing software and easily define the aspect.
I am new to game development and am curious about the use of a sprite sheet. What are the advantages and disadvantages. Is file size an issue? - to me it would seem that a bunch of small images would be the same as one massive one. Also, defining each individual area of the sprites seems time cumbersome.
Basically, I dont get why you would use a sprite sheet - please enlighten me.
Thanks
Performance is better for sprite sheets because you have all your data contained in a single texture. Lets say you have 1000 sprites playing the same animation from a sprite sheet. The process for drawing would go something like.
Set the sprite sheet texture.
Adjust UV's to show single frame of animation.
Draw sprite 0
Adjust UV's
Draw sprite 1
.
.
.
Adjust UV's
Draw sprite 998
Adjust UV's
Draw sprite 999
Using a texture sequence could result in a worst case of:
Set the animation texture.
Draw sprite 0
Set the new animation texture.
Draw sprite 1
.
.
.
Set the new animation texture.
Draw sprite 998
Set the new animation texture.
Draw sprite 999
Gah! Before drawing every sprite you would have to set the render state to use a different texture and this is much slower than adjusting a couple of UV's.
Many (most?) graphics cards require power-of-two, square dimensions for images. So for example 128x128, 512x512, etc. Many/most sprites, however, are not such dimensions. You then have two options:
Round the sprite image up to the nearest power-of-two square. A 16x32 sprite becomes twice as large with transparent pixel padding to 32x32. (this is very wasteful)
Pack multiple sprites into one image. Rather than padding with transparency, why not pad with other images? Pack in those images as efficiently as possible! Then just render segments of the image, which is totally valid.
Obviously the second choice is much better, with less wasted space. So if you must pack several sprites into one image, why not pack them all in the form of a sprite sheet?
So to summarize, image files when loaded into the graphics card must be power-of-two and square. However, the program can choose to render an arbitrary rectangle of that texture to the screen; it doesn't have to be power-of-two or square. So, pack the texture with multiple images to make the most efficient use of texture space.
Sprite sheets tend to be smaller
files (since there's only 1 header
for the whole lot.)
Sprite sheets load quicker as there's
just one disk access rather than
several
You can easily view or adjust multiple frames
at once
Less wasted video memory when you
load the whole lot into one surface
(as Ricket has said)
Individual sprites can be delineated by offsets (eg. on an implicit grid - no need to explicitly mark or note each sprite's position)
There isn't a massive benefit for using sprite sheets, but several small ones. But the practice dates back to a time before most people were using proper 2D graphics software to make game graphics so the artist workflow wasn't necessarily the most important thing back then.