With just a click of the mouse, your hard bodies transform into soft and springy structures. The only important thing is that R12 builds of plugins should not be used in R13 or R14.MaxonC4D has just posted some Exciting videos about what's new in CINEMA 4D R12 If you compile specifically for R14, Xcode 4.5 has to be used. For R13, Xcode 3.2.6 is still used (plugin will run in R14, too). In a nutshell: If you compiled your plugin in R12, you will have to make a rebuild in R13 to make it usable in R13 and R14 on Mac. See the changelist in the SDK documentation. the SplineCustomGui and SplineData member functions, or all functions like HPBToMatrix().
Cinema 4d r12 codes code#
However, some minor changes in the code may be needed to successfully compile it, since some parts in the API have changed, e.g. Plugin developers just have to rebuild their plugins in R13, using a project file derived from the R13 SDK project. Windows builds of any plugins have no problem. Even though the CINEMA 4D API allows using R12-compiled plugins in R13 and R14, it is strongly recommended to build a separate version for R13 (will also run in R14). Since a plugin build with a project file that was derived from the R12 SDK project does not crash in R12, plugin developers only have to care about their builds for R13 and R14. The R13 and R14 SKD project files are totally fine, so the problem will not occur in plugins compiled in those releases, anyway. As long as those symbols are exported in the plugin binaries, the operating system will attempt to use them. But as the problem is in the plugin developers’ binaries, it is the plugin developers who have to fix it. The problem has been identified, and information has been posted on PluginCafé. There is nothing MAXON could do about it. Two screenshots of Xcode 3.2.6, showing the critical setting. In R13 and R14, different parts of the CINEMA 4D core have been changed, and while none of those changes concerned the handling of plugins, it was enough change to make the problem of exported symbols apparent. Probably both of them.Īnyway, in R12 plugins would not crash, but that seems to be pure coincidence. It might be an unfortunate combination of project settings or a bug in the Xcode 3.2.6 stripper, which is also not totally unlikely. The weird thing is, even when the Strip Style was correctly set to Non-Global Symbols, the stripper would always throw an error and now perform any stripping at all. But after all, it depended on timing and contents of the memory if a crash would actually occur. Hence, when closing a dialog or allocating or freeing any resources, the new and delete from the plugin binary would be used instead of the appropriate functions from the CINEMA 4D SDK that would use CINEMA 4D’s own memory management. As a result, even critical symbols like new and delete have been exported and then used by the operating system. In the R12 SDK project, the Stip Style was set wrong: It would only strip out the debug symbols. When creating release build, usually all non-global symbols have to be stripped from the plugin binary. However, if the cinema4dsdk.xcodeproj of the R12 SDK was used, a setting in the release build settings was wrong. That is a legitimate way to create the project file for a CINEMA 4D plugin. When creating the project file for a CINEMA 4D plugin, most people usually copy the cinema4dsdk.xcodeproj, rename it, throw in their own sources, and change the product name. And even if the crash was reproducable, the debugger always ended up in a different location of the code (but it was always in CINEMA 4D, and not in the plugin that caused the crash). What made this error so hard to find was the fact, that it did not occur on every machine. A lot of plugins crashed on OS X, either immediately when CINEMA 4D was started, or when a window or dialog was closed. When R14 was released, the problem got worse. With the release of the latest R13 service update, some plugins started crashing on OS X.