Morph Exporting Plugin - chanBank problems solved!!!

[Anonymous]

Hey all,

There's been a lot of trouble around on forums on the net about trying to export morpher modifier's data. I also have had this problem.

The general complaints tend to be:-

Crashing when trying to access morph channel data.
chanBank vector in the MorphR3 class is empty.
MorphR3 class data is corrupted.
etc..

I am not quite sure exactly why this problem occurs, but we know why it breaks code and how to get around it so that you can export morph data from your exporter plugin.

The culprit is the morphChannel class. Again, I don't know why this is happening, because i am compiling the morpher dle myself, and referring to the wm3.h from my exporter in order to use MorphR3 classes and morphChannel classes, so it's not like i have two copies of the code that differ. Anyway, essentially, from within morpher.dle, the apparent size of a morpherChannel is 140 bytes. But from within my exporter dle, the apparent size is 172 bytes. This makes it obvious as to why data is appearing corrupted, when looking at the data from my exporter, we are looking through mis-aligned memory glasses you might say!

As i said, i can't think why the dles would think of morphChannel differently as there's only one copy of the source for the class, which is creating the lib file, which is used as input to the linker in my exporter. But simply extending the morpher.dle source to have getter functions for any data you want to export, will be a good enough work around. Also declaring the chanBank variable at the end of the MorphR3 class will help to ensure that's the only variable that is currupt in the eyes of the exporter, assuming data order in the memory isnt changed by any optimisation.

I hope that this post helps out some people out there, it's been doing our nutt's in and morph targets are essential for us! And i havn't found any other forum threads which actually tell of a solution! I'll be sure to post this wherever this problem is documented.

If anyone has any insight, to help further understand the cause of this class size difference, it would be appreciated :o).

Thanks,
Leigh

[Anonymous]

Narrowed down now to the fact that using a std::vector in a class is where the corruption starts, so any class in the morpher dle that has a std:vector in it, will need to have these variables declared at the end, and functions written for access to any information inside them.

even std:vector<double> gets broken when accessed directly from a pointer to the vector which is not from within morpher.dle (even though a message window displaying the memory value the pointer points to from my exporter dle, and the memory value the vector is stored at from within the morpher dle have the exact same result)

Leigh

[Anonymous]

http://www.programmersheaven.com/mb/CandCPP/310449/310449/needs-to-have-dll-interface-warning/?S=B20...

Explaination of why STL isnt working properly.

The STL classes cannot be accessed from dlls when not initialised by the same dll.

Essentially.. it's impossible to export morph targets from 3ds max without editing the morph target plugin that max comes with!

Good to know..