Thanks, @ferdinand

1. I think it's easier to reproduce this problem with C4D 2024 (say 2024.5.1).
2. I don't think this is a bug with C4D. It's a problem with our plugin about how to use C4D MODATA_COLOR from the effector field for Multi Shader in our Render Engine. The viewport always has the expected correct result, it's our plugin who doesn't produce the expected result.

With more and more thinking and testing, I began to believe that in the scene attached the MODATA_COLOR from the effector field is used to find which texture defined in the Multi Shader should be applied to each cloned instance. (so the MODATA_COLOR values are more like texture indexes). So the MODATA_COLOR values are not really used as colors in the viewport, and shouldn't be treated as gamma-corrected values regardless of the scene's color space.

If my above understanding is correct, I think our plugin just need to treat the MODATA_COLOR values in this particular case the same way as C4D viewport. Currently, our plugin convert the MODATA_COLOR values from linear to srgb based on the scene's color space, which I think is incorrect, because I think the MODATA_COLOR values are not real colors in this case.

Thank you very much, @ferdinand
Yeah, in the video you attached, it looks to me that Linear workflow doesn't affect the final render result.

I have got the approval to attach this simple test scene that demonstrates the problem I'm experiencing. The setting is a bit different with your scene.

The scene attached uses Multi Shader. My understanding is that the MODATA_COLOR from the effector field is used to find which texture defined in the Multi Shader should be applied to each cloned instance. (so the MODATA_COLOR values are more like texture indexes). So the MODATA_COLOR values are not really used as colors in the viewport, and shouldn't be treated as gamma-corrected values regardless of the scene's color space.
Please let me know if my understanding is correct. Thanks again!

Hi @ferdinand, thanks for all you help.
I think a cloner's MODATA_COLOR should be interpreted if the cloner uses Multi Shader. Is my understanding correct?

Thank you very much, @ferdinand

I think I start understanding it now.

The MODATA_COLOR values existing in the scene won't get changed by the scene's color space settings, instead, they could be interpreted differently when scene's color space setting changes.

In the scene I'm testing, the MODATA_COLOR comes from a Linear Field (doesn't necessarily be Linear Filed, it could be other Filed types, like Box Filed, Capsule Filed) of Plain effector's Fields setting. The MODATA_COLOR values are not real colors, they are used to find the texture for each instance from a Multi Shader's setting.
So I think in this case, it could be safely assume the data is linear values?
If this is true, is there is a way to find if a MODATA_COLOR from a Field? So I can make sure MODATA_COLOR from Field are treated as linear values.

Thanks!

Hi @ferdinand. Thank you very much for the detailed explanation.

Let me try to answer your questions first.

What is that 'customized texture object' concretely? I assume the texture node in the material/shader system of your render engine?

yes, that's true.

What leads you to the assumption that your colors are wrong?
How are you writing the data into the texture, and how is your render engine interpreting its input space?

The colors are used as input texture for a gradient map node in our render engine. So the color is not directly used for a object's color.
The final rendered image from our render engine should match C4D viewport, so that's how I tell if the result is correct.

In R2024, I always found "The Application uses Linear Space for Calculations."

Sorry, as you said this is not true. If I untick "Linear Workflow" checkbox, I will actuall see "The Application uses sRGB Space for Calculations."

I thought MODATA_COLOR is in computational color space which is controlled by the settings in Scene Settings -> Project -> COLOR MANAGEMENT, that's why I thought I can get the MODATA_COLOR's color space by an API.
However, the colors values I got from MODATA_COLOR remain the same no matter if "Linear Workflow" checkbox is ticked or not.
So this means my thought was wrong, otherwise the values of MODATA_COLOR will change if I ticke/untick the "Linear Workflow" checkbox.

Does this mean that MODATA_COLOR's value won't be affected by any scene level color space settings?

It seems the color I got from MODATA_COLOR is always linear no matter if "Linear Workflow" checkbox is ticked.
No matter if "Linear Workflow" checkbox is ticked I can get the expected result in below two ways:

• If I set the image buffer of our render engine's texture node directly use the MODATA_COLOR's color values, and set the texture node's color space as linear srgb, then I will have the same image as the viewport.
• I can also call BasicTransformColor() with COLORSPACETRANSFORMATION::LINEAR_TO_SRGB before setting the image buffer, and also set the texture node's color space as srgb, then I will also have the same image as the viewport.

Although the two way work, I'm not sure if some settings can change the MODATA_COLOR's values I get, so I asked the original question.

Thank you very much for the detailed explanation, @ferdinand.
Sorry for not making the initial question clear.

I actually need to support multiple C4D versions: from R21 to latest R2025.
I have noticed that the new R2025 changed the color management system settings under Scene Settings -> Project -> COLOR MANAGEMENT.
I also played the COLOR MANAGEMENT settings in both R2025 and R2024, it seems all possible options use linear color space for calculations. But my concern is if there are options that could make it use non-linear color space for calculation, and if it leads to changing an object's MODATA_COLOR data values.

The below is the code snippet used to get the MODATA_COLOR data.

BaseObject *op = xxx;
BaseTag *tag = op->GetTag(ID_MOTAGDATA);
if (tag)
{
    GetMoDataMessage msg_data;
    if (tag->Message(MSG_GET_MODATA, &msg_data) && msg_data.modata)
    {
        MDArray<Vector> colors =  md->GetVectorArray(MODATA_COLOR);
        ...............
    }
}

The colors data got in the above code snippet will be used to set a customized texture object's input image. And the customized texture object's color space matters.
I found that I will have the expected result if only linear color space is used in the customized texture object in a test scene.
In R2024, I always found "The Application uses Linear Space for Calculations." in Basic COLOR MANAGEMENT regardless of the settings.
In R2025, I found different information (e.g. "Calculations happen in linear sRGB space.", "Calculations happen in ACES2065-1 space.") in COLOR MANAGEMENT according to the settings. And all of them seems to be linear color spaces in the scene I used.
But I don't know if the MODATA_COLOR data got above will always in linear color space. And I couldn't enumerate all possible COLOR MANAGEMENT settings to check.
So I'd like to find out if there is a way to get the color space of the MODATA_COLOR data, so the correct color space could be set in the customized texture object.

Thank you!

Hi,
Could you please help me found the way to get the color space of the MODATA_COLOR retrieved from a object by C++ SDK?
I'd like to check if its color space could be changed to non-linear color space by some settings.
It seems the MODATA_COLOR remains in a linear color space regardless of settings in Scene Settings -> Project -> COLOR MANAGEMENT.

Thanks!

Thank you, @f8bet00net.
Yeah, I remember I had gone though this with you before. But recently, we found there is a way to customize TreatSpecificWarningsAsErrors settings in projectdefinition.txt for MSVCBase.props for windows VS projects.
So I asked this question again just to double confirm if we could do similar things for MacOS XCode settings.
Thanks for confirming this is not possible on MacOS.

Hi,

Is there a way to customize the below settings in projectdefinition.txt when a mac project is generated by project tool?

1. frameworks/settings/compiler.xcconfig: OTHER_CPLUSPLUSFLAGS. I'd like to use a different set of flags.
2. frameworks/settings/debugbase.xcconfig, frameworks/settings/releasebase.xcconfig: ARCHS, MACOSX_DEPLOYMENT_TARGET, MACOSX_DEPLOYMENT_TARGET[arch=arm64]. I'd like to remove x86_84 arch, and change the deployment_target to a different version.

Thank you!

This works! Thank you very much, @i_mazlov.