This seems to happen only on Linux systems, and freakabcd did some investigation into the matter, and IIRC it had to do somehow with the function for conversion the floats to strings.

Is this 32bit or 64bit linux?

32-bit ubuntu with packages from https://edge.launchpad.net/~cheleb/+archive/blender-svn

Self-compiled version of libftoa from svn passes all included tests, except for last test for doubles
don't match 0.9999999999999999: 0.999999999999999888977 and 0.9999999999999998

After having recompiled blender-32970 on my home machine I could not reproduce this bug anymore.

I have compiled using scons with preferences
WITH_BF_COLLADA = True
BF_OPENCOLLADA = '/home/lockal/bin/opencollada'

I have reported the PPA owner Ralf Hölzemer about this bug and hope the investigation will have a positive outcome.

Hi Lockal,
guy with the PPA on Launchpad here.

First, thanks for the heads up. I just tried to reproduce this error with the PPA build from today (32970) and couldn't find any issue here on my 64bit Maverick system.

Maybe this was some general error that was fixed recently?

Hi Ralf Hölzemer, this bug is still reproduceable with 32970 from ppa.

Just tried ppa version with fresh install of 32-bit Ubuntu 10.10 on VirtualBox with no success: still get 1000000 instead of 1.000000.

Hi Lockal S

I am trying to isolate the bug. With the latest attempt did you also did an custom compile of libftoa?

We have a hard time reproducing this issue and you are the only one reported this issue. Is this issue also happing to you when you download the 2.55 32 Linux binary build from blender.org?

Regards,
Jeroen Bakker.

It's seems I have found the solution. Btw, Collada export works fine with binary build from blender.org, also it works fine with -O0 build of OpenCollada. It even works well if I add printf("%f", f); to ftoa (looks like compiler cant inline or do other optimisations for f, so that hides this problem). So I added
printf("copyToBufferAsChar %x %.12f %s\n", *((unsigned int*)&f), f, getCurrentPosition());
after ftoa call (line 68 in common/libBuffer/src/CommonCharacterBuffer.cpp) and got something like this:
copyToBufferAsChar 3f7fffff 0.999999940395 1000000
copyToBufferAsChar bf7ffffd -0.999999821186 -1000000
copyToBufferAsChar bf7ffffa -0.999999642372 -1000000

I still don't understand, how libftoa works, because it should not work at all.

In common/libftoa/src/Commonftoa.cpp at line 56 you can see
float fabs = abs(f);

and few lines later
if ( fabs < 0.00001 )

abs implicitly converts its argument to int, so abs(-0.999999821f) is 0, but not 0.999999821. Probably fabs is the function, which should be used here. Same applies to Commondtoa.cpp

Patch is attached to this message. It resolves the problem for me (I also hope this case is not like printf line described above).

Oke,

Thanks, will review the patch, and if oke will let Nathan commit it.

Thank you very much for the effort!
Jeroen

Lockal,

the abs function does not convert an float to an int,
it convert an negative float to a positive float.

don't think you have solved the actual issue.

Jeroen.

If you use <math.h> and <stdlib.h> and do not know the difference between abs and fabs, please read
http://www.kernel.org/doc/man-pages/online/pages/man3/abs.3.html
http://www.kernel.org/doc/man-pages/online/pages/man3/fabs.3.html

Also you can use gdb disassembler to see the difference.

Also you can use flag -fdump-tree-optimized to see the code IR:
fabs = (float) ABS_EXPR <(int) f>;

Also you can use -Wconversion flag to see warnings about imlicit conversions:
common/libftoa/src/Commonftoa.cpp: In function 'float Common::roundingSummand(float, int, int&)':
common/libftoa/src/Commonftoa.cpp:56: warning: conversion to 'int' from 'float' may alter its value
common/libftoa/src/Commonftoa.cpp:56: warning: conversion to 'float' from 'int' may alter its value

Btw, there are many double2float and float2double implicit conversions in collada exporter, but those are not so important.

I have to admit, that the collada method only working for numbers |x| >= 1.0. Smaller nummers don't get to the expected if check. Will clean up the path and send to opencollada project. Don't see any harm in the fix.

Can you check if the attached fix also work for you before I send it to opencollada?

Index: common/libftoa/src/Commondtoa.cpp
===================================================================
--- common/libftoa/src/Commondtoa.cpp (revision 785)
+++ common/libftoa/src/Commondtoa.cpp (working copy)
@@ -50,7 +50,7 @@


double roundingSummand(double d, int maxLength, int& dezmialPointPos)

{

- double fabs = abs(d);

+ double fabs = fabs(d);

dezmialPointPos = 0;



if ( fabs < 0.00000000000001 )

Index: common/libftoa/src/Commonftoa.cpp
===================================================================
--- common/libftoa/src/Commonftoa.cpp (revision 785)
+++ common/libftoa/src/Commonftoa.cpp (working copy)
@@ -53,7 +53,7 @@


float roundingSummand(float f, int maxLength, int& dezmialPointPos)

{

- float fabs = abs(f);

+ float fabs = fabs(f);

dezmialPointPos = 0;



if ( fabs < 0.00001 )

Nope, your patch is broken, you should use other name for fabs variable.

Commonftoa.cpp: In function ‘float Common::roundingSummand(float, int, int&)’:
Commonftoa.cpp:56: error: ‘fabs’ cannot be used as a function

http://code.google.com/p/opencollada/issues/detail?id=148

fix is patched in Collada revision 786. I see in their source that they have left the name.

http://code.google.com/p/opencollada/source/browse/trunk/common/libftoa/src/Commonftoa.cpp?r=786

Variable name was changed in r788.
http://code.google.com/p/opencollada/source/detail?r=788

I think this problem can be marked as resolved and fixed now.

Has been fixed upstreams. I will update the libraries for win32 and win64 right away.

Closing.

r33806 and r33807