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
    • Register
    • Login
    1. Home
    2. bojidar
    3. Topics
    B
    • Profile
    • Following 0
    • Followers 0
    • Topics 4
    • Posts 9
    • Best 1
    • Controversial 0
    • Groups 0

    Topics created by bojidar

    • B

      Merging files with PLUGINFLAG_SCENELOADER_MERGEORIGINAL

      Cinema 4D SDK
      • 2025 c++ • • bojidar
      3
      0
      Votes
      3
      Posts
      160
      Views

      ferdinandF

      Hey,

      so I talked with Fritz, I got the direction right, but there are some relevant details. When you set the flag for an importer hook, it signals that you do not want Cinema 4D to carry out the automatic scene color conversion along the conversion path implied in the settings.

      So, when you have a importer, and it does NOT set the flag, and you would import a scene with these settings:

      c3e3d6f8-2734-41d2-abfb-f7af807c12f8-image.png

      Cinema 4D would transform all scene colors from sRGB-2.1 to the Render Space. When you DO set the flag, Cinema 4D will NOT do that, and the importer is expected to handle that.

      So, when you need to set this flag, this implicitly means that something with your scene data is not correct, they are not meant to be sRGB. You can of course also change the respective setting, Raw for example means as always no conversion. Without a bit more details about your scene data and its provenance, it is hard to give here good advice.

      Cheers,
      Ferdinand

      PS: I might update the im/exporter examples at some point to showcase the custom case, but the default should be to NOT to set the flag, and let the intended color management of Cinema 4D do its work.

    • B

      React to Set Color Space from the Asset Inspector

      Cinema 4D SDK
      • c++ 2023 • • bojidar
      2
      0
      Votes
      2
      Posts
      308
      Views

      M

      Hi sadly it is not possible for the moment, I will talk to the responsible team to see if that's possible.

      Cheers,
      Maxime.

    • B

      Hide the illumination group in node materials

      Cinema 4D SDK
      • c++ • • bojidar
      2
      0
      Votes
      2
      Posts
      291
      Views

      ferdinandF

      Hey @bojidar,

      Thank you for reaching out to us.

      I assume you are talking about NodeMaterial cases, i.e., a material realized by the Nodes API.

      a78c9ce8-3a6c-4903-8428-625e0f8add14-image.png

      Something like a NodeMaterial does not actually exist under the hood. A NodeMaterial is just a modified Material (i.e., the type Mmaterial) where pretty much everything except for the Viewport (and previously Illumination) tab is being hidden. This is done by us overriding GetDDescription in Material. By default not the whole illumination tab is hidden, but only everything below the check box "Portal" (don't ask me why). I just had a look: And for Redshift we recently added a section in Material::GetDescription where we check for a material being part of the Redshift node space and then hide the full tab. Since third parties do not own/overwrite Material, their node material then looks different, without them being able to change that (here at the example of V-Ray):

      e03ce790-eb53-43dc-a604-ddfe5a7bace6-image.png

      For me it looks a bit like that we unintentionally left that group there. Maybe physical render node materials were/are still using that? But at least I do not see a reason why light portals and polygon lights must be standardized in this manner (we hide that group except for physical).

      I would recommend reaching out to us with a mail and the request to remove that "feature", i.e., make this more a program management than a programming thing. I cannot guarantee that we will do this, as there might be some special material management reasons why this has been done, but the starting point would be to have a PM discussion.

      Cheers,
      Ferdinand

    • B

      Cannot copy BaseLink from one parameter to another in ShaderData Read in C4D 2024

      Cinema 4D SDK
      • c++ 2024 • • bojidar
      14
      0
      Votes
      14
      Posts
      1.5k
      Views

      ferdinandF

      Hey @bojidar,

      So, I spent again some time on trying to debug this, and this time manually stepped through the deserialization of 1053286, i.e., your material type. And I am not really any wiser to what is going wrong there. This could be related to a change one of developers made for 2024 to GeAliasGoal, a precursor to what you see as a BaseLink in the public API.

      But when I look at how it steps through the chunks of the hyper file for your material, I do not really ever see that parameter being deserialized. I think this is more a Tech team than an SDK team issue as they own that part of our APIs. I would have to ask you to file a bug report via our bug tracker for this. Please make sure to include:

      Reproduction steps. The file.

      You can also include your code, but that is of less importance. Please give me then also a note when you have done this, so that I can attach the relevant people and make sure that they get access to a license of your software. I could also file the bug report for you, the problem would be then however, that you could not see it, as you can only see your own reports as an MRD. I.e., you could not take part in the comments/discussion attached to the issue. I would recommend that you submit it yourself. When you run into problems, ask Deyan, or reach out to us via mail.

      Cheers,
      Ferdinand