Plugin Cafe Homepage
Forum Home Forum Home > Plugin Cafe > SDK Help
  New Posts New Posts
  FAQ FAQ  Forum Search   Register Register  Login Login

Cinema 4D R19 C++ SDK Documentation

 Post Reply Post Reply
Author
Message
Andreas Block View Drop Down
Forum Moderator
Forum Moderator
Avatar

Joined: 2014 Oct 01
Location: Hannover
Online Status: Offline
Posts: 1482
Post Options Post Options   Quote Andreas Block Quote  Post ReplyReply Direct Link To This Post Topic: Cinema 4D R19 C++ SDK Documentation
    Posted: 2017 Sep 01 at 4:57am

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.
The R19 online documentation replaces the R18 documentation, but the R18 documentation is still available on the downloads page (as ususal).

Any comments or feedback will be appreciated.

Best regards,
your SDK Team

Cheers,
Andreas
SDK Support Engineer
Back to Top
C4DS View Drop Down
Member
Member


Joined: 2015 Dec 01
Online Status: Offline
Posts: 103
Post Options Post Options   Quote C4DS Quote  Post ReplyReply Direct Link To This Post Posted: 2017 Sep 01 at 5:12am
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 R18

EDIT2:
Quickly browsed through the API changes.
Is this a typo in the documentation, or has it been defined like this?
#define BITMAPBOOL_TOGGLEACTIVAION

Edited by C4DS - 2017 Sep 01 at 5:20am
Back to Top
Andreas Block View Drop Down
Forum Moderator
Forum Moderator
Avatar

Joined: 2014 Oct 01
Location: Hannover
Online Status: Offline
Posts: 1482
Post Options Post Options   Quote Andreas Block Quote  Post ReplyReply Direct Link To This Post Posted: 2017 Sep 01 at 5:15am
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.

Cheers,
Andreas
SDK Support Engineer
Back to Top
C4DS View Drop Down
Member
Member


Joined: 2015 Dec 01
Online Status: Offline
Posts: 103
Post Options Post Options   Quote C4DS Quote  Post ReplyReply Direct Link To This Post Posted: 2017 Sep 01 at 5:21am
You're right, browser reload required. Sorry.
Back to Top
Andreas Block View Drop Down
Forum Moderator
Forum Moderator
Avatar

Joined: 2014 Oct 01
Location: Hannover
Online Status: Offline
Posts: 1482
Post Options Post Options   Quote Andreas Block Quote  Post ReplyReply Direct Link To This Post Posted: 2017 Sep 01 at 6:20am
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.



Edited by Andreas Block - 2017 Sep 01 at 6:20am
Cheers,
Andreas
SDK Support Engineer
Back to Top
C4DS View Drop Down
Member
Member


Joined: 2015 Dec 01
Online Status: Offline
Posts: 103
Post Options Post Options   Quote C4DS Quote  Post ReplyReply Direct Link To This Post Posted: 2017 Sep 01 at 7:02am
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.




Edited by C4DS - 2017 Sep 01 at 7:40am
Back to Top
kbar View Drop Down
Member
Member
Avatar

Joined: 2009 Feb 12
Location: New Zealand
Online Status: Offline
Posts: 64
Post Options Post Options   Quote kbar Quote  Post ReplyReply Direct Link To This Post Posted: 2017 Sep 01 at 3:36pm
Originally posted by C4DS


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.
Back to Top
gr4ph0s View Drop Down
Member
Member


Joined: 2015 Jul 07
Location: France
Online Status: Offline
Posts: 320
Post Options Post Options   Quote gr4ph0s Quote  Post ReplyReply Direct Link To This Post Posted: 2017 Sep 01 at 7:21pm
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 !


Edited by gr4ph0s - 2017 Sep 01 at 7:22pm
Technical lover.
Back to Top
kbar View Drop Down
Member
Member
Avatar

Joined: 2009 Feb 12
Location: New Zealand
Online Status: Offline
Posts: 64
Post Options Post Options   Quote kbar Quote  Post ReplyReply Direct Link To This Post Posted: 2017 Sep 03 at 12:55am
Originally posted by C4DS


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).

Edited by kbar - 2017 Sep 03 at 1:00am
Back to Top
S_Bach View Drop Down
Forum Moderator
Forum Moderator
Avatar

Joined: 2011 Jun 27
Online Status: Offline
Posts: 1302
Post Options Post Options   Quote S_Bach Quote  Post ReplyReply Direct Link To This Post Posted: 2017 Sep 04 at 1:53am
Hello,

the "iferr" macro is only an internal compatibility macro that has no use for third party developers.

best wishes,
Sebastian
SDK Support Engineer
Back to Top
Andreas Block View Drop Down
Forum Moderator
Forum Moderator
Avatar

Joined: 2014 Oct 01
Location: Hannover
Online Status: Offline
Posts: 1482
Post Options Post Options   Quote Andreas Block Quote  Post ReplyReply Direct Link To This Post Posted: 2017 Sep 05 at 7:23am
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.


Edited by Andreas Block - 2017 Sep 05 at 7:24am
Cheers,
Andreas
SDK Support Engineer
Back to Top
kbar View Drop Down
Member
Member
Avatar

Joined: 2009 Feb 12
Location: New Zealand
Online Status: Offline
Posts: 64
Post Options Post Options   Quote kbar Quote  Post ReplyReply Direct Link To This Post Posted: 2017 Sep 05 at 1:50pm
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.


Edited by kbar - 2017 Sep 05 at 2:28pm
Back to Top
wbeh View Drop Down
Member
Member


Joined: 2009 Sep 12
Location: Germany
Online Status: Offline
Posts: 244
Post Options Post Options   Quote wbeh Quote  Post ReplyReply Direct Link To This Post Posted: 2017 Sep 06 at 1:57am
Originally posted by kbar

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


Edited by wbeh - 2017 Sep 06 at 1:58am
Back to Top
kbar View Drop Down
Member
Member
Avatar

Joined: 2009 Feb 12
Location: New Zealand
Online Status: Offline
Posts: 64
Post Options Post Options   Quote kbar Quote  Post ReplyReply Direct Link To This Post Posted: 2017 Sep 06 at 1:17pm
Thanks Wilfried.
Back to Top
C4DS View Drop Down
Member
Member


Joined: 2015 Dec 01
Online Status: Offline
Posts: 103
Post Options Post Options   Quote C4DS Quote  Post ReplyReply Direct Link To This Post Posted: 2017 Sep 07 at 12:48pm
Originally posted by kbar

Originally posted by C4DS


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.
Back to Top
kbar View Drop Down
Member
Member
Avatar

Joined: 2009 Feb 12
Location: New Zealand
Online Status: Offline
Posts: 64
Post Options Post Options   Quote kbar Quote  Post ReplyReply Direct Link To This Post Posted: 2017 Sep 07 at 1:03pm
Originally posted by C4DS


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?

Edited by kbar - 2017 Sep 07 at 1:05pm
Back to Top
 Post Reply Post Reply

Forum Jump Forum Permissions View Drop Down

Bulletin Board Software by Web Wiz Forums® version 9.61 [Free Express Edition]
Copyright ©2001-2009 Web Wiz

This page was generated in 0.109 seconds.