Hi, I have very little experience with Unity, so I can't tell you what you options there are. I have, however, give some insights on your questions from a general point of view.
Firstly, there are only two cases where texture atlases can be beneficial nowadays:
1. Reduce draw calls. By combining textures into one, more things can be drawn with one draw call. This means that they draw calls also need to have the same render states, the same vertex and index buffers, the same shaders, and if instancing is not available, the same shader parameters.
Basically, when draw calls are completely identical, except for their bound textures, they could be combined, saving on some of the overhead. There are very few cases of this is actually the case, so you should go ahead and analyze your typical scenes to estimate what the possible gains are.
Also, when the platform has texture arrays or bindless textures, use these methods instead.
2. Reduce texture memory requirements. In most cases today, texture atlases actually will need more memory than individual textures. If you're targeting platforms that have limitations like only square texture, only POT ("power or two") texture dimensions or mipmapping only for POT textures, atlases can be beneficial.
None of the platforms have any of these limitations IIRC, definitely not PC.
Also, if your textures have already been manually combined by the artist, as shown in this image texture space is used very efficiently, so that can be beneficial. But there's no good way to do these automatically and it's quite difficult to get right manually as well. Those have the additional advantage of reducing draw calls as well.
Texture atlases have a lot of downside. They are a PITA to create and manage and they are prone to artifacts due to filtering and through mipmapping, so in my opinion they are rarely worth the effort.
On to your questions:
Ad 1. Modern 3D games won't use texture atlases at all, for the reasons given above. If they do, they make them as big as possible, limited only by hardware capabilities and actual needs.
Ad 2. Atlases are exactly like normal textures, so all limitations for textures apply to atlas textures as well, plus a few additional ones. I know of no recent platform that would require square textures or performance benefits for square textures. The performance hit that Unity might be talking about is, that when it encounters a platform with only square textures, it has to make all non-square textures square on the fly, increasing load times, memory usage and texture memory pressure. But a platform like that would be an ancient one anyways...
Ad 3. It's up to you how you organize your atlases. Remember, your goal is to reduce draw calls. You can put leave and trunk texture in separate atlases and use them in two draw calls, you can put them in the same atlas and use them in two draw calls, no difference in number on draw calls. The latter method _may_ save one texture switch, if the draw calls are sequential, but that would come with a render state and possible shader switch as well, so not much upside.
Or, you could put them in the same atlas and draw them in one call, using the semi-transparent settings. You save one draw call, but render the opaque part inefficiently and possibly with artifacts. Many options, none of them are easy wins.
Ad 4. Very few savings possible by grouping them. In addition, I guess these armor pieces might have different meshes anyways, so it's not possible to combine these draw calls in the first place.
Ad 5. Yes, things that are likely to be used by the same shader, vertex/indexbuffer and renderstates, and are rendered in sequence, so they can be combined. Not much usually fits that bill.
Here are a few things that come to mind where texture atlases might be beneficial:
- vegetation / grass
- particle systems
- gui, menus and other 2d elements
In short, I think you'd be better off finding something else to increase performance. Did you do measurements? Are you sure that draw calls are your #1 performance killer? PCs nowadays can handle quite a lot of those with no problems...
If you're looking for speed, I recommend LZ4 (http://en.wikipedia.org/wiki/LZ4_(compression_algorithm)), if you're looking for high compression LZMA is pretty much the best freely available algorithm (as stated above). If you want a good trade off between those, zlib is still pretty competitive.
If WinRAR is faster than your LZ77 implementation, then your LZ77 implementation is very very slow.
In your case, all the pointers point to a const object, meaning you can't change the object through that pointer. You can, however, have the pointer point somewhere else, as is evident from the assignment of mD3dscene.
If you want the pointer itself const, you have to put a const after the *.
Examples: int * ptr; // non const pointer to non const object const int * ptr; // non const pointer to const object int const * ptr; // non const pointer to const object (same as above) int * const ptr = something; // const pointer to non const object const int * const ptr = something; // const pointer to const object int const * const ptr = something; // const pointer to const object (same as above)
I think these are all cases and I hope that helps!
Posted by Rattenhirn
on 23 February 2014 - 05:55 AM
data compression means to move data from the space dimension to the time dimension...
From Wikipedia: "Lossless compression reduces bits by identifying and eliminating statistical redundancy."
So nothing is moved between dimensions, whatever that might even mean in this case.
Maybe you try to space/time trade offs that are often the case with CS algorithms, including compression. For instance, a better compression rate will typically take a longer time. So by spending more time working on the data one can save space or, vice versa, by using more space, one can cut down the processing time.
Firstly, many companies or teams do not distinguish sharply between gameplay programmers and other programmers. The skillsets overlap too much to make that a useful distinction anyways. It's rather an affinity towards certain kinds of problems.
Secondly, scripting languages are usually only available for very specifc domains. Like the GUI, AI scripting or cutscenes. And they are supposed to be used by non-programmers. The reason you can script everything in engines like UDK and Unity is that they do not like giving out the source code or native APIs, making scripting pretty much the only option.
Thirdly, there's nothing wrong with knowing C++. I'd say, it's probably one of the most useful programming languages to know, even if you don't use it, as it gives a lot of insight into how programming languages do things and what the costs of certain features are.