Posts made by bojidar

Hi
Currently we iterate over variadic ports with variadicPort.GetPorts but it seems to always have one default port ("#") when all variadic children are cleared. I guess that is expected behaviour so is there some safe way to know when to ignore the port? Can we simply check if the id of the port is "#"? Or should we think about using a different approach e.g. somehow calling GetChildren on a maxon::GraphNode which at first glance seems to work?

With the example gradient node after clearing all knots in the first ramp I get something along the lines of:

maxon::nodes::PortList portList = maxon::nodes::ToPortList(gradientBundle)
    iferr_return;
for (auto portResult : portList.GetPorts())
{
    WarningOutput(portResult.GetValue().ToString(nullptr));
}
gradientnode@R9OPuVzGMZ5nE94TL6Qp2q<firstbundle/#
gradientnode@R9OPuVzGMZ5nE94TL6Qp2q<secondbundle/_0
gradientnode@R9OPuVzGMZ5nE94TL6Qp2q<secondbundle/_0

Hello,
We recently noticed that when merging files through our scene file loaders in 2025 the colors on existing materials in the scene were changing. Our loaders just insert some objects/materials in the document we are provided with in ::Load(...) and are registered with PLUGINFLAG_SCENELOADER_MERGEORIGINAL which seems to be the problem. If I remember correctly we use it because of some problems with document scale when merging. Without it everything seems to work and I also noticed that PLUGINFLAG_SCENELOADER_HANDLES_COLOR_MANAGEMENT fixes it. However, I'm a bit confused now.... How do these flags cause the behavior we are seeing and why would other materials in the scene ever change when merging? And are these 2 flags a valid combination?

Is maxon.natvis supposed to work for Node types e.g maxon::GraphNode, maxon::nodes::Node or did we miss something obvious? It seems they use some internal types which are not available and I ended up writing something similar to the pointer arithmetic in the python lldb script.

Is there a way to get notified when Set Color Space in the Project Asset Inspector is used? I noticed that it works with the standard renderer and Redshift and looked around for a message but didn't find anything.

Hi
Is there a way to hide the illumination group that comes from the standard Cinema4D Mmaterial for node materials? If I remember correctly it was still visible in Redshift until recently and it was removed, so is there some magic way of doing that or is it currently not possible?

Hey,
Sorry for the really delayed answer... Perhaps I didn't explain something well enough. What we changed was the id of a parameter as seen in the screenshot above in the Softbox shader from 613662896 to 1404507874 . The disk level used to be 0 before the change and then we set it to 1 after. So in more recent V-Ray versions we register the shader with disk level 1 and if I understand how the serialization works the level in the old scene should be 0 and Read should be called with a disklevel=0(since that is what ReigsterShaderPlugin was called with in the old V-Ray version). I was trying to do the same with another shader i.e. increment the disk level from 0 to 1 in RegisterShaderPlugin and do something along the lines of

if (diskLevel < 1) {
    BaseContainer &nodeData=static_cast<BaseShader*>(node)->GetDataInstanceRef();
    
    const BaseLink* oldLink=nodeData.GetBaseLink(oldParameter);
    
    if (oldLink != nullptr) {
    
    	GeData linkData;
    
    	linkData.SetBaseLink(*oldLink);
    
    	nodeData.SetData(newParameter, linkData);
    
    }
    
    nodeData.RemoveData(oldParameter);

and it just doesn't work in 2024.

Hello,
Why is the disk level being 0 there a problem? Isn't that the value of the disk level in the scene we are reading? So since it's an old scene and we didn't have any custom ::Read logic in the build this scene was saved with it should to be 0(the default value)? Also shouldn't the value only be changed in RegisterShaderPlugin(since the problem here is the Softbox shader) and not RegisterMaterialPlugin as the post says? We always change the disk level when adding logic in NodeData::Read and I also noticed it might only be broken with nested shaders as we have recently done the same in our Camera tag and it works fine in 2024.

Yeah, sorry I changed it right after posting the reply and didn't think it would be a problem.

This is about V-Ray for Cinema4D. In this scene there is a softbox texture(in the V-Ray material diffuse slot). Here the base texture of the softbox(the checker in the screenshot) is lost after loading the scene in 2024 and using the code in the original post, but loads fine in older versions. The old TEXSOFTBOX_BASE_TEX_TEXTURE=613662896 became TEXSOFTBOX_BASE_TEX=1404507874 and the issue should be reproducible with any V-Ray build for C4D 2024 from the last year.

Note that this isn't something critical as we only do it in a few places, however, it is slightly annoying
and mostly wrote to check if there is something obviously wrong with what we are doing .

From what I can see it works on 2023.2.1 and doesn't work in 2024.0. SetData is indeed called and returns true, however, oldLink->GetLink/ForceGetLink always return nullptr. So I guess the link isn't resolved? But when checking with the active object dialog example the shader is indeed there.

Hi,

So we used to do the following in NodeData::Read() whenever the id of a ShaderLink parameter had to be changed and preserve the shader from old scenes.

BaseContainer &nodeData=static_cast<BaseShader*>(node)->GetDataInstanceRef();
const BaseLink* oldLink=nodeData.GetBaseLink(oldParameter);
if (oldLink != nullptr) {
	GeData linkData;
	linkData.SetBaseLink(*oldLink);
	nodeData.SetData(newParameter, linkData);
}
nodeData.RemoveData(oldParameter);

However, on Cinema4D 2024 this doesn't seem to work if the NodeData is a shader. The old BaseLink parameter gets removed, the new parameter is set but the link still points to nullptr after the document is loaded. It does look a bit weird, so is there something I am missing or a better way to do this?

Thanks,
Bozhidar