[JDHill]

The main thing I notice is that in the r14_dae_w_mr.dae file, decimals are being written using commas, while in all the other dae files, they are written using periods. As far as I know, it is not legal to represent floating-point numbers this way in COLLADA; they are to use periods as decimal separator, and it is therefore no wonder that hdrls is choking on the data . I don't see any way for our plugin to cause such a change, so I assume it must simply be an effect of Cinema having loaded it, which is only showing up in R14. It would be interesting to see if you can observe this same effect by exporting a .dae yourself, rather than by means of the hdrls plugin.

And by the way, for making such comparisons, I generally use WinMerge (http://winmerge.org/). Not sure whether that would be too useful for you, but it's free, and can come in handy in quite a few situations, especially since it can compare entire directories.

[mashium123]

yes, exporting to a dae-file via c4d itself leads to the same difference:
with maxwell it's commas, wihtout it's dots.

now, all those dae-tests (the one with the hdrl-export as well as the export via c4d) had been done with the dae-version 1.5.
when i export from cinema using the dae-version 1.4 (the file says version 1.4.1) the problem is gone, even with maxwell installed. no commas anymore and hdrl processes the file in a normal way without errors.

[JDHill]

Interesting. One more comparison, then, would be: check the collada 1.4 vs 1.5 results in R13, to try to isolate the behavior to collada version, rather than Cinema version.

[mashium123]

here's a zip containg 4 files: dae exports via c4d, all with maxwell-plug installed.
http://www.mesutcapkin.com/temp/c4d_dae ... 13_r14.zip

r13 with 1.4.1 and 1.5 c4d-exports: all with dots.
r14 with 1.4.1 with dots, r14 with 1.5 with commas.

[mashium123]

while trying to find out why the presence of the maxwell plug screws up dae_1.5-export in r14, i could try and workaround the hdrl-problem by telling the hdrl-plug to use the 1.4.1 dae instead of 1.5.
but how would i do that?

the .pyp-file says in lines 475-477:
"formatIds = [ c4d.FORMAT_C4DEXPORT, 1025755, c4d.FORMAT_OBJEXPORT ]

formatSuffixes = [ 'c4d', 'dae', 'obj' ]"

my guesswork would be that the number "1025755" stands for the dae-format being used, which would be 1.5.
would this number be some kind of a "id-numer" for that 1.5 version of dae, which c4d understands?
if so, would the 1.4.1 version not also have an id-number? if so, where would i have to look it up so i can try and write that number down instead of the 1025755 and see, if the plug then exports using dae version 1.4.1.
not sure... is that the way those things work?

[mashium123]

ok, i found the id. it's 1022316. have put it in there. and it works. great! workaround established.
thx for your guidance.

now, our r14/maxwell/dae1.5-problem still remains of course.

[JDHill]

Ha, you keep posting too fast, as I'm doing my research. Searching, I also found an old reference indicating the COLLADA exporter as being identified with 1022316. I find that nowhere in the whole of C4D, though, it's totally undocumented.

Anyway, to sum up, we have pretty much narrowed it down to the 1.5 COLLADA exporter in Cinema R14. And in theory, you should be able to erase that difference by changing your OS decimal separator to period, rather than comma. I am not aware of anything our plugin could be doing to cause that, and I believe that even if it were, the Cinema COLLADA exporter should under no circumstance output commas, since as far as I can tell, that is not valid for the COLLADA file spec.

[mashium123]

Ha, you keep posting too fast, as I'm doing my research. Searching, I also found an old reference indicating the COLLADA exporter as being identified with 1022316. I find that nowhere in the whole of C4D, though, it's totally undocumented.

probably we've found that one in the same spot - an cgsociety-archive from november 2011?

Anyway, to sum up, we have pretty much narrowed it down to the 1.5 COLLADA exporter in Cinema R14. And in theory, you should be able to erase that difference by changing your OS decimal separator to period, rather than comma.

yes. i changed the id back to the dae 1.5 version and changed the OS seperator instead. it works.
now i'm able to export dae1.5 files with maxwell installed and everything seems to work fine.

I am not aware of anything our plugin could be doing to cause that, and I believe that even if it were, the Cinema COLLADA exporter should under no circumstance output commas, since as far as I can tell, that is not valid for the COLLADA file spec.

i'm not really sure it would help, if i reported this as a bug to maxon. since they would need the maxwell plug-in to recreate this problem, wouldn't they? so, somehow our plug-in seems to be involved?

[JDHill]

Actually, I found it on plugincafe.com, in a question by our own Kabe (I wonder what he is up to these days). On the last question, I'd like to wait until I can check it out here myself, before involving Maxon. As I say, I don't see how the plugin could cause it, but I'd like to be able to prove that.

In the meantime, here is one more thing that would be interesting to check: move the R14 Maxwell plugin somewhere else, replace it with a copy of the R12-R13 plugin, and see how the R14 1.5 dae exporter behaves. The R12-R13 plugin should work fine, except for some some particles stuff. The difference is, the two are built against different Cinema SDKs.

[mashium123]

ok, i changed the OS seperation back to commas, just like it was before.
moved out r14plug and placed the r13 instead. exported dae1.5: no commas. everything looks fine.

[JDHill]

Interesting. The R14 SDK and plugin use a different version of the compiler, a different VC++ runtime, and the plugin also loads different versions of the Maxwell extensions. So the environment is substantially different when running the two plugin versions -- thanks for checking it.

[mashium123]

just thougt, i'd mention that today's update to 14.034 didn't solve our problem concerning the dae1.5-export.
not that i expected it to do so, since the release notes don't list any changes in that region.

[mashium123]

just wanted to keep you updated:
i downloaded the new 4.1.1 release of hdri lightstudio today and i also saw that there's a new version of the c4d-plug in for it. i installed that one too and now i don't seem to be able to reproduce the effect any longer.

[JDHill]

Thanks for the update, I'll try to check it on this end too.

[Aniki]

Yes, previous hdrls plugin had flaws in the export (collada), so its not maxwells fault.

Works now as they fixed the plugin.