TGEA 1.7.1 Atlas with 8 blended textures?
by Matt Kronyak · in Torque Game Engine Advanced · 09/19/2008 (2:32 am) · 12 replies
According to a comment by Matt Fairfax in this post (www.garagegames.com/mg/forums/result.thread.php?qt=73599) more than 4 blended textures should be possible fairly easily due to recent changes in 1.7.
We performed a test with atlasGenerateBlenderTerrain and it was able to accept 8 source images without a problem. The console output also confirmed this:
It also looks like TGEA was able to recognize this data when it loaded the Atlas terrain:
I'm looking for some guidance on how to get more than 4 blended textures rendered. I see several for loops that go through 4 fixed iterations in AtlasInstanceGeomTOC and AtlasInstance. Might any of these need to be modified? Is there perhaps a shader that needs to be modified?
Any help would be appreciated.
We performed a test with atlasGenerateBlenderTerrain and it was able to accept 8 source images without a problem. The console output also confirmed this:
o Generating config chunks...
- Virtual texture size is 32768
- Found 8 source images specified.
* Source #0 = 'game/data/terrain/grass2'
* Source #1 = 'game/data/terrain/rock3'
* Source #2 = 'game/data/terrain/rock1'
* Source #3 = 'game/data/terrain/rock4'
* Source #4 = 'game/data/terrain/grass5'
* Source #5 = 'game/data/terrain/tile6'
* Source #6 = 'game/data/terrain/tile7'
* Source #7 = 'game/data/terrain/tile8'
AtlasFile::waitForPendingWrites - Waiting for pending output to finish.It also looks like TGEA was able to recognize this data when it loaded the Atlas terrain:
AtlasClipMapImageCache_Blender::registerSourceImage - couldn't locate texture 'C:/projects/DevRoot/Trunk/TGEA/Level Editor/game/data/terrain/game/data/terrain/tile6' for blending. AtlasClipMapImageCache_Blender::registerSourceImage - couldn't locate texture 'C:/projects/DevRoot/Trunk/TGEA/Level Editor/game/data/terrain/game/data/terrain/tile7' for blending. AtlasClipMapImageCache_Blender::registerSourceImage - couldn't locate texture 'C:/projects/DevRoot/Trunk/TGEA/Level Editor/game/data/terrain/game/data/terrain/tile8' for blending. Allocating a 512 px clipmap for a 32768px source texture. - 6 base clipstack entries, + 1 cap. - Using approximately 9.310000MB of texture memory. AtlasInstance2::onAdd - took 531 ms to fill clipmap with texture data. AtlasInstanceGeomTOC::loadCollisionLeafChunks - Loading leaf collision chunks... AtlasInstanceGeomTOC::loadCollisionLeafChunks - DONE.
I'm looking for some guidance on how to get more than 4 blended textures rendered. I see several for loops that go through 4 fixed iterations in AtlasInstanceGeomTOC and AtlasInstance. Might any of these need to be modified? Is there perhaps a shader that needs to be modified?
Any help would be appreciated.
#2
First, to recap, atlasGenerateBlenderTerrain accepts and stores more than 4 source images without a problem when generating the terrain.
Second, to ensure that the Atlas instance is aware of all of the source images it was generated with I added a line to output the number of source images in bool AtlasInstance::onAdd(), right after S32 srcCount = dAtoi(srcImageCount); and just before the loop that does work with the images: for(S32 i=0; i (both in atlas\runtime\atlasInstance2.cpp).
This simple line looks like:
This correctly writes the number of source images to the log (in this case, 8).
Third, to ensure that registerSourceImage is being called for every texture on the atlas terrain I added a line to ClipMapBlenderCache::registerSourceImage in clipmap\clipMapBlenderCache.cpp to output the path \ filename of each source image as it is registered:
This verifies that this information at least exists in the terrain and in my test terrain with 8 textures it outputs all of the file names correctly.
At this point it appears that the information for more than 4 textures is both being read and written correctly to the Atlas file itself.
The next set of changes I made were to try to get the rendering code to use this data.
In clipmap\clipMapBlenderCache.cpp in ClipMapBlenderCache::doRectUpdate, just after
GFX->setShader(mOnePass);
GFX->setAlphaBlendEnable(false);
I changed
Then a little further down in the same method I changed:
Finally, in atlas\runtime\atlasClipMapBatcher.cpp, in AtlasClipMapBatcher::renderClipMap() I changed the first loop that says for(S32 i=0; i<4; i++) to for(S32 i=0; i<8; i++) and changed all subsequent loops in that function that have a hard coded 4 to have a hard coded 8. I also changed Vector mRenderList[4]; to Vector mRenderList[8]; in atlasClipMapBatcher.h.
With these changes I can see that the data I am looking for exists, and the rendering changes appear to make sense (using the actual source image collection rather than just arbitrarily trying to use the first 4 textures) but the textures are still not appearing correctly.
I'll continue to work on this more, but any insight anyone might have to getting this to work would be appreciated.
09/29/2008 (10:32 pm)
I've been digging through this more over the past week and while I haven't gotten more than 4 terrain textures working yet I think I have made some headway. I've made a few changes that looked appropriate and don't result in any unexpected behavior at this point so it seems that progress is being made.First, to recap, atlasGenerateBlenderTerrain accepts and stores more than 4 source images without a problem when generating the terrain.
Second, to ensure that the Atlas instance is aware of all of the source images it was generated with I added a line to output the number of source images in bool AtlasInstance::onAdd(), right after S32 srcCount = dAtoi(srcImageCount); and just before the loop that does work with the images: for(S32 i=0; i
This simple line looks like:
Con::errorf("AtlasInstance2::onAdd - SOURCE IMAGE COUNT %d!", srcCount);This correctly writes the number of source images to the log (in this case, 8).
Third, to ensure that registerSourceImage is being called for every texture on the atlas terrain I added a line to ClipMapBlenderCache::registerSourceImage in clipmap\clipMapBlenderCache.cpp to output the path \ filename of each source image as it is registered:
Con::warnf("AtlasClipMapImageCache_Blender::registerSourceImage - REGISTERING %s", filename);This verifies that this information at least exists in the terrain and in my test terrain with 8 textures it outputs all of the file names correctly.
At this point it appears that the information for more than 4 textures is both being read and written correctly to the Atlas file itself.
The next set of changes I made were to try to get the rendering code to use this data.
In clipmap\clipMapBlenderCache.cpp in ClipMapBlenderCache::doRectUpdate, just after
GFX->setShader(mOnePass);
GFX->setAlphaBlendEnable(false);
I changed
GFX->setTexture(2, (0 < mSourceImages.size()) ? mSourceImages[0] : NULL);
GFX->setTexture(3, (1 < mSourceImages.size()) ? mSourceImages[1] : NULL);
GFX->setTexture(4, (2 < mSourceImages.size()) ? mSourceImages[2] : NULL);
GFX->setTexture(5, (3 < mSourceImages.size()) ? mSourceImages[3] : NULL);toS32 sourceImagesSize = mSourceImages.size();
for(S32 i = 0; i < sourceImagesSize; i++)
{
GFX->setTexture(i + 2, (0 < sourceImagesSize) ? mSourceImages[i] : NULL);
}Then a little further down in the same method I changed:
GFX->setTexture(2, (i * 4 < mSourceImages.size()) ? mSourceImages[i * 4] : NULL);
GFX->setTexture(3, (i * 4 + 1 < mSourceImages.size()) ? mSourceImages[i * 4 + 1] : NULL);
GFX->setTexture(4, (i * 4 + 2 < mSourceImages.size()) ? mSourceImages[i * 4 + 2] : NULL);
GFX->setTexture(5, (i * 4 + 3 < mSourceImages.size()) ? mSourceImages[i * 4 + 3] : NULL);tofor(S32 j = 0; j < sourceImagesSize; j++) GFX->setTexture(2, (i * 4 + j < sourceImagesSize) ? mSourceImages[i * 4 + j] : NULL);
Finally, in atlas\runtime\atlasClipMapBatcher.cpp, in AtlasClipMapBatcher::renderClipMap() I changed the first loop that says for(S32 i=0; i<4; i++) to for(S32 i=0; i<8; i++) and changed all subsequent loops in that function that have a hard coded 4 to have a hard coded 8. I also changed Vector
With these changes I can see that the data I am looking for exists, and the rendering changes appear to make sense (using the actual source image collection rather than just arbitrarily trying to use the first 4 textures) but the textures are still not appearing correctly.
I'll continue to work on this more, but any insight anyone might have to getting this to work would be appreciated.
#3
I haven't got time to check this out just yet as my computer experienced a HDD corruption (still waiting for the installation media from HP).
What do you mean that the "the textures are still no appearing correctly"? Are they not visible at all or are the somehow being drawn in wrong order etc.?
Where are you defining the second blend map, or how are you defining the extra 4 blending layers/channels for the new textures? I means simply getting the 8 textures loaded isn't enough, you'll alsol need to tell the shaders to actually use them and supply some info on where to apply them (maybe you accounted that already but I can't make it out from the posted additions).
09/29/2008 (11:36 pm)
Hello.I haven't got time to check this out just yet as my computer experienced a HDD corruption (still waiting for the installation media from HP).
What do you mean that the "the textures are still no appearing correctly"? Are they not visible at all or are the somehow being drawn in wrong order etc.?
Where are you defining the second blend map, or how are you defining the extra 4 blending layers/channels for the new textures? I means simply getting the 8 textures loaded isn't enough, you'll alsol need to tell the shaders to actually use them and supply some info on where to apply them (maybe you accounted that already but I can't make it out from the posted additions).
#4
mRenderList and updating AtlasClipMapBatcher::renderClipMap accordingly (which is called in AtlasClipMapBatcher::render (which is subsequently called by AtlasInstance::renderObject).
In ClipMapBlenderCache::doRectUpdate (which is used by ClipMap::fillWithTextureData and ClipMap::recenter) in the section of the code under the comment that reads
// Do one pass per opacity.
I changed everything that previously used the first 4 arbitrary indexes of the mSourceImages array to use a loop based on the number of source images in the array. This seems like its likely a week point in this attempt if the shaders are not able to utilize this. My understanding of shaders from an implementation standpoint is extremely basic.
I did look in atlasBlenderPS20P.hlsl and atlasBlenderPS20V.hlsl and (not completely understanding what was happening) I saw what looked to be 4 entry points (for lack of a better term) for texture information, although I wasn't clear on whether this was an arbitrary declaration to accept 4 textures, or (based on reading the line under // Blend) if these were information being sent for the RGBA channels for a single texture.
09/30/2008 (12:52 am)
When I say they aren't appearing correctly I mean they aren't appearing at all. I haven't defined a second "blend map" -- I'm not entirely sure what that is. I tried simply increasing the capacity of VectorIn ClipMapBlenderCache::doRectUpdate (which is used by ClipMap::fillWithTextureData and ClipMap::recenter) in the section of the code under the comment that reads
// Do one pass per opacity.
I changed everything that previously used the first 4 arbitrary indexes of the mSourceImages array to use a loop based on the number of source images in the array. This seems like its likely a week point in this attempt if the shaders are not able to utilize this. My understanding of shaders from an implementation standpoint is extremely basic.
I did look in atlasBlenderPS20P.hlsl and atlasBlenderPS20V.hlsl and (not completely understanding what was happening) I saw what looked to be 4 entry points (for lack of a better term) for texture information, although I wasn't clear on whether this was an arbitrary declaration to accept 4 textures, or (based on reading the line under // Blend) if these were information being sent for the RGBA channels for a single texture.
#5
My understanding is that in the default "atlasGenerateBlenderTerrain" console command you supply a single opacity map (i.e. the RGBA texture -- 4 channels to define where each of the 4 textures are to be applied) to the terrain being generated. At least in the earlier versions of TGEA the atlasBlenderPS20P.hlsl had the basic idea of taking that opacityMap-texture and multiplying each of the textures with the color channels, something like:
color = oMap.r * tex1 + oMap.g * tex2 + oMap.b * tex3 + oMap.a * tex4;
That's the basic setup how it controlled how strong each texture was applied at given texCoord (pixel). You multply opacity map's red channel with texture 1 and green channel with texture 2 etc.
Now that you have introduced 4 extra textures but no additional opacity map, the shader simply won't apply those new textures (i.e. tex5-8). I'm not sure how the new "one pass per opacity" functionality is implemented but I'm confident it needs another opacity map for the next 4 textures, it might not even try to render them because the atlas terrain has only a single opacity map defined.
I'm sorry I can't help you with more detailed info as I don't have a compiler or the source code at the moment. I'd advice you to trace the generation/handling/applying of the opacity map beginning from the "atlasGenerateBlenderTerrain" command onward, it should reveal how it is defined, stored and used.
Good luck with the effort!
@GG: maybe someone who has built the system and made those "one pass per opacity" additions to the clipMap could comment on this?
09/30/2008 (1:58 am)
Okay.My understanding is that in the default "atlasGenerateBlenderTerrain" console command you supply a single opacity map (i.e. the RGBA texture -- 4 channels to define where each of the 4 textures are to be applied) to the terrain being generated. At least in the earlier versions of TGEA the atlasBlenderPS20P.hlsl had the basic idea of taking that opacityMap-texture and multiplying each of the textures with the color channels, something like:
color = oMap.r * tex1 + oMap.g * tex2 + oMap.b * tex3 + oMap.a * tex4;
That's the basic setup how it controlled how strong each texture was applied at given texCoord (pixel). You multply opacity map's red channel with texture 1 and green channel with texture 2 etc.
Now that you have introduced 4 extra textures but no additional opacity map, the shader simply won't apply those new textures (i.e. tex5-8). I'm not sure how the new "one pass per opacity" functionality is implemented but I'm confident it needs another opacity map for the next 4 textures, it might not even try to render them because the atlas terrain has only a single opacity map defined.
I'm sorry I can't help you with more detailed info as I don't have a compiler or the source code at the moment. I'd advice you to trace the generation/handling/applying of the opacity map beginning from the "atlasGenerateBlenderTerrain" command onward, it should reveal how it is defined, stored and used.
Good luck with the effort!
@GG: maybe someone who has built the system and made those "one pass per opacity" additions to the clipMap could comment on this?
#6
Your description of atlasBlenderPS20P appears to still be accurate. Due to my lack of knowledge of shaders I wasn't clear as to whether tex1-tex4 were independent channels of a single texture themselves or, as you described, 4 independent textures where the they are multiplied by RGBA of the opacity map. This makes more sense now. If Atlas is determining what textures appear where using the opacity map that would explain the limitation of 4 textures (despite storing and being aware of additional source images).
I can see now how a second opacity map would be helpful. It seems that the code that actually imports the raw data and generates the Atlas terrain would need to be modified.
Quickly glancing at the code right now I can see that ClipMapBlenderCache keeps a vector called mOpacitySources. Looking at ClipMapBlenderCache::createOpacityScratchTextures also seems to shed a little more light on this. ClipMapBlenderCache::doRectUpdate also appears to loop through and use every available opacity map. In this case I can see that some of my changes above to that function are not appropriate there would always only be 4 terrain textures per opacity map. Its creating and storing additional opacity maps that appears to be the real issue.
09/30/2008 (2:22 am)
Henri, I appreciate your feedback.Your description of atlasBlenderPS20P appears to still be accurate. Due to my lack of knowledge of shaders I wasn't clear as to whether tex1-tex4 were independent channels of a single texture themselves or, as you described, 4 independent textures where the they are multiplied by RGBA of the opacity map. This makes more sense now. If Atlas is determining what textures appear where using the opacity map that would explain the limitation of 4 textures (despite storing and being aware of additional source images).
I can see now how a second opacity map would be helpful. It seems that the code that actually imports the raw data and generates the Atlas terrain would need to be modified.
Quickly glancing at the code right now I can see that ClipMapBlenderCache keeps a vector called mOpacitySources. Looking at ClipMapBlenderCache::createOpacityScratchTextures also seems to shed a little more light on this. ClipMapBlenderCache::doRectUpdate also appears to loop through and use every available opacity map. In this case I can see that some of my changes above to that function are not appropriate there would always only be 4 terrain textures per opacity map. Its creating and storing additional opacity maps that appears to be the real issue.
#7
Henri, your comments were invaluable in setting me in the right direction to figure this out.
Ultimately I needed to modify atlasGenerateBlenderTerrain to be able to handle a second opacity map as well as modify AtlasInstance2::onAdd to figure out if a second opacity map is available and if so to use it appropriately. There were a few other minor changes (had to create a new constructor for ClipMapBlenderCache that could accept more than one opacity map) but I otherwise didn't have to make any changes to any shaders or rendering code.
There's still a little bit of code I want to clean up but otherwise this solution is pretty straight forward. It also handles putting the opacity data directly into the atlas file and dealing with either one or two opacity files correctly (it should be really easy to modify this to use more than 2 opacity files without a problem).
Here's a little screen shot of a test terrain usind solid colored textures with a number in the center of each so that I could see clearly that its working:
10/01/2008 (3:55 am)
I just wanted to report that I've been successful in storing, loading and using two opacity maps!Henri, your comments were invaluable in setting me in the right direction to figure this out.
Ultimately I needed to modify atlasGenerateBlenderTerrain to be able to handle a second opacity map as well as modify AtlasInstance2::onAdd to figure out if a second opacity map is available and if so to use it appropriately. There were a few other minor changes (had to create a new constructor for ClipMapBlenderCache that could accept more than one opacity map) but I otherwise didn't have to make any changes to any shaders or rendering code.
There's still a little bit of code I want to clean up but otherwise this solution is pretty straight forward. It also handles putting the opacity data directly into the atlas file and dealing with either one or two opacity files correctly (it should be really easy to modify this to use more than 2 opacity files without a problem).
Here's a little screen shot of a test terrain usind solid colored textures with a number in the center of each so that I could see clearly that its working:
#8
Glad I could help, will try your changes out myself when I get my computer back together (STILL waiting for the installation media from HP) -- You are planning to release this as a resource, right? At least I'd like to take a shot at the code ;)
Now, all that remains is that someone fixes the clipMap blurring issues (i.e. the selection of wrong mip levels). Haven't heard anything from Rene / GG in a while regarding that. Are you experiencing any of those issues so far?
10/01/2008 (4:57 am)
Wohoo, looks great!Glad I could help, will try your changes out myself when I get my computer back together (STILL waiting for the installation media from HP) -- You are planning to release this as a resource, right? At least I'd like to take a shot at the code ;)
Now, all that remains is that someone fixes the clipMap blurring issues (i.e. the selection of wrong mip levels). Haven't heard anything from Rene / GG in a while regarding that. Are you experiencing any of those issues so far?
#9
As for blurring this is something I have seen and another issue I was looking into fixing but haven't made any progress on yet. My first goal was to try and disable automatic MIP selection and force it to always use the highest MIP level (I understand this would have performance implications but I have no idea how much. If its small I could live with it).
One thing I have found that makes the terrain look significantly better (ableit using significantly more video memory -- I plan on adding this as a client-configurable option) is changing a pref that determines the clip map size. Off hand I don't recall the exact name... I believe its $Pref::Atlas::ClipMapSize but I will verify this later. By default its 512 but setting it to 2048 looks very very good (although it uses about 4x the video memory, over 100mb according to what it reports in the console). For people with 512MB or more video cards this shouldn't be a problem, but if you only have 256mb or 128mb you will see significant stuttering / slow down or the client will simply crash (which is why I plan to make this client-configurable with a check to verify that enough video memory is available for using the higher levels).
10/01/2008 (9:49 am)
I will put up a resource by the end of the week (possibly tonight if I have time).As for blurring this is something I have seen and another issue I was looking into fixing but haven't made any progress on yet. My first goal was to try and disable automatic MIP selection and force it to always use the highest MIP level (I understand this would have performance implications but I have no idea how much. If its small I could live with it).
One thing I have found that makes the terrain look significantly better (ableit using significantly more video memory -- I plan on adding this as a client-configurable option) is changing a pref that determines the clip map size. Off hand I don't recall the exact name... I believe its $Pref::Atlas::ClipMapSize but I will verify this later. By default its 512 but setting it to 2048 looks very very good (although it uses about 4x the video memory, over 100mb according to what it reports in the console). For people with 512MB or more video cards this shouldn't be a problem, but if you only have 256mb or 128mb you will see significant stuttering / slow down or the client will simply crash (which is why I plan to make this client-configurable with a check to verify that enough video memory is available for using the higher levels).
#10
If you mean disabling the mip mapping on the 8 detail textures, that's fairly easy to do, simply alter the GFX call loading them but doing so will cause some loss of performance, shouldn't be overly drastic on a more efficient card. However, I suspect that will not fix the blurring issue.
As far as I've understood the main issue is with the clipmap choosing a wrong detail level (I might have been a little misguiding by calling it a mip mapping issue). It is related to how the clipmap works and I believe it basically creates a stack of "scratch textures" at size of $Pref::Atlas::ClipMapSize and uses them to texture the terrain.
The scratch texture is the render target of the atlas blender which uses the opacity maps and the detail textures to fill it with suitable data, rendering more detail for areas closer to the camera. The benefit is that once the scratch texture is filled it has "fresh data" near your current view and doesn't need to do the blending until you move or turn enough, at which point it will start filling the clipMap with new data (and I think the clipMap has multiple detail levels as well, henche I called it a stack of textures, of which the lowest ones are almost always upto-date with "blurrier data" so in case the clipMap hasn't had enough time to load the highest detail data it uses a lower detail level data -- a blurry texture).
The system is even a bit more complex, I currently don't know it that well, but somewhere deep within its logics fail to pick the right detail levels (of the clipMap). The system was deviced by Ben Garney and Rene Damm found some flaws in it and partially fixed them, but I recall Rene writing the system needs some fundamental changes to work correctly.
10/01/2008 (11:43 am)
The $Pref::Atlas::ClipMapSize will definately improve the quality, though an earlier post claimed that anything wider than your used resolution will not have effect (i.e. in my case, 1024x1024 would be decent enough as I'm running on older GPU -- and it would even update faster).If you mean disabling the mip mapping on the 8 detail textures, that's fairly easy to do, simply alter the GFX call loading them but doing so will cause some loss of performance, shouldn't be overly drastic on a more efficient card. However, I suspect that will not fix the blurring issue.
As far as I've understood the main issue is with the clipmap choosing a wrong detail level (I might have been a little misguiding by calling it a mip mapping issue). It is related to how the clipmap works and I believe it basically creates a stack of "scratch textures" at size of $Pref::Atlas::ClipMapSize and uses them to texture the terrain.
The scratch texture is the render target of the atlas blender which uses the opacity maps and the detail textures to fill it with suitable data, rendering more detail for areas closer to the camera. The benefit is that once the scratch texture is filled it has "fresh data" near your current view and doesn't need to do the blending until you move or turn enough, at which point it will start filling the clipMap with new data (and I think the clipMap has multiple detail levels as well, henche I called it a stack of textures, of which the lowest ones are almost always upto-date with "blurrier data" so in case the clipMap hasn't had enough time to load the highest detail data it uses a lower detail level data -- a blurry texture).
The system is even a bit more complex, I currently don't know it that well, but somewhere deep within its logics fail to pick the right detail levels (of the clipMap). The system was deviced by Ben Garney and Rene Damm found some flaws in it and partially fixed them, but I recall Rene writing the system needs some fundamental changes to work correctly.
#11
10/01/2008 (11:56 am)
Another things I was thinking to fix was the vertex normals of the atlas geometry. The current generator was simply filling them with (xyz= 0 0 1) so any attempts to do normal mapping based dynamic lighting will utterly fail to produce correct results. There were some comments in the code about them being hard to calculate or something. I figured I would supply a normal map texture to get the values from but it's currently not a priority on my list.
#12
10/02/2008 (6:36 pm)
I posted a brief resource for this. Its currently awaiting approval: www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=15505 
Torque 3D Owner Henri Aalto
Braincoolant
I recall that the blended atlas code used to load only 4 texture to the GPU at some point (one of the loops you mentioned), haven't checked the latests revisions from that perspective. The blended atlas pixel shader also used only 4 textures but I don't know whether they've changed that (as the new megaTerrains can even do multiple iterations with 4 textures if you have 5+ on the terrain). You will also need to load an additional "opacity map" into the atlas texture TOC or create another texture TOC to be able to tell where these 4 new textures will be rendered on the terrain.
So... I think you need to modify (at least) those loops and the shader.
I was also thinking about modifying the blended atlas for 8 textures myself but the major drawback was the fact the the clipmap system still isn't up to the job in general, it still blurs the textures (chooses wrong MIP-levels or something).
Instead, I'll likely do something similar to the "8 textures on atlas" resource and write my own shader to replace the atlasDetail shader of the regular blended atlas terrain and disable the default blending (basically this could be done using the unique texture atlas as well but that doesn't incorporate dynamic shadows from objects at the moment and I don't understand the "shadow targets" well enough to be able to hook it up).
Edit: I read the forum link you posted and it seems like they have indeed modified the shaders but at least the altas generation code to include the additional channels for the opacityTOC need to be added. I may give it a look later today.