Maxon Developers Maxon Developers
    • Documentation
      • Cinema 4D Python API
      • Cinema 4D C++ API
      • Cineware API
      • ZBrush GoZ API
      • Code Examples on Github
    • Forum
    • Downloads
    • Support
      • Support Procedures
      • Registered Developer Program
      • Plugin IDs
      • Contact Us
    • Categories
      • Overview
      • News & Information
      • Cinema 4D SDK Support
      • Cineware SDK Support
      • ZBrush 4D SDK Support
      • Bugs
      • General Talk
    • Unread
    • Recent
    • Tags
    • Users
    • Login

    SDK Documentation

    SDK Help
    0
    36
    18.2k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • H
      Helper
      last edited by

      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

      1 Reply Last reply Reply Quote 0
      • H
        Helper
        last edited by

        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

        1 Reply Last reply Reply Quote 0
        • H
          Helper
          last edited by

          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?

          1 Reply Last reply Reply Quote 0
          • H
            Helper
            last edited by

            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?

            1 Reply Last reply Reply Quote 0
            • H
              Helper
              last edited by

              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.

              1 Reply Last reply Reply Quote 0
              • H
                Helper
                last edited by

                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.

                1 Reply Last reply Reply Quote 0
                • H
                  Helper
                  last edited by

                  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

                  1 Reply Last reply Reply Quote 0
                  • H
                    Helper
                    last edited by

                    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.

                    1 Reply Last reply Reply Quote 0
                    • H
                      Helper
                      last edited by

                      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.

                      1 Reply Last reply Reply Quote 0
                      • H
                        Helper
                        last edited by

                        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.

                        1 Reply Last reply Reply Quote 0
                        • H
                          Helper
                          last edited by

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

                          1 Reply Last reply Reply Quote 0
                          • H
                            Helper
                            last edited by

                            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

                            1 Reply Last reply Reply Quote 0
                            • First post
                              Last post