8 pass accumulation Anti-Aliasing

How can I enable 8 pass accumulation Anti-Aliasing?
It appears that current version of Java3D only uses multisampling for anti-aliasing but it used to support 8 pass accumulation Anti-Aliasing in version 1.5.

Is there a way to switch on 8 pass accumulation Anti-Aliasing in the latest Java3D version?

Somebody already asked this question years ago here:
http://forum.jogamp.org/Why-antialiasing-does-not-operate-tp4027215p4027385.html

But his question was left unanswered.

Here's my code:

GraphicsConfigTemplate3D template = new GraphicsConfigTemplate3D();
template.setSceneAntialiasing(GraphicsConfigTemplate.PREFERRED);
GraphicsDevice defaultScreenDevice = GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice();
graphicsConfiguration = defaultScreenDevice.getBestConfiguration(template);
canvas = new Canvas3D(graphicsConfiguration);
Object n = canvas.queryProperties().get("sceneAntialiasingNumPasses");
System.out.println("sceneAntialiasingNumPasses = " + n);

But the output I get is always:

sceneAntialiasingNumPasses = 1

How can I get sceneAntialiasingNumPasses = 8?

My version:
Jav3D 1.7.0-pre1
Jogl 2.3.2

This issue was solved by Emanuel Puyberet some time ago as a final update to the 1.6.0 version of Java3D.

It was done after the branch to the new 1.7.0 version along with several other updates. Each was taken across to 1.7.0 individually but unfortunately this particluar fix was missed.

So it has been merged into the dev1.7.1 branch of JAva3D 1.7 here:
https://github.com/philjord/java3d-core/commit/239b497e3c012bfee176192cd344bbeb0c3cf192

So if you pull that code branch you can use as many passes as you need to by way of the j3d.numSamples property.

(I've added this reply only to allow others to find this fix, as I'm sure you've already got it and moved on)

On 2/1/20 10:33 PM, philjord [via jogamp] wrote:
> This issue was solved by Emanuel Puyberet some time ago as a final update to
> the 1.6.0 version of Java3D.
>
> It was done after the branch to the new 1.7.0 version along with several other
> updates. Each was taken across to 1.7.0 individually but unfortunately this
> particluar fix was missed.
>
> So it has been merged into the dev1.7.1 branch of JAva3D 1.7 here:
> https://github.com/philjord/java3d-core/commit/239b497e3c012bfee176192cd344bbeb0c3cf192

https://jogamp.org/cgit/java3d/java3d-core.git/commit/?id=239b497e3c012bfee176192cd344bbeb0c3cf192

>
> So if you pull that code branch you can use as many passes as you need to by
> way of the j3d.numSamples property.
>
> (I've added this reply only to allow others to find this fix, as I'm sure
> you've already got it and moved on)

Excellent!

Thanks Phil,
I downloaded your build from here:

https://jogamp.org/deployment/java3d/1.7.0-final/

But it looks like it's missing this crucial NPE fix:

https://github.com/philjord/java3d-core/pull/3

So it's unusable for my JCanvas needs.
Could you please build a new jar that includes the NPE fix?

It would be nice to upload a more recent build of Java3D 1.7 into jogamp.org/deployment.

Ok no problem, we don't currently have a naming protocol for a non-RC and non-autobuild incremental versions to be published under.
So I'll publish it in
https://jogamp.org/deployment/java3d/1.7.1-build-20200221
in a few hours.

Great thanks Phil.
It's not there yet but I wait.

Actually I just noticed that the fix to NPE seem to have been later reverted!
Do you know why? Was it fixed in a different way? Or not fixed at all?

Oops, nevermind, I was looking at 1.7.0 branch. The fix was later reapplied to branch 1.7.1
So all seems fine. Will wait for the build.

Ok, the build is up at
https://jogamp.org/deployment/java3d/1.7.1-build-20200222/

Note the javadocs are unchanged for external API so I haven't uploaded those again, please use the javadocs from
https://jogamp.org/deployment/java3d/1.7.0-final/

Why do those JARs have different names in 1.7.0 and in 1.7.1? j3dcore.jar -> java3dcore.jar It's a bad idea, it must be fixed.

Good point, I've corrected those names now.

Perfect, I tested it and it works great now.

Curious, what will happen if I set "j3d.numSamples=8" in a computer with graphics cards that doesn't support that level of multisampling?
Will it crash or automatically switch to a lower level?

Great teamwork.

Thank you Phil & Julien and Saeid,
keeping things rolling.

~Sven

On 2/23/20 2:33 AM, philjord [via jogamp] wrote:
> Good point, I've corrected those names now.
>

Thank you Phil.

Sorry to disturb you again but all 7z archives in 1.7 have inconsistent names whereas I name them jogamp-java3d.7z in 1.6 :s

Julien,
Another good point, however I decided to put that version number in deliberately to allow people to easily download multiple version without having to rename themselves. Unless there is a strong reason to use the short name for zip files I'd like to stick with the included version id for zips.

You just reminded me I didn't update the zipped filenames, fixed now too.



Saeid,
Your questions sounds very straight forward, but in pulling together an answer I've found it's far more complex than I thought (in particular becuase numSamples skips the GraphicsConfigTemplate3D  system.

A very short answer is that like the depthBuffer size request the system should happily return less than asked for and carry on.

I suspect that if you demand antialiasing though a request like this:
 GraphicsConfigTemplate3D template = new GraphicsConfigTemplate3D();
        template.setSceneAntialiasing(GraphicsConfigTemplate3D.REQUIRED);
        GraphicsConfiguration gcfg = GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().getBestConfiguration(template);

there is a chance the system will refuse to initialize if there is no anitalising support, but that's not quite teh question you asked.

I will get a proper answer back to you in a few days on what capability requests may be able to cause trouble.

I know that in the past (15 years ago) I've had to use the implictAntiAlising system property on MacOS to get it to work.

This isn't what is done for JogAMP itself, we don't put the version number in the name of the 7z file. The more inconsistencies we add, the more troubles we get in return. The version number is already in the directory, it doesn't make sense to put it into the filenames.