First, some context :
The 3D engine I wrote for my game allows me to switch between DirectX 9 and OpenGL, thanks to an intermediate API layer.
Both allow the user to enable multisampling (via GL_ARB_multisample for OpenGL, D3DMULTISAMPLE_x_SAMPLES for DirectX). Multisampling is enabled for the game window buffer.
The models for my characters use one big texture with texture atlases, so I disabled mipmapping there in order to avoid texture bleeding.
I experience the following results :
As I should, I get the same result when disabling multi-sampling for DirectX or OpenGL.
As I should, I correctly get edge smoothing on polygons when enabling multi-sampling for both.
However, in OpenGL, it seems that multi-sampling also has an effect akin to texture filtering, probably multi-sampling at different spots in the texture for each pixel, as the results are comparable to what mipmap would achieve, without texture bleeding - obviously, great. On the other hand, however, DirectX doesn't seem to provide this benefit as the result of texture mapping isn't anti-aliased, and the same as when multi-sampling is disabled.
I would very much like to know if there is anything I can do in order to get the same result in DirectX as in OpenGL. Maybe I am not aware of the good keywords, but I haven't been able to find documentation that relates to this specific aspect of multisampling.
Related
I wish to make an opengl universal texture transparent hack for the DxWnd tool (an open-source program hosted o SourceForge). The hack should work for every program using opengl to render RGBA textures. DxWnd cah hook and redirect all calls from libraries, including opengl32.dll.
I've read and tried to implement all suggestions about making a texture transparent, including enabling GL_BLEND, disabling GL_CULL_FACE and setting glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA). In addition, there's a routine that enforces the alpha bits of all texture pixels.
I expected that, once finished, the result should be a semi-transparent scene, but that doesn't happen.
For instance, the following is a 3d scene from gl hexen II:
and this is the final result, with some textures not transparent and most pixel colors lost:
Just to demonstrate that DxWnd is able to manipulate color pixels (so that this should not be the cause of the problem) this is the same scene with a filter that recolors every texture:
What could be the reason of the problem? How should I fix it? Please, be aware that since DxWnd is hooking a generic program, it may easily have to confront with opengl calls that have an opposite purpose!
What you want is not generally possible just from hooking onto some other application.
You may be able to force blending to be on. But correct transparent rendering is a fundamentally different task from rendering an opaque scene. Because alpha-blended transparency is based on doing per-triangle blending operations with the background, it only really works if you render everything in a back-to-front order.
But as far as the program is concerned, it thinks it is doing opaque rendering. So it's going to render in the order it sees fit to use. Which for more modern applications is probably front-to-back, to take advantage of early depth testing.
And that's the exact opposite order you need to make transparency work. And there's no generic way to control the order of rendering just by hooking onto a few OpenGL functions.
Furthermore, applications tend to try to avoid rendering parts of the scene that are obviously not visible. So if the application thinks that a particular room is not visible because the door to that room isn't visible, then the room and its contents won't be rendered. So even if you could get the order of rendering correct, you'd also need to make the program change what it renders in order to correctly see through stuff.
It should also be noted that doing alpha blending requires that the fragments being rendered have a useful alpha value. But most fragment computations for opaque surfaces will have an alpha value of 1.0. And thus: no blending. And, unless you're dealing with fixed-function OpenGL rendering, or you're willing to manually patch shaders to add your own alpha uniform values, there's no way to change this from outside of the application.
I have a transparent OpenGL texture which has some simple shapes drawn on it by OpenGL:
circles, polygons, lines. They are drawn without anti-aliasing, multi-sampling, etc. Therefore, they have jaggy borders.
I don't have access to process of texture creation so I cannot enable multi-sampling
.
Is there a way to make those smooth AFTER drawing is done?
There are image-based anti-aliasing filters such as FXAA and MLAA that will work in this situation. I hesitate to call them anti-aliasing because they do not really avoid aliasing, they just hide it after the fact. They are more akin to intelligent blur filters.
I know from your other question that you do not want to use FBOs, so that leads me to believe you are using an OpenGL 2.1 or older codebase. FXAA can be implemented in GLSL 1.20, but it works better in 1.30 (GL 3.0). The one thing I do not know about is using FXAA on an image that includes transparency, it expects luminance to be encoded in the alpha channel (or sRGB, which is not a GL 2.1 feature).
You will probably not want to apply FXAA to your texture directly, rather you would need to draw into a PBuffer and apply FXAA after you blend your input texture.
I am currently drawing some geometry with "modern OpenGL" using QUAD and QUADSTRIP primitives.
I have faced with strange artifacts. My quads actually tessellates with visible triangles. Hope you'll see while lines across quads.
Any ideas?
Modern OpenGL (3.1+ Core Profile) does not support QUADS or QUADSTRIPS. Check for example here for allowed primitive types.
The culprit most likely is that you enabled polygon smooth antialiasing (still supported in compatibility profile), i.e. did glEnable(GL_POLYGON_SMOOTH) + some blending function. Artifacts like the one you observe are the reason, nobody really bothered to use that method of antialiasing.
However, it may very well be, that you did enable antialiasing in your graphics driver settings and the AA method used doesn't play along nicely with your program.
I have a problem with different visual results when using a FBO compared to the default framebuffer:
I render my OpenGL scene into a framebuffer object, because I use this for color picking. The thing is that if I render the scene directly to the default framebuffer, the output on the screen is quite smooth, meaning the edges of my objects look a bit like if they were anti-aliased. When I render the scene into the FBO and afterwards use the output to texture a quad that spans the whole viewport, the objects have very hard edges where you can easily see every single colored pixel that belongs to the objects.
Good:
Bad:
At the moment I have no idea what the reason for this could be. I am not using some kind of anti-aliasing.
System:
Fedora 18 x64
Intel HD Graphics 4000 and Nvidia GT 740M (same result)
Edit1:
As stated by Damon and Steven Lu, there is probably some kind of anti-aliasing enabled by the system by default. I couldn't figure out so far how to disable this feature.
The thing is that I was just curious why this setting only had an effect on the default framebuffer and not the one handled by the FBO. To get anti-aliased edges for the FBO too, I will probably have to implement my own AA method.
Once you draw your scene into custom FBO the externally defined MSAA level doesn't apply anymore.You must configure your FBO to have Multi-sample texture or render buffer attachments setting number of sample levels along the way.Here is a reference.
I'm having a problem getting accurate primitive colours when I'm using multi-texturing elsewhere in the scene. Basically, I have some lines and polygons that I am trying render over a video texture (I'm using 3 stage multitexturing to create the video texture)... Anyhow, I know the problem is not alpha related... In fact, I know that in my texture update function if I just comment out the calls to glBindTexture() for texture levels 1 and 2, the primitive color is fine (so leaving texture level 0)... Is it trying to multitexture the primitives too (even though I'm obviously not setting texture coordinates for primitives)?
Make sure to disable multitexturing when not using it. OpenGL uses a state machine, so if you turn on a texture it will stay on until you explicitly turn it off.
Just because you're not setting coordinates, doesn't mean OpenGL will assume you're not using the texture.