Openfl 3.6.1 has bug for Away3D primitives Bad bug!

Hello guys,

I have found bug openfl 3.6.1 because it has issues like Vector3D and Vector are not good. like this
sees primitives with hole or over layering.

Please remove bugged version 3.6.1!!!

I am testing with Openfl 3.6.0 because it works fine. I will show proof. please check away3D if you test Basic_Shading with openfl 3.6.1 if you run app you see what does it happen??? It is bad. I vomit…

You shopuld check openfl 3.6.0 with basic_Shading than it sees clean and works like Flash Player :smiley:

That is why I want because developers of Openfl should remove bad bugged latest version of Openfl 3.6.1

Current latest stable version is Openfl 3.6.0!!! Thanks!

Please install “haxelib install openfl 3.6.0”

Can you find out from the commits between 3.6.0 and 3.6.1 what has changed that caused your bug?

Please believe me! Please check Away3D example Basic_shading. Check my solution:

OpenFL 3.6.0:
screenshot

Openfl 3.6.1:
screenshot

That is proof… I am not spammer because who says me spam…

Check video! https://www.youtube.com/watch?v=7dPz2Z_wG2Q

Hi,

I don’t think @tanis was suggesting any spamming but just trying to narrow down the issue.

Anyway, although I’m not using the latest 3.6.1, looking at the commit log there could be an issue with the ‘updateDepthAndStencil’ method if you are compiling to legacy as the else condition disables the depth test functionality.

That’s just a guess but could be something try.

If I get chance I’ll give it a try.

Greg209

I already compile with -Dlegacy

I type always with command line “openfl build windows -Dlegacy -static -DHXCPP_X86” Than it is very smallest application wow. If you use debug version than it is just bit bigger than legacy static.

If you use other example non-legacy with debug = It is very very big over than 20 mb biggest application-data

Why does data of application save different like -Dlegacy with -debug and -static than it is maybe different size of content’s application

There were some contributions to our Stage3D layer, which may have interacted negatively with Away3D’s code.

We are starting to make changes to make Stage3D a “first-class citizen” in our focus on OpenFL. This means that instead of hosting the code (for other teams shaping it to support their libraries), we are working on making the Stage3D bindings behave the way Stage3D “should” behave. In the short term, this will mean that Away3D (and other libraries that use Stage3D) may fall compatibility, but we are doing what we can to work on finding areas that are not behaving as they should, addressing them, then seeing if we can try and collaborate to propagate any API changes needed by libraries that use OpenFL Stage3D.

I apologize that you have had problems with OpenFL 3.6.1, for your project, stay with the versions you have, we are trying to address any incompatibility issues with Away3D by the time we release again