T3D MIT Master -- still giving "Warning: NaN encountered" (solution provided)

#1 daeAtomicType.cpp

daeBool
daeDoubleType::stringToMemory(daeChar *src, daeChar* dstMemory)
{
	src = skipWhitespace(src);

	if ( strncmp(src, "NaN", 3) == 0 ) {
		daeErrorHandler::get()->handleWarning( "NaN encountered while setting an attribute or value\n" );
		*(daeLong*)(dstMemory) = 0x7ff0000000000002LL;
	}
...
	else
	{
		sscanf(src, _scanFormat, dstMemory);
	}

#2 that is the source code generating the Warnings ... wondering if its a common issue with DAE files and can be ignored, just use the cached DTS to not get the errors?

#3 Progress! "NaN" ... I'm thinking it means "Not a Number"!

searching all DAE files for: NaN
./shapes/actors/Soldier/soldier_rigged.DAE : 8 issues found
./shapes/weapons/Lurker/FP_Lurker.DAE : 2 issues found
./shapes/weapons/Lurker/TP_Lurker.DAE : 8 issues found
./shapes/weapons/ProxMine/FP_ProxMine.DAE : 2 issues found
./shapes/weapons/ProxMine/TP_ProxMine.DAE : 6 issues found
./shapes/weapons/RifleShell/RifleShell.DAE : 4 issues found
./shapes/weapons/Ryder/FP_Ryder.DAE : 2 issues found
./shapes/weapons/Ryder/TP_Ryder.DAE : 2 issues found

Now question is, when encountered - can we replace it with "0" or some other value to get rid of the Warning message(s) spam?

#4 Solution:

Open each DAE file ... with something like "vi" or "gvim"

replace all instances of "NaN" with zero "0"

.. save

clear all cached DTS models ... and guess what, no more NaN spam!

coincidently: only found this issue with the collada models saved as .DAE for some odd reason ... all of the ones with .dae extension were fine.

maybe just those were exported differently or some such.

#5 If you are going to ignore NaN then why not have the code ignore and replace with zero without spamming the console? I would not imagine it would be fun or productive to replace NaN in the source DAE files every time you export from a modeling program.

#6 Frank@ Could be done, maybe there is newer version of COLLADA source even which handles it better.

For now, using cygwin + shell script to automate the process

I run it under game/art folder

#make file list
find . -name "*.DAE" > file.list
find . -name "*.dae" >> file.list
for FILE in `cat file.list`;
do
 test=`grep NaN $FILE | wc -l`
 if [ $test -gt 0 ]; then
  echo "$FILE had $test issues, resolving ..."
  # edit in place #
  sed -i 's/NaN/0/g' $FILE
  echo " ... $FILE corrected"
 else
  echo "$FILE - OK"
 fi
done

#7 Nice! I hate doing stuff like that by hand.

#8 That gets rid of the NaN errors ... to get rid of the others, used grep to remove all lines containing ".psd" or "file:". Just remember to escape the "." if using cygwin ("\.psd") or it will treat the dot as a wildcard.

... and that removes most all the spam from the art assets.

If I understood GiT better, would upload the fixes ... as its a bit embarrassing that the fresh "Full template" has tons of errors which everyone simply ignores.

And newbs likely bang their head against the wall trying to decipher "normal" errors/warnings like these vs. ones that they might introduce themselves.

#9 Yep, possibly embarrassing but not enough of importance for me at least to prioritize time to fix such harmless warnings... However, we do encourage anyone to contribute such a pull request - it's not that difficult once you adjust to the git way of doing things.

Truthfully, in the long run I would much rather see the Chinatown and associated soldier art replaced.

#10 Attempting to figure out GitHub ... created a branch from Dev and made the required "corrections" to the assets and committed these changes.

I think this is the correct URL to reference ...
[url]
https://github.com/jyaskus/Torque3D/commit/bffa3c4bdfaf64b6e5d525cc94335145518f3f79 [/url]

#11 If I understood GiT better, would upload the fixes ... as its a bit embarrassing that the fresh "Full template" has tons of errors which everyone simply ignores.

#12 Replacing nan with 0 does not seem to me as a proper solution. If you fill attribs and after that you rely on math operations, T3D will not crash but you would see some micro freezes in game.

#13 @Ivan - Please elaborate as I don't see the correlation between modifying the DAE file and micro freezes in-game. After all, first thing the engine does is import/convert the DAE files into binary DTS files.

With enough facts, maybe we can make a better solution

#14 I guess the 'correct' solution in this case depends on what *dstMemory is initialised to. The code above simply leaves it as-is if there is a NaN in the DAE file. If these values are initialised to 0 then that seems perfectly valid.

I'd also ask whether NaN is allowed by the DAE specification. If so, there probably shouldn't be a console error about it.

#15 Jeff, working with nans is really slow. It is well documented (IEEE standards).

#16 I assumed it was due to poor design or exporter, since both T3D and the DAE checker report the WARNING message.

But wikipedia shows how NaN could be used in floating point math;
en.wikipedia.org/wiki/NaN

So I see your point that it has its uses ... just still unclear if its actually intentional and makes a difference to the engine, once converted to DTS format ... or just ignored when encountered.

Regardless, my expectation was that art work included with an engine as an example should not cause warnings messages.