Topics created by bojidar

Hey @bojidar,

I would suggest that you write a mail about this, so that I can forward it. All I can tell you is that for variadic ports all bets are off. I really ran into this issue when I had to handle variadic ports for graph descriptions.

When you instantiate a node with variadic ports, it usually has some default children. I have never tried what happens when you try to remove all ports (graph description can do this, but they then do not test if the system does not regenerate them). There is also no guarantee that the 1st variadic port has the ID _0. It is just a convention, which is for example directly borken by the Standard Renderer Material node, as it gives its first BSDF layer port the ID 1, and the 2nd manually created layer then the ID _0 (because of course it does):

76bb0bfe-ff1f-4530-a55c-059bc195e46b-image.png
1aa63fb8-e9dc-4e83-80b6-7ffa782752af-image.png

You really have to write a mail here, because this is so deep in the Nodes API internals, it requires a true specialist to answer it.

Cheers,
Ferdinand

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.

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

Cheers,
Maxime.

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

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