Windows & Xbox 360 texture renders differently

rated by 0 users
This post has 35 Replies | 3 Followers

Top 10 Contributor
Posts 1,214
SunBurn_Community_Licensee
SunBurn_Contributor
SunBurn_Pro_Licensee
Philippe Da Silva Posted: 01-18-2012 1:07 PM

Hi guys,

I'm meeting a small graphics issue on Ace on Steroids where while the code is similar in both Windows & Xbox 360, I get a visual difference:

Windows:

Xbox 360 (detailed and taken from my iPhone so lower quality):

 If you look closely, you'll see that on the Xbox, the fog texture seems blurred... or using Point sampling.

It only happens when I apply a PostProcessor (SunBurn's HDR or IGF's Bloom) and it doesn't affect the windows rendering.

Any idea what is going on?

Thanks

Philippe

Top 25 Contributor
Posts 201
SunBurn_Community_Licensee
SunBurn_Contributor
SunBurn_Pro_Licensee

In the bloom post processor i used a half size intermediate rendertarget to add extra blur the bloom effect. I'm guessing it could be something to do with this and upsampling back to full screen - possibly this is handled slightly differently between xbox and windows. I can't test on xbox at the moment to have a look since my creators club membership has lapsed and i've not got round to renewing it.

The other thing that springs to mind could be the surfaceformat of the intermediate rendertargets although i'm farily certain that they use the same format as the back buffer in the bloom - I'll have a look and see if i can see anything in the code.

Edit - Just checked the code and the intermediate rendertargets all use surfaceformat.color so i wouldn't expect to see banding to see if it's the half size buffers your could try changing the following chunk of code and remove all the  / 2 s

            if(bloomBuffers.Count==0)

            {

                SurfaceFormat surfaceFormat = SurfaceFormat.Color;

                bloomBuffers.Add(new RenderTarget2D(graphicsDevice, _viewport.Width / 2, _viewport.Height / 2, false, surfaceFormat, DepthFormat.None, 0, RenderTargetUsage.PlatformContents));

                bloomBuffers.Add(new RenderTarget2D(graphicsDevice, _viewport.Width / 2, _viewport.Height / 2, false, surfaceFormat, DepthFormat.None, 0, RenderTargetUsage.PlatformContents));

                bloomBuffers.Add(new RenderTarget2D(graphicsDevice, _viewport.Width / 2, _viewport.Height / 2, false, surfaceFormat, DepthFormat.None, 0, RenderTargetUsage.PlatformContents));

                graphicsDevice.SetRenderTarget(null);

            }

Top 10 Contributor
Posts 1,214
SunBurn_Community_Licensee
SunBurn_Contributor
SunBurn_Pro_Licensee

Hi Bamyazi,

I'll give it a try but I doubt this is related to the Bloom post processor code since I also get the same texture banding when using SunBurn's HDR.

I'll try to run SunBurn's HDR sample on this display device and see if I get similar results. If yes, that would mean it's due to the display device not being friendly with pixel color depth and I'll need to test on other display devices.

I'll let you know of my results.

Top 10 Contributor
Posts 1,214
SunBurn_Community_Licensee
SunBurn_Contributor
SunBurn_Pro_Licensee

Ok, so I ran your changes and I'm getting same results.

I also downloaded and run SunBurn's HDR sample and I don't see a difference between Windows & Xbox rendering but it seems that the skybox textures aren't as color depth as the ones I'm using (I suppose it's using a 24bits color depth).
I therefore replaced the skybox textures with my fog one on all 6 faces and I get the same banding.

I also looked at gamma potential issues with my display device but when capturing picture using the Xna Device center and looking at the screenshot on my laptop (which doesn't shows the banding), I clearly see the banding occuring: this is therefore not related to the Display device.

I also tried some other stuff like using Forward rendering or removing all post processing and setting a static ambien light with a really high intensity and white color to get the fog texture with as much highlight as possible and I don't get the banding on both platforms.

I'm lost here and I'd need some help to get it right on Xbox too... I really can't find what is going wrong...

Thanks

Philippe

Top 25 Contributor
Posts 201
SunBurn_Community_Licensee
SunBurn_Contributor
SunBurn_Pro_Licensee

http://social.msdn.microsoft.com/Forums/is/xnaframework/thread/c93c806a-0239-4ece-a362-0c4a625f0a28

I found this just now - it may be a gamma issue on the TV you use with XBOX apparently you should try shawn's screencap utility and view the captured image on your windows machine

http://blogs.msdn.com/b/shawnhar/archive/2007/01/08/capturing-screenshots-from-xbox-xna-games.aspx

 

Top 10 Contributor
Posts 1,214
SunBurn_Community_Licensee
SunBurn_Contributor
SunBurn_Pro_Licensee

I read this too but while I'm not using Shawn's screencap utility, I still get the banding when looking at a screen capture performed with the Xna Game Studio Device Center tool (right click on your Xbox device lets you capture what is currently rendered by the Xbox).

Both Shawn's screencap and Xna Game Studio Device Center capture utility act the same. So since the screencap looks exactly the same on Xbox TV display and my laptop, then it isn't a gamma issue.

Moreover, if I don't apply any post processing, I don't get banding at all on Xbox... I'm really confused... I guess I'll have to go over Xna forums and ask there to get some more people help...

I'd love to see if John's has any idea if that could be related to the PostProcessManager

Top 10 Contributor
Posts 4,854
Employee
SunBurn_Studio_Licensee

Hi guys,

Are you rendering the scene to xna's HDRBlendable format and using the frame buffer alpha channel for blending (eg: blending with the destination alpha)?

The Xbox implementation of HDRBlendable only has 2 bits of alpha precision and will cause visual artifacts when using the destination alpha value.  Please note using the source alpha (standard alpha blending) will work fine as the value is not read from the frame buffer.

Let me know if this helps!

Follow me on Twitter – development and personal tweets
Awesome XNA Videos – Lighting, Rendering, and game videos

Top 10 Contributor
Posts 1,214
SunBurn_Community_Licensee
SunBurn_Contributor
SunBurn_Pro_Licensee

Well, as per the BloomPostProcessor, the code doesn't set anything special but using the PostProcessorTarget texture provided by PostProcessManager and applying a few FullFrameQuad.Render() calls based on a shader that extracts the higher lighting range of it, passes through 1 an horizontal then vertical gaussian blur effect and finally gets combined applying a simple saturation to improve the overall lighting.

But what seems strange in my case is that the SunBurn's HighDynamicRangePostProcessor renders a similar texture banding effect without making anything special on the GraphicsDevice...

What could it be caused by? I guess you are resetting all GraphicsDevice states before calling the PostProcessors listed in the PostProcessManager, right?

Top 10 Contributor
Posts 1,214
SunBurn_Community_Licensee
SunBurn_Contributor
SunBurn_Pro_Licensee

Since this is something that didn't happen before, I'm wondering if that couldn't be related to the fact SunBurn 2.0.17 introduced partial transparencies...

I'll test it out as soon as I can with opaque textures to see if I get the same result.

On another note, could it be related to this (http://venturebeat.com/2012/01/19/microsoft-acknowledges-color-space-problem-with-xbox-360-update/), I doubt since it's only happening on videos but who knows :p

Top 10 Contributor
Posts 1,214
SunBurn_Community_Licensee
SunBurn_Contributor
SunBurn_Pro_Licensee

I double checked and using an opaque texture does reproduce the same banding.

I ran the project using breakpoints on my BloomPostProcessor EndFrameRendering() method and notice 3 important things:

  1. the RenderTargets I create and use for the effects are set to use SurfaceFormat.Color as expected.
  2. the BackBuffer SurfaceFormat is also using SurfaceFormat.Color as expected
  3. the ProcessorRenderTarget that is exposed by the BasePostProcessor class is set to use a SurfaceFormat.HdrBendable

Could that last point be the reason why I'm getting these bandings? Mixed with alpha issues potentially?

I'm using this ProcessorRenderTarget to extract my initial brighter areas which is then blurred and finally combined into the backbuffer.

Top 10 Contributor
Posts 1,214
SunBurn_Community_Licensee
SunBurn_Contributor
SunBurn_Pro_Licensee

That could be it!

It seems based on Shawn's article that Windows & Xbox 360 do not treat equally the HdrBendable format where Xbox 360 is using a 10.10.10.2 bits which definitivelly leads to an issue when you want to blend alpha: you only have 2 bits for that.

So if you have a scene without any alpha or additive blending, post processors will run just fine. But if like I do here, you use a quite large (in my case it takes the full screen space) alpha gradient texture inside a quad, you'll end up with these bandings.

At least, that makes sense and I can now look at potential solutions...

I'm not sure if that should enter as a bug fix/feature request but why SunBurn PostProcessManager doesn't provide us with a ProcessorRenderTarget which would be using the SurfaceFormat set in our GraphicsDeviceManager.PreferredBackBufferFormat preferences?
That would make sense since no all PostProcessors may want the HdrBendable surfaceformat and it should be part of the HighDynamicRangePostProcessor to render the scene in that format, shouldn't it?

I'm now thinking of gathering the GBuffer from the FrameBuffers and use that to render my bloomed effect.

Top 10 Contributor
Posts 1,214
SunBurn_Community_Licensee
SunBurn_Contributor
SunBurn_Pro_Licensee

Ok based on my previous findings, I then thought that it would work if I used a non alpha based texture (totally opaque gradient cloud where Black would replace transparency. 

However, when using such texture I'm still getting bandings so alpha isn't the issue. What could I do now?

Could it be that somehow, it still compile textures using DxtCompression while I say it to use Color? Could it be that it actually generated MipMaps while I think I'm telling it not to?

How can I see if a XNB file actually contains no MipMaps or uses Color as asked?

What can I do more to investigate?

Top 10 Contributor
Posts 4,854
Employee
SunBurn_Studio_Licensee

Hi Philippe,

We're not able to reproduce this here at all. :/  The only way we've been able to generate banding is by using the HDRBlendable alpha destination channel for blending (eg: storing a value in the alpha channel and using it later for blending).

After the texture is loaded you can check out its SurfaceFormat to see what format the data is stored in.  DXT compression would definitely introduce banding and also some blockiness.

Let me know if this helps!

Follow me on Twitter – development and personal tweets
Awesome XNA Videos – Lighting, Rendering, and game videos

Top 10 Contributor
Posts 1,214
SunBurn_Community_Licensee
SunBurn_Contributor
SunBurn_Pro_Licensee

Can I share with you the current source code for you to check directly what is going on?

Philippe

Top 10 Contributor
Posts 4,854
Employee
SunBurn_Studio_Licensee

Hi Philippe,

Sure thing, we'd be glad to help.  Were you able to reproduce the problem in a smaller project, or does it only happen in the game?

Follow me on Twitter – development and personal tweets
Awesome XNA Videos – Lighting, Rendering, and game videos

Page 1 of 3 (36 items) 1 2 3 Next > | RSS