Antialiasing: No longer toggled?

A few tests seem to indicate that “NodePath.setAntialias(…)” no longer works as (I think that) it once did.

If I have “framebuffer-multisample 1” and “multisamples 2” set in my PRC file, and NVidia settings permitting, antialiasing seems to be activated. If they are commented out, it isn’t (as expected).

In the former case, calling “NodePath.setAntialias(…)” while the game is running doesn’t seem to affect the rendering, whether to activate or deactivate it.

I’ve tested this (albeit not exhaustively) in both Windows and Ubuntu Linux, I believe.

I’m pretty confident that this was working previously. :confused:

i think this has something to do with the display driver or render API (DX/GL) or the GPU. with my PC, Intel GPU, setting AA never works right, it’s either full on or full off.

Hmm… I’m pretty confident that I was using OpenGL when the feature was working, and haven’t switched since. (After all, my primary development environment is Ubuntu Linux.) As a result, I doubt that it’s an inherent difference between OpenGL and DirectX. (Unless something has changed there, of course.)

Similarly, I don’t believe that my GPU has changed since I last saw the feature working.

Changes in the graphics drivers are a distinct possibility, I think.

I did switch to the latest version of the Panda3D SDK (at time of writing; 1.9.3), as I recall. I have seen this issue in a deployed build–but I imagine that changes made for the SDK are integrated into the modules used by the runtime, as well.

A thought: if the drivers are the source of the problem, but they do respect the requested frame-buffer properties, would it be feasible (and safe) to implement in-game toggling of antialiasing by changing the frame-buffer properties (and presumably recreating the main window so that they take effect)?

2 multisamples is not a whole lot. Whatever effect that causes wouldn’t be very noticeable.

Do you use any postprocessing effects? The “framebuffer-multisample” and “multisamples” config variables only affect the main window, and not any scene buffer you may be using, which is what should actually receive the multisample configuration.

I do not believe it is possible to change the framebuffer configuration without reopening a buffer/window.

Do you mean in terms of performance, or visual effect? In both cases, the difference is at least visible, whether in terms of relatively-jagged edges or frame-rate/time–the latter perhaps more than the former.

Hmm… I’m honestly not sure of whether anything that I’m doing would count.

Perhaps I should describe in brief the shader-setup that I have:

  • I’m not applying any full-screen shaders on my end. (I imagine that this is what you were asking.)

  • There are two shadow-casting cameras. These each have a simple shadow-caster shader applied to them. They both use the “render” node as their scene. They each render to an off-screen buffer, which is used later to generate shadows.
    – Only one of these should be active at a time, and I switch between them in game-logic. (One represents the sun-light, and the other the player’s lantern.)

  • Levels have a “root-node”, which is a child of render. has this as its scene (not render), so that the shadow-caster shaders don’t take effect.

  • Various nodes beneath the “root-node” have various shaders applied (some of which make use of the above-mentioned shadow-buffers), although there are two “standard” shaders (one for each light) that are more commonly-used than the others.

  • Portal-culling is active. (I doubt that this has any effect, but I mention it just in case.)

That’s more or less what I was thinking of, I believe–a little drastic, but better than writing out to the PRC file new values for the multi-sample variables, and then asking the player to restart the game entirely.

(Another option, of course, is to just leave a note attached to the antialiasing check-box indicating that it may not work with some setups, and directing the player to their graphics card’s utility program.)

I’d like to continue on from this topic, if I may:

In general, how do modern games approach the question of toggling anti-aliasing? I’ll confess that it’s been a while since I tried such an option in a game, but I imagine that few games require that the player restart the game when anti-aliasing is toggled–so what do they do?

I’m really not sure of how to approach this in my game, right now–“NodePath.setAntialias(…)” doesn’t seem to work reliably, remaking the main window seems like a somewhat-drastic method, and I wonder whether having a multi-sampled buffer doesn’t incur a performance cost even if anti-aliasing is disabled… :confused: