Jump to content
  • Advertisement
Sign in to follow this  
deffer

Multisampling by hand

This topic is 4824 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi. So I got a weird problem again ;) Background: I got a scene which is awfully aliased without multisampling, and quite fine otherwise. The point is, the output does not go to a plain PC monitor, but through an external device to a TV, or something like that. So I got to render to texture, or access the backbuffer after rendering to send the screen data to the actual output device. In a few words: Multisampling is not for me. To the point: I need to reproduce the multisampled (or any other nice looking) antialiasing in the back-buffer. From what I heard and read in DX SDK docs, it's being made with a technique similar to blur. However, it is described with a much larger dose of complexity, so I'm not confident enough to begin implementing it. So: 1. Is it possible at all? 2. Can it be done in hardware? (like we blur in hardware) 3. Is it going to be expensive? (for comparison: I may use yet one more 7x7_blur with in the aplication) 4. How about the actual implementation, any hints or sources? Thanks. ~def

Share this post


Link to post
Share on other sites
Advertisement
You could render the scene in a texture that is of double the width and height of the backbuffer, and perform box filtering in a pixel shader to gain 4x antialiasing quite cheap. Then again, most hardware perform this exact step very much optimally, when you set the multisampling mode from the presentation parameters.

May I ask, why exactly don't you want to use the built-in multisampling facilities? Technically, it shouldn't matter where the output goes.

Share this post


Link to post
Share on other sites
Quote:
Original post by Nik02
You could render the scene in a texture that is of double the width and height of the backbuffer, and perform box filtering in a pixel shader to gain 4x antialiasing quite cheap.


Bwaa, rendering the scene to a 4 times larger surface would definitely kill me [sad]
As to the box filter, I feel it would perform the antialiasing in an aliased way. I mean, I got many objects in the scene, that have pretty much XY aligned borders. And it sucks, since box filtering wouldn't change it a bit - I would gain no smoothing with it.

As to the filtering method, I found this in the DX SDK:

It shows various sampling methods, for performing antialiasing. It loks a bit simple to me. The MSDN article is quite general and does go too much into details.

Quote:
Original post by Nik02
Then again, most hardware perform this exact step very much optimally, when you set the multisampling mode from the presentation parameters.

May I ask, why exactly don't you want to use the built-in multisampling facilities? Technically, it shouldn't matter where the output goes.


It's not that I don't want to. I cannot. I prety much have to render everything to a texture, and then get that back to some software processing and send to some external device.

Oh, and the docs explicitly state in many places, that the render target data cannot be accessed if it was created with multisampling enabled [sad] I didn't go into trouble of proving it to myself, but guys at my work keep saying that it's impossible, and I think they know what they are talking about...

Share this post


Link to post
Share on other sites
You can use GetFrontBufferData instead, that will allow any kind of antialiasing because the pixels are physically realized by then.

I also know what I'm talking about [wink]

Share this post


Link to post
Share on other sites
Quote:
Original post by Nik02
You can use GetFrontBufferData instead, that will allow any kind of antialiasing because the pixels are physically realized by then.


Yes, but:
Quote:
from DX SDK (about GetFrontBufferData)
This function is very slow, by design, and should not be used in any performance-critical path.


I also recall using it before somewhere, it's really slow...

Quote:
I also know what I'm talking about [wink]


Sorry, I never doubt in you [grin]
The guy at work, who was implementing the part sending to the external device said, that he tried everything, and it cannot be done well in real-time with multisampling enabled. I generally believe in what people tell me, unless I got a reason not to (or I feel suspicious about the things they say).

Share this post


Link to post
Share on other sites
Could you not render the scene to a texture, the render that to a fullscreen quad with a blur shader? Then you could access the back buffer since it wouldn't have been created with multi-sampling.

Share this post


Link to post
Share on other sites
Actually, in the meanwhile I just tried that.
And it didn't look well. I tried various blur patterns, and in the end I'm starting to think that multisampling is somewhat(totally?) different than just fancy blur...

I still don't know how that is possible, though...

Share this post


Link to post
Share on other sites
Quote:
Original post by deffer
Actually, in the meanwhile I just tried that.
And it didn't look well. I tried various blur patterns, and in the end I'm starting to think that multisampling is somewhat(totally?) different than just fancy blur...

I still don't know how that is possible, though...


You're right: Multisampling is more than just fancy blur - it needs more source data than the final target can accommodate. Hence I mentioned the double-sized rendertarget in my first reply. Blurring is just a low-pass filter, it can't really construct more data than is already available.

GetFrontBufferData isn't slow, if you use professional cards designed for tv production (Quadro FX 4000 PCIE) but on regular cards, the bus speeds from the front buffer to system memory prevent fast downloads of the data. With some Quadros, you can even feed the output to IEEE1394 directly; this is the format that most digital tv production hardware handles most painlessly.

Share this post


Link to post
Share on other sites
Disclaimer: I'm making this up and I'm not sure how it will work out.

I'm thinking that it might be possible to use an edge detection shader to help determine the blur factor. So on 'edges' you would blur more than on the semi-flat surfaces. Essentially, this would blur the mesh silhouettes and leave hopefully leave the rest in in a less blurry state.

I know Photoshop has a 'Smart Blur' filter that essentially does this and I've found that it produces an image that looked less blured and more anti-aliased in practice.

Well, it's just a thought, I hope it helps.

Share this post


Link to post
Share on other sites
Quote:
Original post by Sages
Disclaimer: I'm making this up and I'm not sure how it will work out.

I'm thinking that it might be possible to use an edge detection shader to help determine the blur factor. So on 'edges' you would blur more than on the semi-flat surfaces. Essentially, this would blur the mesh silhouettes and leave hopefully leave the rest in in a less blurry state.

I know Photoshop has a 'Smart Blur' filter that essentially does this and I've found that it produces an image that looked less blured and more anti-aliased in practice.

Well, it's just a thought, I hope it helps.


In Photoshop, the user sets the contrast treshold, below which adjacent pixels will be blurred with Gaussian blur. In a realtime production, there isn't an opportunity to set the treshold every frame, and in practice there isn't a single "correct" value for it.

You could try this technique however, but remember that this is just another "fancy blur", it can't really invent new subpixel data.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!