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?
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:
> 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)
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.
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();
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.