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
    1. Maxon Developers Forum
    2. shir
    3. Topics
    S
    • Profile
    • Following 0
    • Followers 0
    • Topics 3
    • Posts 11
    • Best 0
    • Controversial 0
    • Groups 0

    Topics created by shir

    • S

      Cinema4D SDK C++ Implementation of a Plugin Module on Windows Issues

      Cinema 4D SDK
      • windows c++ 2025 • • shir
      2
      0
      Votes
      2
      Posts
      204
      Views

      ferdinandF

      Hey @shir,

      Thank you for reaching out to us. A Program Database (PDB) is a debug information format from Microsoft. It is comparable to the DWARF debug information format often used under Linux and macOS. However, unlike DWARF under Linux, where debug information is directly compiled into the binary, Microsoft chooses to store debug information in separate files, the pdb files.

      When you attach a debugger to a binary without any debug information, it will by default only see the machine code of the binary. So when you have an issue and the debugger puts out a stack trace, it will only show you the offsets in a library, e.g., something like this:

      #1 0x0000000000767576 in myBinary.dll #2 0x0000000000767df4 in otherBinary.dll #3 0x0000000000773aca in myBinary.dll #4 0x00000000004b893e in myBinary.dll

      You can see this happen in the call stack window in your screenshot. VS only provides information in the format someBinary.ext!someAddress(), e.g., c4d_base.xdl64!00007ffb200acfb7(), as it has no further information. With bin!address() VS means a function at that address is being called. In my opinion, VS has one of the most cryptic stack trace formats out there and can be a bit confusing for beginners.

      To see meaningful output, you need the debug information for that binary, which among other things contains the mapping of addresses to source code. If you have the pdb file for the binary, you can load it into your debugger, and it will then show you something like this instead:

      #1 0x0000000000767576 in MyClass::MyMethod() at myClass.cpp:42 #2 0x0000000000767df4 in OtherClass::OtherMethod() at otherClass.cpp:15 #3 0x0000000000773aca in MyClass::AnotherMethod() at myClass.cpp:78 #4 0x00000000004b893e in main() at main.cpp:10

      When you compile the Cinema 4D SDK and your source code, it will automatically generate the pdb files for these binaries for you, so that you can debug them in a meaningful manner. But what we see here is Visual Studio asking you for the pdb for c4d_base.xdl64, one of the core library binaries located in the corelibs folder of the Cinema 4D application you are debugging with. You did not compile that binary, so you do not have the pdb file for it. And we do not ship our binaries with debug information, as that would not only be a very large download, but also would expose our source code to the public.

      You are hitting a debug stop there (VS tells you that in the info box by stating this is a __debugbreak). This is the less critical case of a debug event, which is covered by the very tutorial you are following (the other one being a critical stop). You can simply hit continue in your debugger and ignore this. The event seems to be raised from Redshift, judging by the stack trace we can see in the screenshot you provided. There is probably some minor hardware issue or so, and Redshift is trying to handle it gracefully by raising this debug event.

      It is, however, not normal when this happens permanently and usually it hints at a corrupted installation of Cinema 4D or a hardware issue when you are always greeted by debug events on startup (or even when just running and interacting with Cinema 4D). Sometimes debug stops can happen as a one-time thing when you are debugging for the first time against some Cinema 4D instance (and it has not yet built all its prefs, caches, and other things Cinema 4D builds in the background). When this persists and you are annoyed by having to press continue, I would recommend trying to either remove Redshift from your Cinema 4D installation or reinstall Cinema 4D altogether.

      You could also check inside of Cinema 4D if you can see any errors in the 'Redshift Feedback Display' window. For you as a third party, it is however not possible to find out what that issue in c4d_base.xdl64 at the offset 7ffb200acfb7 is.

      Cheers,
      Ferdinand

      PS: There is also g_enableDebugBreak=true|false which you can pass to your Cinema 4D instance as a commandline argument. With that you can permanently mute debug stops. But that is more of an expert feature and you probably do not want to enable that as a beginner.

    • S

      How do I create a Plugin Identifier?

      Cinema 4D SDK
      • windows python 2024 • • shir
      14
      0
      Votes
      14
      Posts
      1.1k
      Views

      ferdinandF

      Hey @shir,

      good to hear that you solved the issue. Maybe NodeBB has an issue with the specific (top level) domain your mail handle was under? I just checked the logs and this is the event for the second registration mail that has been sent out (I edited your mail handle for privacy reasons). I.e., this is the one I manually invoked. There is another event for your actual registration. As far as NodeBB is concerned, it seems to be convinced that it successfully sent these mails.

      { "confirm_code": "dbcc0d6c-8646-4191-9975-badc1c7035f2", "email": "[email protected]", "subject": "Welcome to PluginCafé", "template": "welcome", "timestamp": 1751883962965 }

      NodeBB can be a bit buggy from time to time but that it fails to send a mail and then creates an event for successfully sending it, would be a bit odd. I will have an eye on this.

      Cheers,
      Ferdinand

    • S

      How to convert an Xpresso Object Rig into a downloadable Plugin?

      General Talk
      • • • shir
      6
      0
      Votes
      6
      Posts
      2.1k
      Views

      r_giganteR

      Hi Shir, thanks for following up and providing your additional info.

      Showing parameter in the Attribute Manager or a custom icon in the Object Manager is not such a big issue: you can start looking at Py-RoundedTube which is an ObjectData derived plugin where all such a stuff (and more) is shown.
      That said, the real question is instead to understand what your rig is actually doing and see if it's reasonable to implement the Xpresso functionality from a set of "primitive" functions you implement in your plugin or if would be instead easier to programmatically recreate the Xpresso rig in an XpressoTag then attached to the object generated by your plugin.

      Actually this assessment can't be done from here where the final functionality and the complexity of your Xpresso network is unknown.

      So far I do see three approches:

      start on your own, step-by-step, dissect the code from the example I mentioned above and try to move your steps alone outsource the task to some paid developer
      or call for volunteers in our very helpful PluginCafe community.

      I'm sorry not be more helpful but, as said in the first post, we can't deliver turn-key plugins or scripts but rather help our customer to learn from our resources.

      Best, Riccardo