Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

One big texture for everything VS little textures per obj.

Discussion in 'iOS and tvOS' started by col000r, Nov 5, 2008.

  1. col000r

    col000r

    Joined:
    Mar 27, 2008
    Posts:
    698
    Please help me understand the way unity's engine works a little better:

    Is it better to have one big 2048x2048 texture that every object uses (even if every object uses only a little part of it), or should each object have it's own little texture? And why, or why not? :]

    I have a fairly small scene where most of the objects are always on the screen. (or at least one object of each kind, so most of the texture atlas would be in use at any given moment).
     
  2. YayPlay

    YayPlay

    Joined:
    Nov 1, 2008
    Posts:
    11
    I am also new to Unity. But if I have understand it correct with iPhone and the unified memory of the prcoessor and the PoverVRchip. Its good to have as little texture/material/draw calls as possible.

    Meaning grouping objects together is better the many separate.

    And I presume that if the grouped object (which then acts as one mesh has a shared texure, cood tristripping meaninging no UV or VC seams it should speed up performance.

    On the other han the PoverVR chip works MUCH faster when using VQ packed textures and the smaller they are the quicker the data fetch for them is. But large VQ texure can get packing artifacts so I gues you have to balance that look agains performance.

    I also think that 1024x1024 is the larges tex size for the PovVR chip but I can be wrong.
     
  3. the_motionblur

    the_motionblur

    Joined:
    Mar 4, 2008
    Posts:
    1,774
    [edit] Ah - I missed that this is the iPhone section. Sorry. The following is rather general then.

    Personally I'd vote for the "several small textures" option. That's not something specific, though.

    If you have an object with it's own small texture you have more freedom.
    For instance you can assign different shaders for the different objects. That's not possible if you have one texture for a huge object.
    Also and more important you can re-use the object on a different scene. Doing so with the huge map could become a problem as you need to load the rest of the map together with your object. :)
    Small (seamless textures) can be tiled along a large object like a wall. That's not so easy to do if the texture sits inbetween others on a large map.

    Personally I also find it more easy to just change small maps.


    On the other hand, though:
    IF you have a fixed set of textures on an already existing large map and try assign parts of it to new objects that's absolutely okay. That way you can save memory.
    Your best option probably is to mix those techniques. Use small textures where apropriate and reuse large ones if you can.

    I hope that helped a little :)
     
  4. Brady

    Brady

    Joined:
    Sep 25, 2008
    Posts:
    2,474
    You'll definitely want to avoid lots of small textures. Material changes will, iirc, result in separate draw calls. According to my testing, if you go above about 25-30 draw calls per frame, you will cross the 30fps threshold and it will drop to about 15fps immediately. That's with a low-poly scene, so it's not a polygon issue, it's a draw call issue.
     
  5. col000r

    col000r

    Joined:
    Mar 27, 2008
    Posts:
    698
    Thanks for your answers! I also watched last year's performance optimization talk again...

    Let me try to summarize:

    Each material on each mesh causes one draw-call per frame, per light that affects it and per camera that sees it.



    If I have 1 mesh with 20 seperate textures, only ambient light, one camera, this will also result in 20 draw-calls. If I would combine the 20 textures into one atlas the scene would now only need a single draw-call.

    If I have 20 meshes with one texture each, only ambient light, one camera, this will result in 20 draw-calls. If I would combine all the textures into one big atlas, the scene would still require 20 draw-calls, even though all the objects would now use the same texture.

    The only way to optimize here would be to combine meshes. But you can only do that if your meshes aren't to move around independently from each other. Now does the mesh combiner script work on the iPhone? And would it be possible to break out a part of a combined mesh once it's needed to move independently? Or is it just not worth it thinking about this?


    So one more question: If I can't combine objects, does it make a noticeable difference if it samples from a huge texture atlas or from a lot of small images? Not loading time, but time to draw a texture that's already in memory.
     
  6. Brady

    Brady

    Joined:
    Sep 25, 2008
    Posts:
    2,474
    Combining does work. Breaking things up and putting them back together is something I'm trying to do at the moment and not having much success so far. I'll let you know if I get it working.
     
  7. jerrodputman

    jerrodputman

    Joined:
    Jun 4, 2008
    Posts:
    181
    @Brady: Have you made any progress with the re-combining efforts?

    The project I'm working on now will need to have lots of objects on the screen at a time, most of them using the same mesh and materials. I've been messing around with different solutions, and still haven't really found an elegant way to do it.
     
  8. Brady

    Brady

    Joined:
    Sep 25, 2008
    Posts:
    2,474
    Nope, not yet. You could always directly manipulate the combined mesh data, but that can be dodgy depending on how your meshes are organized. But if the objects are all static or move together, it shouldn't be a problem to combine them all at once. Having lots of things that move independently (even though they use the same mesh and material) is the rub. If the objects are REALLY simple, you could just manually modify the vertex positions in the combined mesh. If they're very complex at all, however, manually transforming the vertices may be way too slow.
     
  9. Dreamora

    Dreamora

    Joined:
    Apr 5, 2008
    Posts:
    26,601
    Just keep one thing in mind: 2048x2048 is not possible at all.
    The max texture size is 1024x1024 on the iphone
     
  10. jerrodputman

    jerrodputman

    Joined:
    Jun 4, 2008
    Posts:
    181
    @Brady: Yeah, I was concerned about having lots of independent moving objects. Unfortunately, I think it's just going to come down to old-fashioned tricks (i.e., having an armada of ships move as one, and then a few ships break off at a time to attack).

    Thanks for the reply.
     
  11. ReJ

    ReJ

    Unity Technologies

    Joined:
    Nov 1, 2008
    Posts:
    378
    Combining textures into atlases and combining meshes is always a good idea. For each separate mesh or mesh subset you pay not only the cost of OpenGLES render-call, but also Unity has to do work processing shader/material settings. That is something we are working to speed up, but even if super optimized it will bear some cost.

    In general I would advice to use as less different textures (combining them into atlas is the way, however you should be careful about PVRTC compression artifacts) and less different materials (same shader with different parameters is counted as different material) as possible. Even if you can't combine meshes, it will not increase performance for you today, but will open door for future optimizations.

    If you have lots of very small dynamic objects, you could try combining them into skinned mesh and animating bones. That might prove cheaper in some cases. At least it will be definitely cheaper than animating vertex data from scripts.
     
  12. bumba

    bumba

    Joined:
    Oct 10, 2008
    Posts:
    358
    so better a 1024 x 1024 texture atlas instead of 5 128 x 128 Textures
     
  13. jerrodputman

    jerrodputman

    Joined:
    Jun 4, 2008
    Posts:
    181
    @ReJ: Ah, so you guys do have some optimizations in the future regarding this. Excellent.

    I hadn't thought of using bones like that. We'll try it out and see how it goes. Thanks!
     
  14. col000r

    col000r

    Joined:
    Mar 27, 2008
    Posts:
    698
    wow, animating bones of one skinned mesh instead of many dynamic objects is an insanely clever idea...

    but I guess my current bottleneck is physics...

    EDIT: One more question: Is the vertex-lit shader faster than Diffuse Fast? I have no lights in my scene anyway, all baked lighting with ambient light up all the way.
     
  15. tgraupmann

    tgraupmann

    Joined:
    Sep 14, 2007
    Posts:
    828
    What kind of performance are you seeing when comparing mesh instances to the skinned mesh with bones idea?
     
  16. iPhone Guy

    iPhone Guy

    Joined:
    Oct 31, 2008
    Posts:
    42
    bumping this thread. Has anyone tried animating bones do you get a significant bump in perf? If so, what size are the objects?
     
  17. n0mad

    n0mad

    Joined:
    Jan 27, 2009
    Posts:
    3,732
    Bump.


    Something's questionning me :

    What is the advantage of TextureAtlas if it can't support PVRTC imported textures ?

    Actually on the iPhone, we only got the ARGB 32 option, but it's so huge I can't find a clear advantage for big games.
     
  18. Brady

    Brady

    Joined:
    Sep 25, 2008
    Posts:
    2,474
    It's not that you can't use PVRTC compressed textures for a texture atlas, it's just that you have to watch out for artifacts. But the advantage isn't in the compression, the advantage is in saving draw calls. If you have several separate textures, they have to be separate materials requiring separate draw calls. If you use an atlas, you can combine the objects into a single mesh and render them as a single draw call.
     
  19. n0mad

    n0mad

    Joined:
    Jan 27, 2009
    Posts:
    3,732
    Well, iPhone Unity keeps returning me "textureformat not supported in TextureAtlas" (or something very close to), when I place PVRTCs in the Texture2D[] member of packTextures() :)
     
  20. Brady

    Brady

    Joined:
    Sep 25, 2008
    Posts:
    2,474
    Make sure it is square and power of 2.
     
  21. n0mad

    n0mad

    Joined:
    Jan 27, 2009
    Posts:
    3,732
    I thought I was clean with that, but thanks to you I checked resolutions again, and Photoshop put an extra pixel width in 4 images.

    Thank you for your support Brady, didn't see that at all :)
     
  22. n0mad

    n0mad

    Joined:
    Jan 27, 2009
    Posts:
    3,732
    Ok ... a fake joy : every single bitmap is PNG imported to PVRTC 4bit, square (256x256 or 512x512), and it keeps telling me :

    "Unsupported format in compressed texture atlas."
     
  23. Brady

    Brady

    Joined:
    Sep 25, 2008
    Posts:
    2,474
    Hmmm... I'm not sure what it could be then... I'm using (and compressing) textures that match that very description without issue. Perhaps there's another import setting throwing it off? I'm not sure which one it might be. Anyone have any other ideas?
     
  24. n0mad

    n0mad

    Joined:
    Jan 27, 2009
    Posts:
    3,732
    I did another checkout : every Texture2D.format returns me the appropriate "PVRTC_4BPP_RGBA" string.

    here is the generating code :

    Code (csharp):
    1. _textureAtlas = new Texture2D(_AtlasSize,_AtlasSize);
    2. _spriteUVs = _textureAtlas.PackTextures(_textureArray, 0, _AtlasSize);
    where _textureArray is filled with some :

    Code (csharp):
    1. Resources.Load(_string) as Texture2D;
    (pseudocode)

    The log error points to the PackTextures() line.

    Concerning the imports settings, I only let the adjusted size and the format. Everything else is disabled.


    I'm confused .. :roll:
     
  25. Brady

    Brady

    Joined:
    Sep 25, 2008
    Posts:
    2,474
    I'm a bit confused as well... I'm not familiar with using PackTextures(), and I'm not sure why you are wanting to generate a texture atlas at runtime, and I believe PVRTC compression can only happen at build time.

    Is there a reason why you don't want to create your texture atlas in something like Photoshop and then just import that texture into Unity?
     
  26. n0mad

    n0mad

    Joined:
    Jan 27, 2009
    Posts:
    3,732
    Yes, I have to do that, because of dynamic skinning textures.

    In short, I'm willing to let the user choose his clothing texture and color =)


    That's kind to help me, but don't worry, I don't want to eat some precious time of you ;)

    Still investigating, I'll keep in touch with possible solutions, and I really appreciate your help.
     
  27. Brady

    Brady

    Joined:
    Sep 25, 2008
    Posts:
    2,474
    Well, I think the runtime nature of it pretty much precludes you from using PVRTC since that is done at build time. There's no way to PVRTC compress a texture at runtime to my knowledge.
     
  28. Eric5h5

    Eric5h5

    Volunteer Moderator Moderator

    Joined:
    Jul 19, 2006
    Posts:
    32,401
    That wouldn't be necessary...if you use PackTextures and all textures are already compressed to begin with, then the resulting atlas will also be compressed. However, I've never actually used it myself so I can't offer any advice. I wonder if it's been updated to work with PVRTC; the manual only mentions DXT.

    --Eric
     
  29. n0mad

    n0mad

    Joined:
    Jan 27, 2009
    Posts:
    3,732
    Yep, that's why I believed PVRTC wasn't supported :)

    And if it's the case, I can't find a real utility for packTextures() on iPhone ...


    Which means I would have to code my own Atlas packager :/


    edit : But Brady said he was using PVRTC compression on iPhone atlases.
    I think I'm lost :p
     
  30. n0mad

    n0mad

    Joined:
    Jan 27, 2009
    Posts:
    3,732
    Things are getting weirder and weirder ...

    I switched all my textures to a RGB 16 bit uncompressed format, everything works fine in the editor, but when I test it on the iPhone, there's no more textures.
    (they are all atlased)

    The console is returning :

    Texture is not accessable. (Filename: /Users/build/builds/unity-iphone-1.0.3/iphone-1.0.3/Projects/../Runtime/Graphics/Texture2D.cpp Line: 142)

    This, as many times as there are textures loaded into atlases.

    :roll: :roll:
     
  31. Eric5h5

    Eric5h5

    Volunteer Moderator Moderator

    Joined:
    Jul 19, 2006
    Posts:
    32,401
    Probably something to do with how textures have that checkbox now (as of 1.0.2) where you can set them to use less memory, in return for not being able to access them with GetPixel/SetPixel, which would include texture atlasing as well.

    --Eric
     
  32. n0mad

    n0mad

    Joined:
    Jan 27, 2009
    Posts:
    3,732
    Oh, that would be a really deeply hidden problem ...

    Checkin that asap.

    Thank you Eric.

    edit : problem solved. Thank you very much.
     
  33. iio

    iio

    Joined:
    Nov 21, 2009
    Posts:
    22
    I hate to partake in thread necromancy but this is stickied so my question is: did anyone complete the any bones anim vs many separate mesh tests? I have many ships in my game and wanted to know if I'm better off creating one large object and animating it or sticking with many smaller but separate meshes.
     
  34. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    Yeah I did. They're always faster for my game (to use bones, max 1 bone per vert influence). Dynamic batching seems to have the same speed hit, but is limited to less verts.

    Combining meshes = faster (for my game).

    There's reasons why it would be slower though, and I'll outline them here:

    1. if your ships are a high polycount, and not very many of them, it is faster to allow them to be culled. In this case, you shouldn't batch anything or skin anything since it'll still process them offscreen.

    2. if your ships are more than 300 verts and on screen at the same time, skinned mesh will usually be faster.

    3. if your ships are lower than 300 verts and may be off screen sometimes, then dynamic batching will usually be faster.

    These are my own tests, and you'll need to run your tests. As you can see, its very conditional if one method is faster than another method. you need to look at what your game does in detail.
     
  35. macdude2

    macdude2

    Joined:
    Sep 22, 2010
    Posts:
    686
    So right now in my game, I have about 60 separate different meshes that all use the same material. Would the combine children script do anything to speed up the scene and lower the draw calls? Thanks.
     
  36. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    I take it you didn't read my reply. You aren't able to have an answer without detailed tests with vert counts. If there's not many verts, dynamic batching is good if they will go offscreen.

    Combine children is fine for you if they are generally always on screen. Otherwise you're not gonna be able to cull them off screen.
     
  37. RichyVeron

    RichyVeron

    Joined:
    May 28, 2017
    Posts:
    1
    the solution to , multiple objects in one single mesh , using same materia (texture atlas too) .