Cinema 4D R19 C++ SDK Documentation
-
On 01/09/2017 at 04:57, xxxxxxxx wrote:
User Information:
Cinema 4D Version:
Platform:
Language(s) :---------
Hello everyone,Cinema 4D R19 got released today.
We have uploaded accompanying C++ SDK documentation, see the
announcement here[URL-REMOVED].
The R19 online documentation replaces the R18 documentation, but the R18 documentation is still available on thedownloads page[URL-REMOVED] (as ususal).Any comments or feedback will be appreciated.
Best regards,
your SDK Team
[URL-REMOVED] @maxon: This section contained a non-resolving link which has been removed.
-
On 01/09/2017 at 05:12, xxxxxxxx wrote:
I was waiting for an official message regarding the SDK.
Seems plugins built with R17 SDK does lockup R19, so I was looking forward to any information.
The R19 SDK apparently needs Visual Studio 2015.When following the link you provided, this still points to the R18 documentation.
EDIT:
Ok, got it. When following "Changes in SDK" there's an entry "Changes in R19", which indeed mentions Visual Studio 2015 or higher.
But the main page still refers to R18EDIT2:
Quickly browsed through the API changes.
Is this a typo in the documentation, or has it been defined like this?
#define BITMAPBOOL_TOGGLEACTIVAION -
On 01/09/2017 at 05:15, xxxxxxxx wrote:
Which link? Maybe your browser just needs a reload?
Or of course I have forgotten to update one. Then please give me a pointer which. -
On 01/09/2017 at 05:21, xxxxxxxx wrote:
You're right, browser reload required. Sorry.
-
On 01/09/2017 at 06:20, xxxxxxxx wrote:
I'm a bit confused by your comment under "EDIT" in your first post, but maybe that's just by the timing of your edit and my answer.
BITMAPBOOL_TOGGLEACTIVAION: Quick catch! Unfortunately it really is defined this way and slipped through all out checks. Sorry.
R17 plugins in R19: We are not aware of any incompatibilities. The SDK examples compiled with R17 still work in R19, no lock up or crashes experienced here. We of course can not talk for 3rd parties. Maybe you can check, which plugin it is exactly. And if we have contact to the developer, we can make them aware and discuss the issue.
-
On 01/09/2017 at 07:02, xxxxxxxx wrote:
My first edit was probably at time when you had already answered, only saw your reply after submitting the edited text.
The R17 plugins that locked up R19 were my own plugins, hence the reason why I tried to find information, and then saw that R19 requires Visual Studio 2015.
I'll further investigate the lock up.EDIT:
I noticed the first time when I started R19 with two of my plugins that Cinema locked up.
First tried with one plugin installed, next tried another plugin. So each time only one plugin was installed. R19 would load and before initializing the viewport, Cinema would lock up.
I guess this problem might be more related to OpenGL and my laptop display driver. But Cinema didn't lock up when none of the plugins were installed. Coincidence?
In the meantime I have rebuild the plugins with R17 and R18 SDK to further investigate, and cannot reproduce the problem. -
On 01/09/2017 at 15:36, xxxxxxxx wrote:
Originally posted by xxxxxxxx
The R17 plugins that locked up R19 were my own plugins, hence the reason why I tried to find information, and then saw that R19 requires Visual Studio 2015..
Just testing my plugins here in R19 and they are all working fine. Compiled using R17.053. There was an issue with earlier versions of R17 not working in R18 (I think it was R17.041). But compiling against 053 works fine.
Note that I did not upgrade to R17.055 since it caused my projects to constantly do a full rebuild every time, there was some change in the C4D framework which I never hunted down. So I stuck with 053 and everything is good in R18 and R19 so far.
-
On 01/09/2017 at 19:21, xxxxxxxx wrote:
Looking a bit to the new delegate exemple, and saw the use of iferr. After reading the documentation, I'm not sure to understand the purpose of this macros, or at least to understand what it check exactly.
Since in other exemples you use the common (!nullptr) to check a pointer, I think it's must be directly linked to delegate but not sure.Anyway it's a very nice release, and loving your new comment style, it make the new features very easy to learn !
-
On 03/09/2017 at 00:55, xxxxxxxx wrote:
Originally posted by xxxxxxxx
The R17 plugins that locked up R19 were my own plugins, hence the reason why I tried to find information, and then saw that R19 requires Visual Studio 2015.
Just thought I would let you know that I had to rebuild my plugins in VS 2015 for R19. This was required because I statically link in other libraries. All the libraries I link with also had to be rebuilt using VS 2015 so that they are all using the same runtime. If you dynamically link to libraries you should be ok. But if your plugin statically links to any libraries you will need to rebuild them using VS2015. If you don't do this then you will experience crashes and instability. It will crash in the VS runtime dlls. If you don't use any other 3rdparty libraries, and just stick with the C4D SDK itself, then your plugins should work fine if you compile with VS 2013 (ie R17, R18 builds).
-
On 04/09/2017 at 01:53, xxxxxxxx wrote:
Hello,
the "iferr" macro is only an internal compatibility macro that has no use for third party developers.
best wishes,
Sebastian -
On 05/09/2017 at 07:23, xxxxxxxx wrote:
By now I have talked with development about possible issues with plugins compiled for older versions or compiled with older Visual Studios.
As long as you only work with our API, we do not expect any issues at all (as the tests with our SDK examples also show). As Kent already mentioned, when linking against any 3rd party libraries, you need to make sure, all are build with the same Visual Studio/compiler version.
A few assumptions, why there may be issues with 3rd party libraries. Microsoft seems to have done some changes to the ABI (Application Binary Interface). If a 3rd party library makes use of features touched by these changes, you'll run into issues. In this case recompilation (of all parts) with VS2015 is the only solution.
Another idea regards Thread Local Storage (TLS). For details see MSDN on TLS. The point is, the keys for TLS are limited per process. MAXON tries its best to use as little as possible. Still the amount is limited and every plugin uses some of these keys. The exact amount depends heavily on the plugin and for example also on the amount of libraries a plugin got linked against. By the way, this is also the reason, the number of plugins that can be run simultaneously is limited and can't be specified exactly. In order to test if this is an issue, remove some of the installed plugins and see if the problem still exists.@Kent: Can you provide us with some details on the issues you have encountered?
Edit: Fixed MSDN link to international one.
-
On 05/09/2017 at 13:50, xxxxxxxx wrote:
Issues linking to external libraries in R19
When I was testing initially with a build from R17 in R19 I was having crashes in the ucrt.dll, called from the vcruntime.dll. My crash occured simply when cloning a sculpt object, nothing to do with any of my own actual code.In VS 2015 they changed the way the runtime works. They refactored out the c-runtime libraries.
https://msdn.microsoft.com/en-us/library/abx4dbyh.aspx
This is most likely the cause of my crashes since I make use of some libraries that use stdlib. Again note that none of my code was called at all, just linking to old libraries was enough to cause the crashes.
So for R19 I now compile using VS 2015. I also have to link to ucrt.lib and vcruntime.lib.
Issues linking to external libraries in R19
When I was testing initially with a build from R17 in R19 I was having crashes in the ucrt.dll, called from the vcruntime.dll. My crash occured simply when cloning a sculpt object, nothing to do with any of my own actual code.In VS 2015 they changed the way the runtime works. They refactored out the c-runtime libraries.
https://msdn.microsoft.com/en-us/library/abx4dbyh.aspx
This is most likely the cause of my crashes since I make use of some libraries that use stdlib. Again note that none of my code was called at all, just linking to old libraries was enough to cause the crashes.
So for R19 I now compile using VS 2015. I also have to link to ucrt.lib and vcruntime.lib.
Dealing with Reflection Layers
I have also been working on support for dealing with Reflection Layers. In R18 the API was changed for ReflectionLayer which means that R17 plugins will no longer run in R18 onwards. They removed the "flags and name" parameters from the SDK and replaced it with functions. This means that if you run your plugins in R18 (or R19) it will lock up or crash since it will no longer be able to get to the data and will point somewhere randomly in memory.The end result for me
So now I have gone from only having to compile 1 version on OSX and 1 version on Windows to having to compile 3 versions on OSX and 3 versions on Windows.
So for me the forward compatibilty of Cinema 4D development is completely gone. From now on I am forced to build a separate version for each C4D version on each OS. But I am perfectly happy to do this, and should have done this from the beginning.So its finally time for me to setup a proper automated build process.
For everyone one else
If you decide to start using Reflection Layers you will need to at least build separately for R17 and R18, on both OS's.If you link to external libraries you will also need to build them separately for R19 due to the changes in VS 2015 (this is not C4D's fault).
If you don't use Reflection Layers and don't use any external libraries then versions compiled in R17 should work fine in R18, R19. At least the C4D SDK Examples work fine in all of my testing. But for me this is no longer an option so I will be compiling for every new version from here on out.
My Opinion
Even though its nice to have this forwards compatibility with future versions of C4D, I do believe compiling against the latest C4D SDK is always best. So I would recommend all developers to build fresh for each OS for each new version of C4D if you are using C++. I am perfectly happy to do this from now on. The added benefit is that I can now add in features for each specific version when C4D adds new features to the SDK. And in doing so it ensures that nothing has changed (or been removed) in the SDK that will break my plugins (ie ReflectionLayer SDK changes).The way around all of this is to just use Python. So if you don't need to access external libraries, don't require anything computationaly expensive, then Python is a much better solution.
-
On 06/09/2017 at 01:57, xxxxxxxx wrote:
Originally posted by xxxxxxxx
Issues linking to external libraries in R19
When I was testing initially with a build from R17 in R19 I was having crashes in the ucrt.dll, called from the vcruntime.dll. My crash occured simply when cloning a sculpt object, nothing to do with any of my own actual code.In VS 2015 they changed the way the runtime works. They refactored out the c-runtime libraries.
https://msdn.microsoft.com/en-us/library/abx4dbyh.aspx
This is most likely the cause of my crashes since I make use of some libraries that use stdlib. Again note that none of my code was called at all, just linking to old libraries was enough to cause the crashes.
So for R19 I now compile using VS 2015. I also have to link to ucrt.lib and vcruntime.lib.
Dealing with Reflection Layers
I have also been working on support for dealing with Reflection Layers. In R18 the API was changed for ReflectionLayer which means that R17 plugins will no longer run in R18 onwards. They removed the "flags and name" parameters from the SDK and replaced it with functions. This means that if you run your plugins in R18 (or R19) it will lock up or crash since it will no longer be able to get to the data and will point somewhere randomly in memory.The end result for me
So now I have gone from only having to compile 1 version on OSX and 1 version on Windows to having to compile 3 versions on OSX and 3 versions on Windows.
So for me the forward compatibilty of Cinema 4D development is completely gone. From now on I am forced to build a separate version for each C4D version on each OS. But I am perfectly happy to do this, and should have done this from the beginning.So its finally time for me to setup a proper automated build process.
For everyone one else
If you decide to start using Reflection Layers you will need to at least build separately for R17 and R18, on both OS's.If you link to external libraries you will also need to build them separately for R19 due to the changes in VS 2015 (this is not C4D's fault).
If you don't use Reflection Layers and don't use any external libraries then versions compiled in R17 should work fine in R18, R19. At least the C4D SDK Examples work fine in all of my testing. But for me this is no longer an option so I will be compiling for every new version from here on out.
My Opinion
Even though its nice to have this forwards compatibility with future versions of C4D, I do believe compiling against the latest C4D SDK is always best. So I would recommend all developers to build fresh for each OS for each new version of C4D if you are using C++. I am perfectly happy to do this from now on. The added benefit is that I can now add in features for each specific version when C4D adds new features to the SDK. And in doing so it ensures that nothing has changed (or been removed) in the SDK that will break my plugins (ie ReflectionLayer SDK changes).The way around all of this is to just use Python. So if you don't need to access external libraries, don't require anything computationaly expensive, then Python is a much better solution.
Kent, I think the main point (also listed by MS) is this one:
"For example, statically linking the CRT into multiple DLLs can present the same problem. Developers encountering this problem with static CRTs have been instructed to compile with /MD to use the CRT DLL. If your DLLs pass CRT resources across the DLL boundary, you may encounter issues with mismatched CRTs and need to recompile your project with Visual C++.
If your program is using more than one version of the CRT, some care is needed when passing certain CRT objects (such as file handles, locales and environment variables) across DLL boundaries. For more information on the issues involved and how to resolve them, see Potential Errors Passing CRT Objects Across DLL Boundaries."- using the DLL version instead of the static linked libraries prevents some MS compatiblity issues and also avoids wasting the limited TLS keys a statically linked CRT libs needs (which in turn can limit the number of plugins you can load)
- when using different DLL versions of the MS CRT libs, you've still have to pay attention to passing objects across DLL boundaries (because that will fail due to incompatibility and potentially crash).Best regards,
Wilfried
-
On 06/09/2017 at 13:17, xxxxxxxx wrote:
Thanks Wilfried.
-
On 07/09/2017 at 12:48, xxxxxxxx wrote:
Originally posted by xxxxxxxx
Originally posted by xxxxxxxx
The R17 plugins that locked up R19 were my own plugins, hence the reason why I tried to find information, and then saw that R19 requires Visual Studio 2015.
Just thought I would let you know that I had to rebuild my plugins in VS 2015 for R19.
...
If you don't use any other 3rdparty libraries, and just stick with the C4D SDK itself, then your plugins should work fine if you compile with VS 2013 (ie R17, R18 builds).Just for the record:
I finally got to install VS 2015 and rebuild the plugin, although it was already confirmed that built with the R17 SDK should run without issues.
But since I experienced some lock ups I didn't want to take any chance.Now, the first thing I encountered when I started one of my plugins from within the debugger was a lock up of R19.
Pausing the execution from within Visual Studio indicated that the lock up was in drawport_opengl.module.xdl64
As I mentioned earlier, I had some sus**cion that the lock up was opengl / driver related. So, this clears things up. The plugins built with R17 SDK were working fine, but my display driver isn't.
Case closed. -
On 07/09/2017 at 13:03, xxxxxxxx wrote:
Originally posted by xxxxxxxx
Now, the first thing I encountered when I started one of my plugins from within the debugger was a lock up of R19.Pausing the execution from within Visual Studio indicated that the lock up was in drawport_opengl.module.xdl64As I mentioned earlier, I had some sus**cion that the lock up was opengl / driver related. So, this clears things up. The plugins built with R17 SDK were working fine, but my display driver isn't.Case closed.
Can you post the full callstack? Just wondering where it actually crashed, since the plugin would have been the start of your callstack.
Did you update your display driver and now everything is working ok?