Hey @d_schmidt yes this is expected, openvdb is sparse with 4 level tile options. Since our volume tool use openVDB we inherit from that.

In the context of OpenVDB and similar data structures, "sparse" refers to a way of efficiently representing and storing data in which only the non-empty or non-default parts are explicitly kept in memory. This is in contrast to dense representations, where every element is stored regardless of whether it holds meaningful information or not.
In a sparse representation like OpenVDB, the data structure is designed to allocate memory only for the parts of the voxel grid that contain relevant data (i.e., active voxels), while ignoring the regions that are empty or hold similar values. This allows for significant memory savings and performance improvements, especially when dealing with large grids where most of the space is empty/similar.

So with that's said the way to retrieve what you expected is with the next code. Note that I've used Multi-Instance for speed reason and not polluting too much the viewport.

constexpr inline Int ConvertVoxelLevelToAmount(TREEVOXELLEVEL level) { switch (level) { case TREEVOXELLEVEL::ROOT: { return 32; } case TREEVOXELLEVEL::TWO: { return 16; } case TREEVOXELLEVEL::THREE: { return 8; } case TREEVOXELLEVEL::LEAF: { return 1; } } static_assert(true, "Unsupported voxel depth"); return 0; } class Command : public CommandData { public: virtual Bool Execute(BaseDocument* doc, GeDialog* parentManager) { iferr_scope_handler { return true; }; BaseObject* object = doc->GetFirstObject(); if (!object) return true; if (!object->IsInstanceOf(Ovolumebuilder)) return true; VolumeBuilder* const volumeBuilder = static_cast<VolumeBuilder*>(object); // get cache BaseObject* const cache = volumeBuilder->GetCache(); if (cache == nullptr) return true; // check for volume object if (!cache->IsInstanceOf(Ovolume)) return true; const VolumeObject* const volumeObject = static_cast<VolumeObject*>(cache); maxon::Volume volume = volumeObject->GetVolume(); maxon::GridIteratorRef<maxon::Float32, maxon::ITERATORTYPE::ON> iterator = maxon::GridIteratorRef<maxon::Float32, maxon::ITERATORTYPE::ON>::Create() iferr_return; iterator.Init(volume) iferr_return; maxon::Matrix transform = volume.GetGridTransform(); BaseObject* sphere = BaseObject::Alloc(Osphere); BaseContainer* con = sphere->GetDataInstance(); con->SetFloat(PRIM_SPHERE_RAD, 5); doc->InsertObject(sphere, nullptr, nullptr); // create instance object InstanceObject* const instance = InstanceObject::Alloc(); if (instance == nullptr) return true; doc->InsertObject(instance, nullptr, nullptr); instance->SetReferenceObject(sphere) iferr_return; if (!instance->SetParameter(ConstDescID(DescLevel(INSTANCEOBJECT_RENDERINSTANCE_MODE)), INSTANCEOBJECT_RENDERINSTANCE_MODE_MULTIINSTANCE, DESCFLAGS_SET::NONE)) return true; maxon::BaseArray<Matrix> matrices; for (; iterator.IsNotAtEnd(); iterator.StepNext()) { if (iterator.GetValue() < 0.0) continue; const Int voxelAmount = ConvertVoxelLevelToAmount(iterator.GetVoxelLevel()); for (Int32 voxelIndexX = 0; voxelIndexX < voxelAmount; voxelIndexX++) { for (Int32 voxelIndexY = 0; voxelIndexY < voxelAmount; voxelIndexY++) { for (Int32 voxelIndexZ = 0; voxelIndexZ < voxelAmount; voxelIndexZ++) { const maxon::IntVector32 voxelCoord = iterator.GetCoords(); Matrix m; m.off = transform * Vector(voxelCoord.x + voxelIndexX, voxelCoord.y + voxelIndexY, voxelCoord.z + voxelIndexZ); matrices.Append(std::move(m)) iferr_return; } } } } instance->SetInstanceMatrices(matrices) iferr_return; EventAdd(); return dlg.Open(DLG_TYPE::ASYNC, ID_ACTIVEOBJECT, -1, -1, 500, 300); } virtual Int32 GetState(BaseDocument* doc, GeDialog* parentManager) { return CMD_ENABLED; } };

Cheers,
Maxime.

Hi Ferdinand,

Yes, I remember reading about that, so the IDs for this container data is 5060 and 5061 (I work in IP telephony as my day job so this is surely no coincidence), but I even tried to move them to 50060 and 50061 and the freeze still happens.

I will pack up the project shortly and email it in. 🙂

Hello @JohnThomas,

Thank you for reaching out to us. Without your code and the high level design of your field, it is hard to give here good advice.

Dependencies in Cinema 4D

Cinema 4D does not have a dependency graph in a more narrow sense. So, when we have this scene graph:

Obj.1 Obj.1.1 Obj.2 Field.F

Cinema 4D will by default update the scene in depth-first traversal: Obj.1, Obj.1.1, Obj.2, Field.F, .... With ObjectData.CheckDirty an object can signal to Cinema 4D that it considers itself outdated and with that invoke a scene update. With ObjectData.AddToExecution you can influence when ObjectData::Execute is being called in a scene update (and with that sidestep the pure hierarchical execution to some degree), and with NodeData::GetAccessedObjects you can tell Cinema 4D which parts of the scene graph can be evaluated in parallel (e.g. tell Cinema 4D that it is safe to eval Obj.1 and Obj.1.1 in parallel, because both signal that they do not access each others data). But GetAccessedObjects is about access violations, and not update dependencies, so you cannot tell Cinema 4D to wait for something with this function.

So, for Obj.1 which relies in its cache output on the cache output of Obj.2, you have already a problem with 'normal' cache generating objects, as Obj.1 will be built before Obj.2. Cinema 4D's solution to that are hierarchies. Cache relevant inputs are generally expected to be child objects of the object which needs them, e.g., a spline (Obj.1.1) below an extrude object (Obj.1). The object with a dependency then calls one of the a bit ill named "hierarchy clone" BaseObject methods:

bcfcb012-01f5-488f-befe-0790effeccfd-image.png

Which effectively result in the children, the dependencies, being built before the dependent (the parent), and the dependent therefore operating on data from this scene update and not the last one. But this really only works within the local hierarchy of an object.

Dependencies for a Field

Your case is rather tricky here, because fields, while being objects, fall outside of that scheme. You could also say that fields are not really meant to be dependent on other scene elements; although Cinema 4D has some native fields which violate that rule.

The problem is that fields, other than polygon and spline generators are not executed themself at a fixed point in the scene update but rather are polled by other objects while they are updating themselves. Fields also do not mix well with the "things I depend on, should be my children"-scheme.

When your field is just linking some simple object, you can just draw a copy from that object, put it into a dummy scene, and execute the passes there, to get the current state of that object (possibly before it updates itself because it comes 'after' the object which invokes your field). But this strategy quickly falls
apart when that linked node has complex dependencies itself. You can technically clone the whole scene and eval the passes there, but that is performance wise terrible and you must also avoid feedback loops, as such cloned scene would also contain your field which clones the whole scene upon sampling.

Bottom Line

There is no ideal solution here. Cinema 4D's dependency handling is not perfect, but people often also do not realize that they build conceptually impossible systems. A field which relies on the cache of an object could be linked as a field in that very object it depends on to build that object's cache. An impossible scenario.

There are ways to solve this to a certain degree, but they depend on the case, and generally also require some sophisticated critical case checking. Cinema 4D's architecture largely prevents from the worst things happening when users construct cyclically dependent scenes (a cube C which depends on a sphere S which depends on the cube C which ...), but when you start manually executing passes within scene execution all that is out of the window.

Maybe you can shed some light on what you are trying to achieve on a higher level?

Cheers,
Ferdinand

@ferdinand Thanks for your help!👍

Thank you very much for all your detailed explanation, @ferdinand!

Hey @vhardy,

yes, @m_adam as supporting expressions on his Todo list for the VS Code bridge. But it is not very high in our priority list, you are the first user requesting it. I gave the subject a gentle nudge in our task tracking.

FYI: Generally we do not make any guarantees if or when we will implement something.

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,
yes, this is expected, and documented in NodeData::Read() / NodeData::Write() Manual. With that's said Read/Write is supposed to serialize data of your object (most of the time member variable) to the c4d file (the HyperFile), so accessing the BaseDocument is a sign of a bad design.

May I ask why do you really want to access the BaseDocument in the Read function?

Cheers,
Maxime

edit (@ferdinand): Just to be clear here, as we briefly talked about this in our morning meeting, what the docs write there is in a certain sense legacy information. When a branch, e.g., the Xbase (shader) branch of a material is being deserialized, the to be deserialized node is inserted into the branch and with that will have access to a document.

But what @m_adam wrote is of course true, the document in this context is the fruit from the forbidden tree, as the node is not yet fully deserialized and certain parts of the GeListHead::Read, GeListNode::Read, BaseList2D::Read, ..., YourPluginLayer::Read deserialization chain might pull all sorts of tricks to carry out the deserialization, including temporarily removing the node from the scene graph.

The documentation is therefore effectively still correct, as deserializing a node should never rely on the document context and accessing the document is forbidden in that context.

@m_adam thanks for your prompt response. I'm looking forward to hearing from you.

Ok Understood,

Ok I guess that explains my "nice" comb from the cache and my jagged flip/flop . sometimes zero comb from the "full" matrix normal ...

I also have different tangents from manually "calculating" them then v3, v2. But I will make a "sanity" check this weekend (feed manual matrixes into my code instead of spline "point" matrixes), before I post about this.

Thanks Ferdinand
I'll divide and conquer away.

Thank you for @Dunhou answer. It was ultimately completed in JSON format

Hey @kbar,

I hope you are well! Since I just answered a similar question in another topic, I am also answering here. We never make any guarantees regarding when something will be released in SDKs. And more-over, we never name upcoming Cinema 4D versions explicitly or when they will arrive. This also includes seemingly insignificant information such as if the next version will be a minor or a major version increment.

Please note that you as Maxon Registered Developer are bound by an NDA and also cannot disclose such information to the public.

But yes, I am pretty sure Maxime meant the next upcoming release.

Cheers,
Ferdinand

Hello @patrick_cue,

Welcome to the Maxon developers forum and its community, it is great to have you with us!

Getting Started

Before creating your next postings, we would recommend making yourself accustomed with our forum and support procedures. You did not do anything wrong, we point all new users to these rules.

Forum Overview: Provides a broad overview of the fundamental structure and rules of this forum, such as the purpose of the different sub-forums or the fact that we will ban users who engage in hate speech or harassment. Support Procedures: Provides a more in detail overview of how we provide technical support for APIs here. This topic will tell you how to ask good questions and limits of our technical support. Forum Features: Provides an overview of the technical features of this forum, such as Markdown markup or file uploads.

It is strongly recommended to read the first two topics carefully, especially the section Support Procedures: Asking Questions.

About your First Question

Please do not use other topics for your support requests, especially when they are bug tickets. Asking a follow-up questions such as "when will this be fixed" or "does this also apply to situation B" in a foreign topic is allowed and even encouraged.

But a specific case with your specific code and data always warrants a new thread. Please also familiarize yourself with Support Procedures: Asking Questions, as while it its clear that you put effort into make yourself understood (thanks!), this is also bordering a bit on the too much information.

The bug tracked by the other topic, is that there is currently no way in the Python API to use c4d.documents.RenderDocument in an OCIO document (i.e., every document since 2025.0) and then display that bitmap with the correct colors via c4d.bitmaps.ShowBitmap. It is important to understand that:

The bitmap data generated is just fine, when you save the bitmap to disk, everything is correct. It is just that the Picture Viewer does not display it incorrectly.

The reason for that is that in Python OCIO is not fully exposed in 2025.1.0 and you cannot set the OCIO profiles of the rendered bitmap there. Internally, we have been working on an OCIO port for Python allowing for color conversions and more things, including OCIO managing bitmaps. We also added a function to bake a display and view transform into an sRGB image - another route how this RenderDocument issue can be solved.

The goal is to publish this with an upcoming version of the Python SDK, ideally the next, but as always we cannot make any guarantees. You cannot fix this issue yourself in 2025.1.0 and lower.

Cheers,
Ferdinand

@i_mazlov Thanks for the reply. I may have described it wrong. I am talking about the image viewer. It seems that there is currently no API interface to get the number of frames rendered, nor can I get the total number of frames in the rendering settings.

Hi @Neekoe,

That's great to hear you've managed to solve the issue!

For your future postings please note that according to our Support Procedures:

We cannot debug your code for you and instead provide answers to specific problems.

This effectively means that you're welcome to ask your questions and attach the code snippet that demonstrates your question or issue you're struggling with. However, we cannot debug your entire codebase, so you have to isolate your specific question and the corresponding part of code yourself before asking the question.

Cheers,
Ilia

Understood Thanks.

curvature_comb.png

not bad for 5 hours of dabbling --- thanks to you @ferdinand

Gotcha's:
The Curvature was 90dgree rotated - LLM to the rescue ...

# c4d.plugins.RegisterTagPlugin( .... # That one nearly got me ;-) # c4d.TAG_IMPLEMENTS_DRAW_FUNCTION # R22

cheers

Thanks @Neekoe to have shared your solution and thanks @Dunhou for helping.
When you pass LV_TREE the Draw method is not called to have it called you need to pass either LV_USERTREE or LV_USER.

Cheers,
Maxime.

@freeze I wrote this a few years back which might give you a good starting point.

https://plugins4d.com/Product/FunRay
https://github.com/kentbarber/rtow4d

Cheers,
Kent

Hello @DayDreamer,

Welcome to the Maxon developers forum and its community, it is great to have you with us!

Getting Started

Before creating your next postings, we would recommend making yourself accustomed with our forum and support procedures. You did not do anything wrong, we point all new users to these rules.

Forum Overview: Provides a broad overview of the fundamental structure and rules of this forum, such as the purpose of the different sub-forums or the fact that we will ban users who engage in hate speech or harassment. Support Procedures: Provides a more in detail overview of how we provide technical support for APIs here. This topic will tell you how to ask good questions and limits of our technical support. Forum Features: Provides an overview of the technical features of this forum, such as Markdown markup or file uploads.

It is strongly recommended to read the first two topics carefully, especially the section Support Procedures: Asking Questions.

About your First Question

This is your first posting and you did well, but I would point you to our 'singular question' rule, as lined out above in the 'Asking Questions' link. While we usually cut user some slack regrading that, the rule exists for a reason, as topics otherwise tend to become gigantic. There are way too many questions in this topic, please split your questions into multiple topics in the future.

There is no mechanism to package and ship plugins under Cinema 4D. You can just zip a plugin folder and the user unzips it then in a path where his or her Cinema 4D instance is looking for plugins. xdl64 is the extension Cinema 4D uses for libraries under Windows, i.e., it is more or less an alias for dll (our library linking is kind of special and right between static and dynamic libraries, hence the custom name). So, no, Python plugins cannot be packaged as xdl64 because Python is not compiled into machine code but interpreted at run time. You can mix C++ and Python plugins in the sense that Python plugins can depend/interact with C++ plugins with the means of the Cinema 4D API. E.g., a Python plugin can react to messages sent by a C++ plugin or data placed by a C++ plugin (or vice versa). That is how our Python API works under the hood. But C++ and Python code cannot interact directly of course, as they are vastly different languages. But you can run our Python VM from C++ and eval the results. When you want to protect your intellectual property, you can use our Cinema 4D | Extensions > Tools > Source Code Protector which will encrypt a pyp Python module. But code must of course be decrypted at runtime to be sent to the Python VM, so, this will not really stop anyone who really wants your source code (a cracker for example). C++ is the by far safer option when intellectual property is important (but also C++ can be decompiled).

Cheers,
Ferdinand