DAEParser throws exception on Std::parseFloat on Neko target

[chfoo]

I'm trying to load a DAE file but it's throwing an exception on the Neko target trying to parse a value that is already a float.

Called from sys.io.FileOutput::$statics line 1
Called from ApplicationMain::main line 79
Called from ApplicationMain::create line 111
Called from lime.app.Application::exec line 225
Called from lime._backend.native.NativeApplication::exec line 154
Called from a C function
Called from lime._backend.native.NativeApplication::handleApplicationEvent line 194
Called from lime._backend.native.NativeApplication::updateTimer line 689
Called from openfl.utils.Timer::timer_onTimer line 168
Called from openfl.events.EventDispatcher::dispatchEvent line 97
Called from openfl.events.EventDispatcher::__dispatchEvent line 218
Called from away3d.loaders.parsers.ParserBase::onInterval line 385
Called from away3d.loaders.parsers.DAEParser::proceedParsing line 204
Called from away3d.loaders.parsers.DAEParser::setupMaterials line 837
Called from away3d.loaders.parsers.DAEParser::setupMaterial line 779
Called from Std::parseFloat line 55
Uncaught exception - Invalid field access : __s

traverseChildHandler() handles getting the float XML element and parsing the value to a float. When entering setupMaterial() on ActionScript, the value is passed into Number() while the Haxe version uses Std.parseFloat() again. This fails on Neko target while C++ and HTML5 appear to accept this mistake and return the float as is.

While I do plan to use C++ and HTML5 later, I would like to keep using Neko during development because of its fast start up time. I would remove the extra parseFloat calls and make a PR but I'm not sure if that breaks any special cases or diverge from the ActionScript sources.

Versions:

• OS: Ubuntu 17.04 64-bit
• Haxe: 3.4.2
• Haxelib: 3.3.0
• away3d-samples: 5.0.1
• away3d: 5.0.2
• hxcpp: 3.4.64
• lime-samples: 4.0.1
• lime: 5.0.3
• openfl-samples: 4.9.0
• openfl: 5.1.2
• swf: 2.3.1

[chfoo]

So it seems like there isn't any noticeable problems removing the extra parseFloat and the LoadDAE example works. However, I discovered numerical issues with COLLADA files exported from Blender using defaults.

Exporting any complicated model, such as the default monkey model, will result in vertexData containing NaN values. Originally, I would load the DAE file, rotate 90 deg to fix the up-axis, and scale by 100. This would result broken geometry. But I found setting Blender's unit size to centimeter, scaling everything by 100 before exporting would avoid this issue.

I spent hours trying to debug the issue (testing on Neko, stepping through the debugger on JS), but couldn't narrow it down enough to see if it is issue with the source code conversion from ActionScript or something else. The array would suddenly contain NaNs after the Asset3DEvent event is dispatched.

Edit: I may have spoken too soon. Scaling by 100 and exporting still results in some NaN values.