Antialiasing in Away3D

Stage3D has anti-alias settings per texture, perhaps this is interacting with global anti-aliasing somehow

I think we are talking about different kinds of anti-aliasing. Texture anti-aliasing (smoothing?) works fine. Global anti-aliasing (multi-sampling?) doesn’t work for me. And in my current project I’m not using textures much, mostly it’s just solid colours (ColorMaterial).
multisampling

I assume the full canvas anti-aliasing setting is browser-specific, whether it works correctly?

This is getting interesting!

I’ve tested on Mac OSX as well and the same is happening as with Flash! So view.antiAlias = 4 does work. Without the view.antiAlias call it is not antialiased~
Also iOS simulator is using anti-alias just fine.

Is there another way I can find out what version of Away3D I’m using besides the Away3D.hx file?! I’m (still) using the openfl build from September 2017. Not sure what version was active at that time?!?!
I’ve made some changes to the chain for my personal use, so I’m a bit hesitant to just download the latest version.

Results of my view.antiAlias settings (Flash, but Mac and Android behave the same)
Flash_No_Alias

And with View3D.antiAlias on 4 :

Flash_Alias_4px

Sphere is with ColorMaterial.

With TextureMaterial the edges are anti-aliased even when I don’t have view.antiAlias set!!!

So the issue is with non-texturized materials on particular build targets …
but it depends on the toolset / version that is used!!!

I’ve different systems with different versions of OpenFL and Lime (it comes with Stencyl which I’m using)

Mac,iOS and Android publications systems are using:
OpenFL 8.0.0
Lime 6.3.0

Windows building platform is using (Flash and HTML5 respond the same as with the 8.0.0/6.3.0 combo: so flash works and html5 doesn’t)
OpenFl 8.5.1
Lime 7.1.0

So I guess you are indeed referring to lime/openfl doing things differently, but you said that view.antiAlias is and was not working before? That could be that we both are using different Away3D builds?!?

Tried windows build on another system that uses
Openfl 8.5.0
Lime 7.0.0
And the antialias didn’t work!!

Tried older versions on Windows:
OpenFL 8.0.0
Lime 6.3.0
And the antialias for windows build still didn’t work!!! But building to Flash does produce aliased result!

So I don’t think it is the Away3D version but what you reported on the lime and openfl combinations!
Still I find it interesting that your view.antialias did not make a difference …

I tried following the source code and went from display to stage to window, to lime app window and in the end there was lime/lime/app/Config.hx that has the antialiasing in it. I’m still not sure where this is set in the different target builds, but my guess is that we need to find it in Lime …

(hope this all helps!?!)

@mdotedot Perhaps you can track the date/time that you downloaded the Haxe version of Away3D, here’s the commit history:

Ah … OK I have 5.0.2 then.

Update to 5.0.2

@jgranick

jgranick committed on Aug 3, 2017

The entry from Aug 3 is in my source file but the Aug 17 entry was not!

That makes it easier for m.e. to check the differences between latest version and my branch.

Now to find the difference between (Lime/OpenFL) on Windows and Mac. I know that a lot of time there is code for either js, flash or cpp. Sometimes there are things like

#if windows

and there might be things like

#if mac

But is there a single or limited number of files that specifically set things for Windows / Mac ?

I thought most of the target specific things are in Lime?! Should we indeed track the differences in that library?

Oh yeah, there would be a lot of changes between that version of OpenFL or Lime, and the current ones. Yep, we do have a number of platform-specific defines, it sometimes has to do with things like default fonts (which are different per platform), but most of the time it would be native vs. Flash vs. HTML5

Hi,
missing antialiasing in HTML5 here too!
I have updated to the new libs (Lime 7.1.1 + Openfl 8.6.1-8.6.2), and noticed a clear improvement in the Away3D performances, but antialias seems to be missing now.

anti
before…

no-anti
after…

Do I have to wait for a fix?

Do you guys think this is an issue with how our GL context or canvas is initialized, or is this something with Stage3D instead? Does building using -Dopenfl-share-context make a difference?

Yes, it does, everything is nicely antialiased with this thing :slight_smile:
Tomorrow I’ll try to tell (and ask!) more…

So, as I said, this parameter helps and with a shared context3D anti-aliasing works as intended. Well, View3D.antiAlias is still not working for me, only antialiasing in project.xml does, but that’s less important. Do I understand correctly, that the problem is with these newly created separate Context3D’s not receiving (and not "applying’) correct antialiasing value through Context3DState?

Yes, it helps, antialiasing now works for me too.

Want to send you the results of my tests: all is good!

Flash   : OK
HTML5   : OK (share context)
MAC OSX : OK  
Windows : OK (share context)
Android : OK
iOS(Sim): OK
Linux not tested

(I’ve tested them all with the below configuration even though some of them worked before without it!)

Since I’m using Away3D as an extension I needed to use this include.nmml:

<?xml version="1.0" encoding="utf-8"?>
<project>
 <define name="openfl-share-context" value="" unless="flash" />
 <window background="#00000000" antialiasing="4" unless="flash" />
</project>

And it works without having to set the View3D.antiAlias

The code for blitting separate Stage3D contexts to the primary one is like this:

Also, they are rendered first to a separate framebuffer. Perhaps the issue here is that either the Context3D framebuffer needs to have additional options set for anti-aliasing, or perhaps the issue is how they are being rendered to the main backbuffer here?

I came to this topic with similar intent and can confirm that yes, enabling the shared context works.

My challenge is that doing this makes the Away3d view steal mouse events from other objects on stage. To fix this I attempted to disable shared context again and then access the Context3D (similar to the method outlined on this thread) and set antialiasing that way but it doesn’t seem to work. So I am wondering:

  1. Has anything gotten easier in this area since this question was first asked, and:
  2. If I must share my context, can anyone offer tricks to ensure that other UI objects placed on stage continue to respond to clicks, etc.?

Looks like this is the issue:

Sounds like WebGL 2 can support it if we had the extra code to manage it

Just noticed this; thanks for the reply! So to summarize, there is a framebuffer used when the context is not shared, and that is what loses the antialiasing?

Yep that’s it — shared forces use of the same canvas instead of a framebuffer

Hmm… I always use shared context, and never has a problems with mouse events (openfl gui objects over view3D scene works fine)… Maybe, your View3D (Away3D) size differs from stage (OpenFL) size? That may cause a many problems with context sharing, because Away3D will try to resize whole shared context for it’s own size and will cause a conflict.

1 Like

It is a different size from the stage. Maybe I can experiment with having it full size; thanks for the input!