SDK Documentation

Helper

On 29/09/2014 at 17:53, xxxxxxxx wrote:

@Scott,

Originally posted by xxxxxxxx

Yeah. I know I can do those kinds of things. But that requires setting them up every time I want to work on a plugin.

Your response is not correct. Since I spent the time to respond to a question, I would like to make sure my post can be useful to others who are not so quickly dismissive.

My solution to your dilemma DOES NOT require that you set it up every time you work on a plugin or plugin group. It requires that you set it up ONCE when you start a new plugin project. Once a layout has been saved, plugin shortcuts simply do not show up in the palette when the plugin is not present in the plugins folder. Shortcuts re-appear in palettes when the plugins are put back in the plugins folder.

Originally posted by xxxxxxxx

We also have to do another mouse click to get at our plugins.

If you are actually into counting clicks, my solution will save your described workflow many.

Cinema 4D has one of the best GUIs in the business. Explore it and you will find solutions to many click causing dilemmas. Throw in some Python and you are home with a beer in you hand by 5:30 every day

Best of Luck,

Joe Buck

Helper

On 29/09/2014 at 18:10, xxxxxxxx wrote:

Sorry about that Joe. I didn't mean to come off as dismissive.
Sorry if I came off as rude.
It just wasn't the solution I wanted.

-ScottA

Helper

On 29/09/2014 at 19:18, xxxxxxxx wrote:

@Scott
No worries. You just sound frustrated to me. I would also like you to know that many of the questions you have asked on this forum have generated answers that really helped me understand parts of the SDK.

So thanks,

Joe Buck

Helper

On 01/10/2014 at 17:02, xxxxxxxx wrote:

Can someone please tell me the differences between the Debug/Release/Intel and the LibDebug/LibRelease/LibIntel configurations in the VisualStudio project for the cinema framework?

Helper

On 01/10/2014 at 19:31, xxxxxxxx wrote:

Originally posted by xxxxxxxx

Can someone please tell me the differences between the Debug/Release/Intel and the LibDebug/LibRelease/LibIntel configurations in the VisualStudio project for the cinema framework?

The framework is build in the Cinema 4D project build and requires these configurations.
The intel compiler is used to produce the final build of C4D. There is no debug build under Intel.
Which one we use depends of our needs...

for DLL builds - dynamic library

Debug - visual studio debug build (DLL)
Release - visual studio release build (DLL)
Intel - Intel compiler release build (DLL)

Library builds - static library, included in a project (which may be a DLL itself, or an executable)

LibDebug - visual studio debug build (library)
LibRelease - visual studio release build (library)
LibIntel - visual studio release build (library)

Can I ask why you you are asking?

Helper

On 02/10/2014 at 06:59, xxxxxxxx wrote:

Originally posted by xxxxxxxx

Originally posted by xxxxxxxx

Can someone please tell me the differences between the Debug/Release/Intel and the LibDebug/LibRelease/LibIntel configurations in the VisualStudio project for the cinema framework?

The framework is build in the Cinema 4D project build and requires these configurations.
The intel compiler is used to produce the final build of C4D. There is no debug build under Intel.
Which one we use depends of our needs...

Yeah, what "Debug", "Release" and "Intel" is for, was clear so far of course. !Wink[URL-REMOVED]
My question was just related to the "Lib..." part in the configs.
The difference of the respective configs with the "Lib" and without the "Lib" in the name.

According to your explanation that would mean the one group is for creating dynamic and the other one for creating static libraries.

Thank you for answering that so far.

Originally posted by xxxxxxxx

Can I ask why you you are asking?

I asked because I was unsure which config to choose for compiling my plugins.

I precompiled all the x64 versions of the c4d api (cinema.framework) for the VS compiler, so that I could link them directly to my plugins without the need to rebuild the framework again and again everytime I compile or recompile some of my own code.

And all produced (I guess) static libraries:

x64_Debug: cinema.framework_Debug_64bit.lib
x64_Release: cinema.framework_Release_64bit.lib
x64_LibDebug: cinema.framework_LibDebug_64bit.lib
x64_LibRelease: cinema.framework_LibRelease_64bit.lib

So I was (and in fact still am) unsure which one to use.

I guess it would have to be the "Lib..."-variations for the cinema.framework (x64_LibRelease & x64_LibDebug) and the other ones (x64_Release & x64_Debug) for the plugins itself as they have to be dynamic. (I mean, *.cdl and *.cdl64 are in fact simple *.dll's, only renamed)

But it seems like "cinema.framework_Release_64bit.lib" (and "cinema.framework_Debug_64bit.lib") would also work instead. And in fact they would have been even my first choice so far.
That's what my confusion comes from.

On the other hand it couldn't be that these cinema.framework libraries are really statically linked into the plugin DLL's, regarding to the final size of them and it also wouldn't make any sense to include the api itself in the plugin code as it just provide the hooks to the main application (C4D itself) as far as I understand the background of that all. I'm still confused.

By the way, some other questions apart from that:

1. Why are there still predefined configs for Win32 in the project even though they have to be useless since C4D is x64 only up from R15?
Not that it really annoys me, I'm just wondering.

2. Why are the release versions of the framework so much bigger than the debug versions?
Around 300 MB (!!!) for the release libs vs. about 12 MB for the debug libs.
I would have expected the release libs to be slightly smaller than the debug versions.

Kind regards,
Tom

[URL-REMOVED] @maxon: This section contained a non-resolving link which has been removed.

Helper

On 02/10/2014 at 08:12, xxxxxxxx wrote:

If you look in the cinema4dsdk sln, you will find a proper setup example.
the cinema4dsdk project constitutes the plugin body while the cinema.framework project constitutes a dependency (its API).

Editing the properties, you will find out that the cinema.framework (the api) is built as a library while the cinema4dsdk (the plugin) is built as a DLL.

The resulting plugin contains its own API and can, therefore, be used on future versions of C4D, provided only addition are made to the API (that's what we do). I believe the libs are not included in the resulting CDL file. they link with cinema 4D instead.

Some more insights are found here - its about R15 and wasn't updated with R16, but it shows the same library/dll configuration.
http://c4dprogramming.wordpress.com/2012/09/30/creating-a-new-plugin-project-in-visual-studio/

Let me know if this helps.

Originally posted by xxxxxxxx

Originally posted by xxxxxxxx

Originally posted by xxxxxxxx

Can someone please tell me the differences between the Debug/Release/Intel and the LibDebug/LibRelease/LibIntel configurations in the VisualStudio project for the cinema framework?

The framework is build in the Cinema 4D project build and requires these configurations.
The intel compiler is used to produce the final build of C4D. There is no debug build under Intel.
Which one we use depends of our needs...

Yeah, what "Debug", "Release" and "Intel" is for, was clear so far of course. !Wink[URL-REMOVED]
My question was just related to the "Lib..." part in the configs.
The difference of the respective configs with the "Lib" and without the "Lib" in the name.

According to your explanation that would mean the one group is for creating dynamic and the other one for creating static libraries.

Thank you for answering that so far.

Originally posted by xxxxxxxx

Can I ask why you you are asking?

I asked because I was unsure which config to choose for compiling my plugins.

I precompiled all the x64 versions of the c4d api (cinema.framework) for the VS compiler, so that I could link them directly to my plugins without the need to rebuild the framework again and again everytime I compile or recompile some of my own code.

And all produced (I guess) static libraries:

x64_Debug: cinema.framework_Debug_64bit.lib
x64_Release: cinema.framework_Release_64bit.lib
x64_LibDebug: cinema.framework_LibDebug_64bit.lib
x64_LibRelease: cinema.framework_LibRelease_64bit.lib

So I was (and in fact still am) unsure which one to use.

I guess it would have to be the "Lib..."-variations for the cinema.framework (x64_LibRelease & x64_LibDebug) and the other ones (x64_Release & x64_LibDebug) for the plugins itself as they have to be dynamic. (I mean, *.cdl and *.cdl64 are in fact simple *.dll's, only renamed)

But it seems like "cinema.framework_Release_64bit.lib" (and "cinema.framework_Debug_64bit.lib") would also work instead. And in fact they would have been even my first choice so far.
That's what my confusion comes from.

On the other hand it couldn't be that these cinema.framework libraries are really statically linked into the plugin DLL's, regarding to the final size of them and it also wouldn't make any sense to include the api itself in the plugin code as it just provide the hooks to the main application (C4D itself) as far as I understand the background of that all. I'm still confused.

By the way, some other questions apart from that:

1. Why are there still predefined configs for Win32 in the project even though they have to be useless since C4D is x64 only up from R15?
Not that it really annoys me, I'm just wondering.

[/QUOTE]
That`s something we forgot when we removed the Win32 target in R16.

Originally posted by xxxxxxxx

2. Why are the release versions of the framework so much bigger than the debug versions?
Around 300 MB (!!!) for the release libs vs. about 12 MB for the debug libs.
I would have expected the release libs to be slightly smaller than the debug versions.

I don`t know. definitely looks weird to me.

Originally posted by xxxxxxxx

Kind regards,
Tom

[URL-REMOVED] @maxon: This section contained a non-resolving link which has been removed.

Helper

On 02/10/2014 at 08:46, xxxxxxxx wrote:

Originally posted by xxxxxxxx

If you look in the cinema4dsdk sln, you will find a proper setup example.
the cinema4dsdk project constitutes the plugin body while the cinema.framework project constitutes a dependency (its API).

Editing the properties, you will find out that the cinema.framework (the api) is built as a library while the cinema4dsdk (the plugin) is built as a DLL.

The resulting plugin contains its own API and can, therefore, be used on future versions of C4D, provided only addition are made to the API (that's what we do).

Some more insights are found here - its about R15 and wasn't updated with R16, but it shows the same library/dll configuration.
http://c4dprogramming.wordpress.com/2012/09/30/creating-a-new-plugin-project-in-visual-studio/

Let me know if this helps.

Don't get me wrong, I did several C++ plugins for C4D before from R9.6 up to R15 with the Express Editions of VS 2005, VS 2008, VS 2010 and now VS 2013.

My goal is to completely remove the cinema.framework project from the solution for my plugin and instead use e.g. the precompiled "cinema.framework_Release_64bit.lib" as an additional dependency. How I did it from R10 up to R15 with the "_api_x64_Release.lib" regarding to this example.

But, to bring the core of my problem down to the point:
To compile the cinema4dsdk from R16 as "final", should I choose the "Release" or the "LibRelease" config (the platform is always x64 now of course)?

I tried both and both work. They resulting "cinema4dsdk.cdl64" even has the same sice in both cases (722.944 Bytes) but there are 24 differences in the binaries.

  
  110:    8F    DE  
  111:    70    6E  
89BF4:    8F    DE  
89BF5:    70    6E  
89C10:    8F    DE  
89C11:    70    6E  
98904:    E1    9C  
98905:    DD    D1  
98906:    78    3C  
98907:    AC    EF  
98908:    07    3D  
98909:    1F    47  
9890A:    95    D2  
9890B:    4D    46  
9890C:    96    97  
9890D:    9A    B6  
9890E:    B8    FF  
9890F:    AF    AE  
98910:    11    E9  
98911:    23    F0  
98912:    AB    C8  
98913:    22    B1  
A5D84:    8A    DA  
A5D85:    70    6E

But don't know what that means in detail and if it would have any impact in practice too?

I would tend toward "Release" not to "LibRelease", but that's just a feeling...

And what's about my other two questions?

Kind regards,
Tom

Helper

On 02/10/2014 at 08:57, xxxxxxxx wrote:

I use "release and x64" personnally. I'll see if I can gain more insight on that.

On the other questions - I modified my message right after sending, the win32 target shouldn't be there. it's a mistake. for the lib size, I don't know and need to look that up.

Helper

On 02/10/2014 at 12:51, xxxxxxxx wrote:

Originally posted by xxxxxxxx

I use "release and x64" personnally. I'll see if I can gain more insight on that.

On the other questions - I modified my message right after sending, the win32 target shouldn't be there. it's a mistake. for the lib size, I don't know and need to look that up.

Okay, thank you so far.
And I'm looking forward to what you'll find out about the lib size.

Helper

On 07/10/2014 at 08:09, xxxxxxxx wrote:

Phoenix,

I just talked to one of our developers about the framework library size. The development is aware of this, but as this has no influence on the size of plugins linked against the release version of the framework lib, the priority is rather low. It's also not that straight forward, it seems to be correlated to the optimizations the compiler is applying (current thinking goes into the direction of some duplication of code). Please be patient, we are looking into this, and I have noted this on my ToDo list.

Helper

On 07/10/2014 at 16:04, xxxxxxxx wrote:

Originally posted by xxxxxxxx

I just talked to one of our developers about the framework library size.

Thank you again for talking to the developers and informing us.

Originally posted by xxxxxxxx

The development is aware of this, but as this has no influence on the size of plugins linked against the release version of the framework lib, the priority is rather low.

Yup, that also corresponds with my observations/experiences so far.

Originally posted by xxxxxxxx

It's also not that straight forward, it seems to be correlated to the optimizations the compiler is applying (current thinking goes into the direction of some duplication of code). Please be patient, we are looking into this, and I have noted this on my ToDo list.

Okay, good to know.
Because nevertheless it should be fixed sooner or later, in my opinion.

Helper

On 19/10/2014 at 01:47, xxxxxxxx wrote:

Hi

@joe
to your question on the first page.
I tried to move the sdk and make it ready with xcode 5.1.1, too.
That might be a solution :

hhttps://developers.maxon.net/forum/topic/8228/10726_moving-xcode-project-compile-error-xcode-solved

Please let me know if this works for you or if it´s even a acceptable way.

Best wishes
Martin