If I render a big texture 1024x1024 but almost the texture is transparent, only about 40% of the texture have data (not transparent). Does it more slower than render a texture with less transparent part?
I have this question because when render a animation, it is more easy to set the pivot of sprite in the image itself, so when I render i only need to draw each sprite at the center of my object's position.
It is more performant, because your image will be smaller. But I doubt it will make a noticeable difference. So, the way you are doing it right now is good, thats how I do it.
Related
Can you please explain the difference between texture and sprite? When we zoom in a sprite, it appears blurry because it's basically an image. Is it the same for a texture?
I read this comment on the image below online:
The background layers are textures and not sprites.
Can someone explain?
Sprites and Textures are both images.
A Sprite is an image that can be used as a 2d object, which have coordinates (x, y) and which you can move, destroy or create during the game.
A Texture is also an image, but that will be used to change the appearence of an object. E.g. you can set a texture for the faces of a cube, a layer (like the background) or even a sprite. But as texture are not objects, you can't move them during the game.
Sprite is the image that is moving related to static images (for example background). Sprites are usually planes (rectangles) with texture on it. Sprites are used in 3D graphics for tricks such as Billboard or Impostor. In 2D games sprites are used instead of moving objects and also as backgrounds.
Texture is an raster image that is to be projected on polygonal object. It worth using textures each time when using polygons is expensive for given objects details (for example bullet dots)
I'm using sprites for an animated menu in my game.
I tried two methods:
Image Renderer: Replacing the image per frame with the sprite slice in the animation window
Sprite Renderer: Same method
I'm playing the sprite animation with no loop then rotating the transform on the z-axis.
The problem is that with the image the Screen Space overlay works well but the rotation of the transform causes the sprite to look glitchy and rough. With the sprite renderer however the Screen Space must be put to Camera and the sprites get placed between other assets in the world.
Example: http://postimg.org/image/436q9jvax/
Is there a way to either fix the roughness on the rotation using image or force the Camera Screen Space on top? My only concern with the 2nd option would be in relation to responsiveness for multiple devices.
The easiest fix was to apply "sorting layers" to the canvas with the sprite renderers on to keep it on top.
I did however incorporate #beuzel's idea about separate cameras in the end and opted for 2D sprites with physics instead of a 3D rendered animation on canvas.
http://postimg.org/image/6qmtiirb9/
Thanks for making the good sample. A fix for the menu intersecting the world is using a seperate camera for the GUI layer. The rough animation might be a pixel perfect setting in the sprite rendering (just guessing).
I don't have enough reputation points to write this as a comment.
I need to blur render but not whole, only fragments. Frozen "glass" shapes will flowed over (SVG animated transparent shapes over WebGl animation). The problem is local frozen effect. Whether is some effect composer or context.readPixels + FastBlur.js makes sense or maybe css + masks ? Thank you for help.
I did it:
WebGl shader blur (Three.js render passes) + mask texture (image = additional invisible canvas element where shapes are drawn). SVG is an independent element, but gives information about kind of shapes and positions for mask texture and displays shapes of course. A bit crazy but works and very fast.
Is it possible to render to FBO texture once and then use the resulting texture handle to render all following frames?
For example, in case I'm rendering a hard shadow map and the scene geometry and light position are static, the depth map is always the same and I want to render it only once using a FBO and then just use it after that. However, if I simply put a flag to render the depth texture once, the texture remains empty for the rest of the frames.
Is FBO get reallocated after rendering a frame has been complete? What would be the right way to preserve rendered texture for rendering of the following frames?
Rendering to a texture is no different than if you had uploaded those pixels to the texture in the first place. The contents of a texture do not magically disappear. A texture's contents are changed when you change them. This could be by uploading data to the texture, or by setting one of the texture's images to be used for framebuffer operations (clearing, rendering to it, etc).
Unless you do something to explicitly change the data stored in a texture, it won't change.
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.