3D object order can matter

[guest]

I keep getting caught out by this, so perhaps if I write it down I'll remember it (who am I kidding?!). One would not expect the order in which 3D objects are specified (i.e. the order in which they are listed in the arrays passed to PROC_render) to matter - after all the GPU has to plot them in Z-order anyway to ensure that foreground objects occlude background objects. However there appears to be an important exception when it comes to objects with transparent (or partially transparent) textures.

Ordinarily, 3D objects (whether plain-coloured, texture-mapped or having a material) are opaque and any object(s) 'behind' will not be visible. However it is possible to specify a texture with an alpha-channel, in which case regions of the object can be made see-through (for example one might model a wall as a simple plane object but use the texture-map's alpha channel to create windows). This technique is used in the 'bbcowl.bbc' Rotating World demo in which the land masses on the 'far side' can be seen.

It appears to be necessary to order the objects in the arrays so that the object with the transparent texture is listed after any objects that need to be seen 'through' it. If not, the alpha channel seems to be ignored and the object treated as opaque again. The particular example, which confused me for ages yesterday, was a situation in which there were three objects, the second of which had a transparent 'window'. The first object could be seen through this window, but the third object couldn't!

So if you have any objects with transparent textures, list them last. Note that the texture map's alpha channel is not enabled by default; to enable it one must add the following code after the call to FN_initd3d or FN_initgl:

BB4W (where device% is the value returned from FN_initd3d):

Code: Select all

      SYS!(!device%+200), device%, 27, 1 : REM ALPHABLENDENABLE
      SYS!(!device%+200), device%, 19, 5 : REM SRCBLEND
      SYS!(!device%+200), device%, 20, 6 : REM DSTBLEND

BBCSDL:

Code: Select all

      GL_BLEND = &0BE2
      GL_SRC_ALPHA = &0302
      GL_ONE_MINUS_SRC_ALPHA = &0303
      SYS "glEnable", GL_BLEND, @memhdc%
      SYS "glBlendFunc", GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA, @memhdc%

[David Williams]

Thanks for that, it's useful to know (especially given my current project!).


David.
--

[DDRM]

Yes, I noticed this behaviour when playing with partial transparency for a plane propeller - I couldn't work out why it didn't seem to be transparent, but it was because the things behind it weren't being plotted!

My guess it that it would impose an unacceptable overhead when plotting later objects to have to check not only whether they are behind something already hidden, but also whether some or all of that object was transparent.

I guess the moral of the story is plot things which are partially transparent last, but there are inevitably going to be problems in a scene where multiple objects have transparent elements...

Best wishes,

D