9

I've been using 24bit .png with Alpha, from Photoshop, and just tried a .psd which worked fine with OpenGL ES, but Metal didn't see the Alpha channel.

What's the absolutely most performant texture format for particles within SceneKit?

Here's a sheet to test on, if needs be.

It looks white... right click and save as in the blank space. It's an alpha heavy set of rings. You can probably barely make them out if you squint at the screen:

enter image description here

exaggerated example use case:

https://www.dropbox.com/s/vu4dvfl0aj3f50o/circless.mov?dl=0

enter image description here

// Additional points for anyone can guess the difference between the left and right rings in the video.

Confused
  • 6,048
  • 6
  • 34
  • 75
  • Thankyou for making me think my screen needed cleaning... And "performant" is a weasel word: Do you want fastest, most feature-laden or something else? – Roddy Sep 05 '15 at 15:10
  • Fastest. But I've added the texture so you can see if it goes all cruddy in whatever format is suggested. Obviously the goal is a hybrid of speed and quality, always, but the texture provided hopefully serves as some kind of baseline for quality considerations. Also just edited with an example use case video. – Confused Sep 05 '15 at 15:12

1 Answers1

3

Use a grayscale/alpha PNG, not an RGBA one. Since it uses 16 bits per pixel (8+8) instead of 32 (8+8+8+8), the initial texture load will be faster and it may (depending on the GPU) use less memory as well. At render time, though, you’re not going to see much of a speed difference, since whatever the texture format is it’s still being drawn to a full RGB(A) render buffer.

There’s also PVRTC, which can get you down as low as 2–4 bits per pixel, but I tried Imagine’s tool out on your image and even the highest quality settings caused a bunch of artifacts like the below:

PVR artifacts

Long story short: go with a grayscale+alpha PNG, which you can easily export from Photoshop. If your particle system is hurting your frame rate, reduce the number and/or size of the particles—in this case you might be able to get away with layering a couple of your particle images on top of each other in the source texture atlas, which may not be too noticeable if you pick ones that differ in size enough.

Noah Witherspoon
  • 57,021
  • 16
  • 130
  • 131
  • So other than loading and compression, there's no performance difference between textures once on the device because the iOS GPUs always make it the exact same type of RGB(A)? – Confused Sep 07 '15 at 00:56
  • As far as I know, yes. – Noah Witherspoon Sep 08 '15 at 04:28
  • I've been doing some reading about different formats with lower bit depths, but not as radically low as PRVTC. Like 4bits per colour, and the like. Is there anyway that using a 4bit per colour texture could double the speed of Additive Blending over an 8bit per colour texture format?... obviously IF the GPU can store and use 4bit as 4bit. But this kind of research is really hurting my head. Imagination docs aren't made for morons like me. – Confused Sep 08 '15 at 04:31
  • There was one format I came across that was 1 bit for colour, and 8bits for alpha, that sounded dreamy for something like this, but it doesn't appear to be on iOS devices. – Confused Sep 08 '15 at 04:33
  • 1
    @Confused If you do try using PVRTC I suggest that in regions where it goes from Alpha==0 to Alpha!=0 that you try to limit the colour change as much as possible. For example, that texture has lots areas of RGB=0xFFFFFF with varying levels of A>0 *but* as soon as Alpha hits 0, the RGB seems to jump to #EFEFEF. Every change like that represents more information that the compressor has to try to squash into the limited available space. If you're using (SrcA, 1-SrcA) blends, you won't see #EFs anyway, so replace with #FFs. FWIW, IMG's PVRTextool has a good viewer for this sort of thing. – Simon F Sep 08 '15 at 10:36
  • This seemingly odd way to not use white for 'white' makes for a subtle little extra glow/pop around the edge of geometric shapes when using additive blend. It makes the edges sexier, in subjective terms. I can see what you're saying though, it is asking much more of the compression in a low bit space. – Confused Sep 08 '15 at 17:15
  • 1
    I don’t think a different texture bit depth is going to have a noticeable effect on the rate at which you can draw them—as I said, they’re being drawn to a full RGB(A) buffer. You may be able to get slight speed improvement by changing the buffer the SCNView uses to RGB565 (16-bit) instead of RGBA (32-bit), but it’ll come at the cost of some visual quality. – Noah Witherspoon Sep 08 '15 at 17:16
  • How do i change that buffer? – Confused Sep 12 '15 at 23:31
  • 1
    SCNView doesn’t provide a way to do that, so you’ll need to set up a CAEAGLLayer or GLKView to draw into (Metal [only supports RGBA](https://developer.apple.com/library/prerelease/ios/documentation/Animation/Reference/CAMetalLayer_Ref/#//apple_ref/occ/instp/CAMetalLayer/pixelFormat)), then set its `drawableProperties` or `drawableColorFormat` to use `kEAGLColorFormatRGB565` or `GLKViewDrawableColorFormatRGB565` respectively. Then, use an [SCNRenderer](https://developer.apple.com/library/prerelease/ios/documentation/SceneKit/Reference/SCNRenderer_Class/index.html) to render your scene into it. – Noah Witherspoon Sep 13 '15 at 00:05