HeroEngine Forums
Welcome, Guest. Please login or Register for HeroCloud Account.

Author Topic: [resolved] Texture Alpha (mipmaps?) not applying correctly!  (Read 5541 times)

McIndus

  • General Accounts
  • *
  • Posts: 18
    • View Profile

Hello everyone, this is my first post here and I'd like to bring a bug to light that may have been addressed before, but I have a way to reproduce the problem, and am hoping for a fix!

I have been creating my own 4-tiled textures for use as Dynamic grass, but have been running into a major issue.  When I zoom out to the point of where it swaps resolutions, the alpha channel gets a 'line' drawn across it.

I thought it was my textures, so I pushed everything a few pixels away from each other and it 'quick-fixed' my issue, but I have tried again and again to track down the problem on my end, to no avail. (even using bright colored blocks to determine what was going on). 

Here is a screenshot of close up with NO artifact:


And here it is zoomed out, with noticeable artifact (turned transparency to 0 to make obvious)



This is also happening when I use the SpeedTree compiler and use billboard leaves.

Close:


Far:



I have looked into my textures, and realized that both of these textures are set up in quadrants - the grass billboards, and the speedtree compiled texture.  If the image is divided like this:

Then the bleed is happening from the top/bottom sections between textures, but not on the original texture, only on it as you zoom out... which is telling me that HE is calling the wrong pixel locations for the second set of mipmaps from combined textures.  It also seems to pop up on the left/right side of the Dynamic grass textures sometimes as well.

Thanks, let me know if you need any more information!
« Last Edit: Jun 10, 15, 09:57:08 AM by HE-BENNETT »
Logged

HE-HERB

  • HeroEngine
  • *****
  • Posts: 530
    • View Profile
    • HeroEngine
Re: Texture Alpha (mipmaps?) not applying correctly!
« Reply #1 on: Apr 28, 15, 01:25:00 PM »

Quote
I have been creating my own 4-tiled textures for use as Dynamic grass, but have been running into a major issue

Does this happen with any of the included test content?

It appears that you're drawing your textures right up to the extent of the quarter of the atlas.  While the texture addressing divides it into a 2x2 of clamped quads, hardware filtering will still bleed across the edge because it can't mask.

Cheers
Logged
herb marselas
graphics guy

McIndus

  • General Accounts
  • *
  • Posts: 18
    • View Profile
Re: Texture Alpha (mipmaps?) not applying correctly!
« Reply #2 on: Apr 28, 15, 05:04:45 PM »

Quote
I have been creating my own 4-tiled textures for use as Dynamic grass, but have been running into a major issue

Does this happen with any of the included test content?

It appears that you're drawing your textures right up to the extent of the quarter of the atlas.  While the texture addressing divides it into a 2x2 of clamped quads, hardware filtering will still bleed across the edge because it can't mask.

Cheers

The image I posted is actually cropped and edited, but if you're talking about the locations where the top/bottom meet, then yes - my texture is sitting right on the edge.
How many pixels would be a 'good' distance to move my images away from the quadrant edges? 

My current method was literally copy/pasting the ones that work just fine in 'single' mode into a 'smaller' resolution composite of 4, using your awesome quad texture Dynamic placement, making sure that I was pixel precise.  I will try to use the test content as a template for my pixel locations to see if that fixes things.  Could this be because my originals are 1024px instead of the default 512px-less and my mips at a distance are causing hardware filtering bleed? 

It's strange that it only happens at a distance.  I checked a bunch of the test content, and it doesn't seem to be there, but there are other minor issues if transparency is set to "0", such as a pixel bleed on the bottom of some of the textures.  I know transp set to 0 looks like crap and has pixelization, etc., and those artifacts go away right away on the test content,  but I have to set my transparency to "10" or more before my current problem goes away on my own textures, and that sacrifices too much of my grass detail, so my current workaround was to push everything 2 pixels away from the quadrant edges, but I feel that a 4 pixel 'buffer' on each texture is a hackish workaround - or is this standard?

Second, and more important question:  Why is this happening in SpeedTree when it compiles my files?  SpeedTree compiler even adds a nice buffer between the textures, but it seems like the mips are still wrong.  Will I have to manually change all of my SpeedTree textures if they have card textures for leaves after they compile?  The texture that it compiled for me in SpeedTree doesn't even have any textures up to the edge of the quadrant.  My 'knothole' cap texture is the one that seems to be bleeding down into the quad below it, but it also only happens when I zoom out.  Could this be because I have included my ambient lighting from ST in the SpeedTree compiler?  Will I now no longer be able to use this function? EDIT* Just compiled without ambient lighting, still have the problem with SpeedTrees.

Thanks for all your help!
« Last Edit: Apr 28, 15, 05:27:43 PM by McIndus »
Logged

HE-HERB

  • HeroEngine
  • *****
  • Posts: 530
    • View Profile
    • HeroEngine
Re: Texture Alpha (mipmaps?) not applying correctly!
« Reply #3 on: Apr 29, 15, 09:30:32 AM »

In a quick check, it looks like we stay about 8 pixels away from the border that separates any two quads; and, a bit closer to the border of the texture atlas itself.  You have the content, so you can easily use it as a guideline.

I'll ask Bennett to provide his input on the SpeedTree texture, as I'm not sure whether that's a usage issue or potential bug.

Cheers
Logged
herb marselas
graphics guy

McIndus

  • General Accounts
  • *
  • Posts: 18
    • View Profile
Re: Texture Alpha (mipmaps?) not applying correctly!
« Reply #4 on: Apr 30, 15, 01:48:21 AM »

In a quick check, it looks like we stay about 8 pixels away from the border that separates any two quads; and, a bit closer to the border of the texture atlas itself.  You have the content, so you can easily use it as a guideline.

I'll ask Bennett to provide his input on the SpeedTree texture, as I'm not sure whether that's a usage issue or potential bug.

Cheers

Thanks for your help, Herb!

Well, the reason I asked about the buffer is because I can't find the pixel buffer you're talking about on the grass quadrant textures.
Are you looking at the content with the Alpha applied?  GIMP automatically shows you the alpha value, PS does not.  If you open the grass files in PS, this is what you see, with the quadrant art going right up to the edge:




Also, unless I turn my transparency up to 4 or 5, you can see the top/bottom of the quads 'bumping' into each other on these textures inside the game as well.  The only thing I see different from my files and the 'test textures' is that the test grass does a gradient fade in the alpha as you get to the bottom of the quadrant, yet mine is big, white, and bold.  I think something is happening in the alpha channel on the third mip.  In HE default files, you don't always see this in game because the bottom of the grass has a stronger transparency than the rest.

I think they are actually the same bug, if it is a bug.  In SpeedTree, when it compiles a texture, it creates a 'green' background to the diffuse textures by default.  I can change this setting to be Transparent, but then I have issues with my billboard trees themselves showing up incorrectly. 
If you compile a texture in speedtree (mine are 1024), by the third mipmap, you can see how the green diffuse 'background' blends with the edge of the pixels of the quad instead of being part of that generated border because of how small the mip is...  however, the Alpha looks 100% ok:



So this - in theory - should work beautifully, and I shouldn't be getting artifacts in the mips when I zoom out, correct?  For some reason, the top/bottom of the diffuse textures on the third mipmap are bleeding through the alpha into the bottom texture.  This is also the exact mip level I'm having issues on with my grass.  I tried dropping my texture resolutions to 512x512 because the test textures are that resolution, but it didn't solve my problem.

Hope this helps.
« Last Edit: Apr 30, 15, 01:54:23 AM by McIndus »
Logged

HE-BENNETT

  • HeroEngine
  • *****
  • Posts: 559
    • View Profile
Re: Texture Alpha (mipmaps?) not applying correctly!
« Reply #5 on: Apr 30, 15, 10:59:23 AM »

Interesting, the problem is specifically with the third mipmap?  I assume you are using the automatic generation of mipmaps option in the DDS exporter for Photoshop?  Can you post a screen shot of the alpha channel of one of the problematic textures - including the mip mapped versions?

Logged

HE-Cooper

  • *****
  • Posts: 2221
    • View Profile
Re: Texture Alpha (mipmaps?) not applying correctly!
« Reply #6 on: Apr 30, 15, 11:58:15 AM »

Those look like the speedtree default MIP exports.
Logged

McIndus

  • General Accounts
  • *
  • Posts: 18
    • View Profile
Re: Texture Alpha (mipmaps?) not applying correctly!
« Reply #7 on: May 03, 15, 10:33:02 PM »

Interesting, the problem is specifically with the third mipmap?  I assume you are using the automatic generation of mipmaps option in the DDS exporter for Photoshop?  Can you post a screen shot of the alpha channel of one of the problematic textures - including the mip mapped versions?

I actually have mainly been using GIMP because I'm trying to better familiarize myself with the program, but for this bug, I get the same exact results whether the mips were automatically generated in PS with the Nvidia .dds plugin, or in GIMP with the GIMP .dds plugin.

Those look like the speedtree default MIP exports.

Yes, exactly!
The mips that I posted were 'opened' in PS, but they were generated by the SpeedTree Compiler with everything in 'default' .dds mode.

Here are the screenshots you wanted, HE-BENNETT.  The first two are the 'grass' textures.  You can see how the first image, which is my own, is solid alpha which makes the bug extremely obvious.  Other than that, it doesn't seem like there's any issue with the mips being different than the originals in the distance to the quadrant edge.



The second shot is of the default 'test' HE grass, which has a very distinct alpha gradient, which would make this bug invisible to you in testing unless the transparency in HE is set to '0' or very near it.



This last image is the Alpha layer of the SpeedTree default mip export, which pretty clearly shows that the alpha has plenty of room, and shouldn't be the problem.



Again, look at the same texture's diffuse version from my post above -- the third mip map is the only one where the 'green' background default border has failed at all and is 'blending' with the texture -- but this shouldn't be an issue if the Alpha is applying correctly, should it?  It would just be extra 'glow', not a -bar- across my textures.   And if it was a texture filtering issue, wouldn't it happen on the original texture or the first and even second mips?  So if the Alpha ISN'T the problem (because it looks like there's boatloads of room up there), then could it be possible for HE to be reading those mips Diffuse Texture's pixel locations improperly?  It only happens after you move the camera back a good distance from the texture in question.  If you can't replicate the problem, try turning on the wind -- it makes it pretty obvious in my world.  I don't think it's just the 3rd mip, it looks like it's everything after that mip as well, but it's hard to tell.

I was also talking to our programmer and he was wondering if, since you mentioned it was a hardware filtering issue -- is there a way to turn it off?

If it helps, there was another post about this topic, but only relating to SpeedTrees that was posted in December by a person with my same problem.  The trees that he imported himself from Max/Maya seemed to be working just fine, but his speedtrees 'all of the sudden' started doing this to him.

Thanks!
Logged

HE-BENNETT

  • HeroEngine
  • *****
  • Posts: 559
    • View Profile
Re: Texture Alpha (mipmaps?) not applying correctly!
« Reply #8 on: May 06, 15, 12:39:26 PM »

The behavior you are seeing with dynamic details is most likely a direct result of the way that DDS compression effects the alpha channel.  All of the cases where I've been able to reproduce the behavior have had alpha from the top two tiles bleeding down into the bottom two.

As you noticed, the default example textures have both a small margin and an alpha gradient towards the bottom of each tile in the texture.  This, combined with a small value in the "transparency" setting in HeroBlade helps circumvent the issue - even a sizeable border will likely not be enough to prevent any compression artifacts (in all cases) in the very small mips.

If you either need to have alpha that goes right to the border with no margin or you even with a margin you're still seeing the "bar", the easiest solution is to manually update the alpha mip maps.  So, first you create the texture and export as DDS.  Then you open the DDS file, checking the "Load mipmaps" button.  Edit the alpha channel of the mip maps to fix the error (which comes from averaging pixel values to create the mip maps). Then, save the DDS again, making sure to check the "use existing mip maps" option.


As for the issue with SpeedTrees, I'm looking into it, but it appears to be the same issue.  If it isn't the source texture causing the problem, there is a section in the user manual which talks about settings to tweak: 

To correct this, adjust the "Inner scale" or "Outer margin" properties on the offending texture to give it a border of empty space. The textures bleeding through are usually opaque (high alpha values) to the very edge of the texture, such as branch cap textures, not the textures that you see the effect on (such as leaves in the example picture).
If a solid texture is detected on initial tree load, the "Inner scale" property will automatically be set to 0.9. However, in some cases this may not be enough.


So if there aren't any compression artifacts in the alpha, it may just be a speedtree setting that needs to be tweaked for that specific texture.
Logged

McIndus

  • General Accounts
  • *
  • Posts: 18
    • View Profile
Re: Texture Alpha (mipmaps?) not applying correctly!
« Reply #9 on: May 30, 15, 10:11:55 PM »

The behavior you are seeing with dynamic details is most likely a direct result of the way that DDS compression effects the alpha channel.  All of the cases where I've been able to reproduce the behavior have had alpha from the top two tiles bleeding down into the bottom two.

As you noticed, the default example textures have both a small margin and an alpha gradient towards the bottom of each tile in the texture.  This, combined with a small value in the "transparency" setting in HeroBlade helps circumvent the issue - even a sizeable border will likely not be enough to prevent any compression artifacts (in all cases) in the very small mips.

If you either need to have alpha that goes right to the border with no margin or you even with a margin you're still seeing the "bar", the easiest solution is to manually update the alpha mip maps.  So, first you create the texture and export as DDS.  Then you open the DDS file, checking the "Load mipmaps" button.  Edit the alpha channel of the mip maps to fix the error (which comes from averaging pixel values to create the mip maps). Then, save the DDS again, making sure to check the "use existing mip maps" option.


As for the issue with SpeedTrees, I'm looking into it, but it appears to be the same issue.  If it isn't the source texture causing the problem, there is a section in the user manual which talks about settings to tweak: 

To correct this, adjust the "Inner scale" or "Outer margin" properties on the offending texture to give it a border of empty space. The textures bleeding through are usually opaque (high alpha values) to the very edge of the texture, such as branch cap textures, not the textures that you see the effect on (such as leaves in the example picture).
If a solid texture is detected on initial tree load, the "Inner scale" property will automatically be set to 0.9. However, in some cases this may not be enough.


So if there aren't any compression artifacts in the alpha, it may just be a speedtree setting that needs to be tweaked for that specific texture.

Wanted to post an update since both issues are now solved with workarounds:

My current workaround for the Dynamic Detail grass is this - pull each tile 8px from the edges of the quadrants in the image (16 for 1024 textures) and then add an alpha gradient to each one.  It adds a bit of extra work, but nothing a good pipeline can't solve.  This step makes the grass currently 'hover' in mid-air.

Second - your fix with SpeedTrees worked beautifully.  I changed "Inner Scale" on the cap textures from .9 to .86 (more if the cap texture is considerably smaller than the leaf texture) and it solved my problem.  Thanks for your help! Now I just have to figure out how to get rid of those pesky roots popping out of my billboards for no reason lol.
« Last Edit: Jun 02, 15, 01:51:34 PM by McIndus »
Logged

McIndus

  • General Accounts
  • *
  • Posts: 18
    • View Profile
Re: Texture Alpha (mipmaps?) not applying correctly!
« Reply #10 on: Jun 02, 15, 01:50:31 PM »

As you noticed, the default example textures have both a small margin and an alpha gradient towards the bottom of each tile in the texture.  This, combined with a small value in the "transparency" setting in HeroBlade helps circumvent the issue - even a sizeable border will likely not be enough to prevent any compression artifacts (in all cases) in the very small mips.

Actually, I notice there is no margin between quadrants on the HE stock images - just the gradient.  I used a gradient and added some 'space' as you suggested, but now my grass floats in space a few centimeters off the ground.  Is there a way for me to change the 'Z' axis of the grass overall in order to 'sink' it into the ground?  I'll have to try just using a gradient if there's no way to alter the z axis.  Is there something I can alter in a shader somewhere?

Thanks Again!

EDIT -- well, it looks like all I needed to do was to add that gradient and keep my dynamic details at a 10 transparency or higher to eliminate the texture bleed.  Adding a border unfortunately made the grass float, like I mentioned above - but with the quadrants right up to the edge + alpha gradient on the border edges = success!  Thanks for all of your help through this process.
« Last Edit: Jun 06, 15, 02:56:49 PM by McIndus »
Logged