Antialiasing in Away3D


I’m using Away3D for a small project. I’ve just discovered that the old way to enable antialiasing (antialiasing=“4” in project.xml) doesn’t work for me anymore.

Tested on windows and html5 targets, lime=7.1.1, openfl=8.5.1, away3d=5.0.7

Any ideas how it could be resolved?


Hello, is that for html5 target? If so, I suspect it might have been resolved with

Hello, is that for html5 target? If so, I suspect it might have been resolved with …

This commit is a part of 7.1.1 which I’m using, so unfortunately there is something else. Also as I said the same happens on native targets.

Just giving my results on AntiAlias

I’m on Revision 6, major 4, minor 1 (Away3D.hx file)

HTML5 : Not Anti Aliased
Flash : Anti Aliased
Windows : Not Anti Aliased
Android : Anti Aliased

When I searched a while back there were some post about IE not using direct.
I’m using Chrome for all my tests.

I’m doing this:

view.antiAlias = 4; // Did not do anything project.xml!

Same here. Not related, but I doubt anybody updates these numbers. Judging by the changelog the latest version is 5.0.6. The latest version in haxelib is 5.0.7.

For me it’s like this:

Windows, Mac: Not anti-aliased
HTML5 (Chrome, Edge): Not anti-aliased
Flash, Android: Not tested

View3D.antiAlias has never worked for me. I mean it didn’t work a year ago when antialiasing="4" worked and it doesn’t work now. This xml attribute (antialiasing) still affects non-away3d stuff (or is it non-Stage3D stuff?), for example it’s noticeable on the edges of a slightly rotated Bitmap.

I’ve spent a lot of time trying to figure out how all these anti-aliasing settings are supposed to work and for now the most suspicious place for me is TextureBase.__getGLFramebuffer. As far as I understand this function is used to create framebuffers. It has a parameter which is called antiAlias, but it’s not used anywhere.This class (along with Context3D) has been dramatically refactored recently, so it’s hard to trace how it had worked before.

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).

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)

And with View3D.antiAlias on 4 :


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 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

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.



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)
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"?>
 <define name="openfl-share-context" value="" unless="flash" />
 <window background="#00000000" antialiasing="4" unless="flash" />

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.?