SDK Documentation
-
On 28/09/2014 at 16:11, xxxxxxxx wrote:
Zip your project, send it to me at [email protected]
give me enough context so that I can understand your issues. -
On 28/09/2014 at 17:02, xxxxxxxx wrote:
I'm talking about the one that comes with c4d: plugins/examples/cinema4dsdk
This used to be in the plugins folder in previous versions: plugins/cinema4dsdk-In the previous versions. When we built it by running the .sln file. The plugins show up in the plugins menu in C4D.
-In R16. Now that cinema4dsdk is inside of a parent folder called "examples". The plugins are now found in plugins->examples.
That's an extra dig into the menu system every single time you want to get at your plugin!The reason why this is bad (to me anyway) is because it's already a hassle to make plugins with C++. Because we have to close C4D down every time we change our code. And then re-launch C4D after we change and compile the C++ code.
Now with R16's new file structure and parent folder layout. We also have to do another mouse click to get at our plugins. Because Maxon put them in a sub menu called "examples".
They took an already bad workflow. And made it even worse by forcing us to dig into a sub menu every time we want to run a plugin.
That's why I want to get rid of that parent folder.Maybe I'm making a mountain out of a molehill. But to me this is a giant extra hassle in an already cumbersome workflow.
I open & close C4D literally hundreds of times while making C++ plugins.
And now I'll also have to add digging through the menus to that already painful workflow.
So if there's a way to get rid of that parent folder. I'd really like to know how to do that. So I can get the plugins to show up under the plugins menu again.-ScottA
-
On 29/09/2014 at 12:42, xxxxxxxx wrote:
Hey Scott,
Originally posted by xxxxxxxx
Now with R16's new file structure and parent folder layout. We also have to do another mouse click to get at our plugins. Because Maxon put them in a sub menu called "examples".
In the C4D gui, I always use "Window->Customization->Customize Commands" and find my plugin with the "name filter". Then put a check in "Edit Palates" and drag the icon for my plugin into the top row of C4D's shortcuts. This speeds things up even more than clicking the plugins menu and then finding your plugin.
If you are developing a GeDialog, you can customize the layout by docking your plugin's dialog and then use "Window->Customization->Save As Startup Layout". If you have your CommandData class configured properly(virtual Bool RestoreLayout(void* secret)), your Dialog will be open in the layout C4D starts with. You can always revert back to the original startup layout using the "Layout:" pulldown menu in the top right corner of C4D gui and select "Standard", then "Window->Customization->Save As Startup Layout" to make this the next layout that C4D starts up with. Any layout can be saved and then be made the startup layout.
Also, if your plugin is working with some scene object and you don't want to create or open it it every time you start C4D, get your scene set up the way you want it before you run your plugin, then save the scene as "new.c4d" in the root of the user preferences folder for the version of C4D you are working with. Now C4D will start with the scene loaded saving even more clicks.
Originally posted by xxxxxxxx
So if there's a way to get rid of that parent folder. I'd really like to know how to do that. So I can get the plugins to show up under the plugins menu again.
When you are done developing your plugin, I believe(do not know for a fact) you can simply move everything needed for production up one directory and the plugins menu will behave as before. I tried it with the SDK and the plugins I executed worked fine. This may not work if the plugin needs to load items outside the the res folder at C4D startup. This has not been thoroughly tested, so Forum please let me know if this information is incorrect and I will edit this post.
Joe Buck
-
On 29/09/2014 at 14:46, xxxxxxxx wrote:
Hey Scott,
If you move your cinema4sdk back down to the plugins folder, or clone it as suggested, then to get it running do the following.
- Edit the MAXON_ROOTDIR inside of projectsettings.props.
Currently it is
<MAXON_ROOTDIR>..\..\..</MAXON_ROOTDIR>
Change it to this
<MAXON_ROOTDIR>..\..</MAXON_ROOTDIR>
- Open up the solution.
You will now notice that the cinema4dsdk loads but the cinema.framework doesn't. So lets just add it again.
Remove the cinema.framework from the solution in VS.
Right click on the solution and choose Add->Existing Project
Go to the folder
16\frameworks\cinema.framework\project
And add the project file cinema.framework.vcxproj.
- Right click on the Solution again and choose Project Dependencies.
Make sure cinema4dsdk is shown in the "Projects" drop down. Then check the "cinema.framework" in the "Depends on" box below.
- Lastly you need to add a reference to the framework.
Right click on the cinema4dsdk project and choose Add->References.
Next click the "Add New Reference" at the bottom of the dialog that appears.
Check the box for cinema.framework and press ok. Then ok again on the other dilaog.
- Compile!
Build your solution and you should now be all good to go.
Kent
-
On 29/09/2014 at 15:02, xxxxxxxx wrote:
Nice! Do you know how to do this for the Xcode project?
Thank you,
Joe Buck
-
On 29/09/2014 at 15:08, xxxxxxxx wrote:
Originally posted by xxxxxxxx
@kbar
Nice! Do you know how to do this for the Xcode project?
Thank you,
Joe BuckNo sorry. I am not on my mac at the moment to have a look.
-
On 29/09/2014 at 15:58, xxxxxxxx wrote:
Hi Joe,
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.
I often grab multiple plugins and paste them into the plugins folder to work on them. Then quickly work on them. Then save them back to my storage drive.
This lets me quickly work on multiple plugins a little bit at a time.
Having to set up shortcuts for them just to work on them would be a huge hassle.I need to be able to compile the cinema4dsdk without that stupid parent folder in there.
It's messing up my clean and efficient workflow.-ScottA
-
On 29/09/2014 at 16:31, xxxxxxxx wrote:
Hey Scott,
Originally posted by xxxxxxxx
I need to be able to compile the cinema4dsdk without that stupid parent folder in there.It's messing up my clean and efficient workflow.
Did you try my solution?
Kent
-
On 29/09/2014 at 17:47, xxxxxxxx wrote:
No. Somehow I missed your post Kent.
It works great. Thanks.
-ScottA
-
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
-
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
-
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
-
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?
-
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?
-
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.libSo 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.
-
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.libSo 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.
-
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 6EBut 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 -
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.
-
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. -
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.