Group Details Private

Global Moderators

Forum wide moderators

  • RE: DrawHudText interferes with Polygon Pen Tool etc

    Hi Flavio,

    Thanks for getting back to us! There's no reason to be sorry, it's the opposite, you're very welcome to share your ideas and post questions!

    I've forked your question to a separate thread. Even though this sounds like a similar issue, under the hood it can be a completely different story 😉

    Please attach a sample project file (or at least the python code you're using), which would help us reproducing the behavior from the video. This makes things happenning easier and faster.

    Cheers,
    Ilia

    posted in Cinema 4D SDK
  • RE: Maxon API for Python

    Hey @ThomasB,

    Thank you for reaching out to us. First of all, there is no classic API anymore, see here for details. It has effectively been renamed to Cinema API.

    • Cinema API: Contains components that are specific to Cinema 4D, as for example its scene graph, the whole plugin system, and also a lot of low level components, e.g., c4d.Vector.
    • Maxon API: Contains components that are not specific to Cinema 4D and either could be or are actively used by other Maxon apps (in fact Cinema 4D is not guaranteed to use all parts of the Maxon API itself). The Maxon API contains both high-level components, e.g., the Asset or Nodes API, as well as low level components such as data types, e.g., maxon.Vector. You can think of the Maxon API as Maxon's C++ std library.

    Even in C++, the Maxon API is not meant to replace the Cinema API, but rather to complement it. It is not impossible that we one day will say, 'let's write an abstract scene graph model that we will then also use in Cinema 4D', but that would be a truly huge undertaking. For now, fundamentals of the Cinema API such as BaseContainer, C4DAtom, GeListNode, BaseList2D, BaseDocument, or BaseObject are here to stay.

    These days many components in the Cinema API are also only thin wrappers or just aliases for the Maxon API. When you create a cinema::Vector in C++, that is just an alias for a maxon::Vec3<maxon::Float64,1>, i.e., a 64bit R³ vector template. The same also applies to Python, when you create there a c4d.Vector, what will actually operate for you under the hood is such maxon::Vec3 template for Float64. This applies to many pure data structures and also things like bitmaps, paths, colorprofiles, and other lower level data. The Maxon API also has high level components such as Assets, Nodes, or Volumes and when there are important systems which make sense to expose to Python, we will expose them. But the bottom line is here, for frontend users such as Python, the Cinema API is mostly the thing to work with.

    When you want to get a better sense of how our APIs are structured, you can look at the C++ Manual API Overview.

    Cheers,
    Ferdinand

    posted in Cinema 4D SDK
  • RE: C4D Python: Redshift IPR Start/Stop Control

    Hi @itstanthony you can use c4d.CallCommand(1040239) to toggle the start/stop of the Redshift IPR.
    You can know such command ID by using the Script Log and doing the action you want to.

    Then to check if the command is active you can use c4d.IsCommandChecked(1040239).

    Cheers,
    Maxime.

    posted in Cinema 4D SDK
  • RE: Cache Proxy Tag

    Hello @JohnThomas,

    Thank you for your clarifications, but unfortunately they do not bring much clarity for me. It is still unclear to me what you want to achieve.

    1. Tcacheproxytagpointselection and its edge, polygon, vertex color, and vertex map counter parts are a MoGraph mechanism to link from a generator, i.e., the tags visible in the Object Manager to tags in the cache of something, i.e., the invisible part of a scene graph. So that the user can interact with tags buried in the cache of something. They are one of the MoGraph workarounds for the very problem I described above. The generator using them has of course to support them/create them, because you need a selection/vertex tag on some point object in the cache in the first place, to which the proxy can link. I.e., you cannot just create proxy tags on anything.
    2. You can create a proxy tag yourself. Since it is just a variable tag, you can just the generic VariableTag interface for that. But the concrete interface is private, so you would have to reverse engineer how they work, but they are effectively a hollow shell which just carry a base link to their linked entity in their data container (and some other meta data). The real challenge would be to keep that meta up to date, i.e., mimic how MoGraph operates these tags.
    3. You also talk about fields implicitly all the time, specifically a variable tag field, i.e., a field which can sample things like selection tags and their proxies. Variable tag fields of course only support variable tags and nothing you would write yourself.

    Cheers,
    Ferdinand

    posted in Cinema 4D SDK
  • RE: Frozen Matrix different

    Hi @chuanzhen,

    Glad to hear the issue went away.

    Just to note, the frozen matrices are designed in a way that simulate behavior of an intermediate parent null object, i.e. just as if you had an invisible parent null object with matrix being equal to the frozen one. Sometimes it can get confusing, because the way the global matrix of the object is calculated is effectively:

    [Local Matrix] = [Frozen Translation] * [Frozen Rotation] * [Relative Translation] * [Relative Rotation] * [Frozen Scale] * [Relative Scale]

    If the relative transform (the main one) and the frozen transform are the same for two objects, given they are children of the same parent and there're no other 3rd parties involved (e.g. plugins, python tags etc), the global transform matrices of these two objects are the same.

    Please find more useful insights in our great Matrix Manual.

    Cheers,
    Ilia

    posted in Cinema 4D SDK
  • RE: Graphic card

    Hey @pim,

    I am not quite sure how you mean that, but it is an open secret that AMD/Intel x86 APUs (CPU + GPU) are usually not so great in their GPU performance; one could also say they tend to suck big time on the GPU side. When we look at the AMD Ryzen 680M performance, we can see that the dirt cheap last generation entry level GeForce RTX 4060 Mobile is absolutely destroying it with 4.6 times its performance in the 3DMark 11. Or to make it tangible: A rendering which takes 10 minute on that last generation entry level GPU will take 46 minutes on that APU.

    via notebookcheck.net:
    3e03615b-b289-4b7f-8225-1f1078fd6e53-image.png

    The 3D Mark performance is of course only indirectly important for Cinema 4D, as it directly only applies to the viewport, so my little tangible rendering comparison was a bit cheated. But it is indicative of the Cuda/OpenCL performance which is very important for rendering and simulation in Cinema 4D. notebookcheck is only using very old versions of Cinebench (only using the CPU), but I bet when you dig long enough, you will also find modern Cinebench 2024 scores (which use the GPU for rendering) for the AMD Ryzen 680M, and they will be horrible.

    There are mini PC Windows builds which use dedicated mobile GPUs which will yield much better performance. They use mobile GPUs to fit into mini PC cases, and to keep their thermals in check, but the good builds tend to be very pricey. I would not buy anything under an RTX 4070 mobile GPU-wise for Cinema 4D. And even though Windows mini builds exist, they tend to be limited due to what is lined out below.

    Because what cannot be overstated enough, is that the biggest issue with mini (x86) PC builds are the thermals. And your in theory super nice and shiny hardware will then be thermally throttled by 20%, 30%, or even 40% of its performance when some chip thinks after ten minutes of usage that it is getting too toasty. You can build very potent systems with x86/CISC architecture (Intel/AMD CPUs), which are also reasonably quite. But they are always huge (go under the desk and not on it), and you better not look at their power consumption and thermals. You can build mini x86 setups, but they then either sound like a starting rocket engine all the time (and such hot hardware also tends not to live very long) or get thermally throttled into oblivion. That is especially true for non-gaming rigs where you often want a lot of RAM and SSDs which worsen the heat problem.

    The alternative is the ARM/RISC architecture because it is just better at being power efficient. Maxon currently only ships Cinebench for both the Apple and Windows ARM architecture. Cinema 4D is only shipped for the Apple ARM architecture, i.e., the M-series.

    I have a quite beefy Windows workstation in the office. It is great in performance and reasonably quite, but has the size of a mini fridge and the power consumption of a small town. I very recently got my new Mac device for/from work, an M4 Mac mini 10C with 32GB of RAM, i.e., one of the lower end configurations. And this thing is an absolute unit when it comes to performance, fits into the palm of my hand, and has exceptional thermals and power consumption. I have not done any any concrete comparisons, and I think my Windows machine is still a bit more potent when push comes to shove, but the Mac mini gets VERY close for a fraction of the cost and size.

    So, long story short: When you want a mini build, ARM is the way to go. But ARM has not yet fully matured on Windows and Maxon is currently not shipping Cinema 4D for ARM on Windows. Even as a long standing Apple non-appreciator, I have to admit that the M-series is an exceptional architecture with exceptional performance. When Apple is not an option, I would advise against a mini build, as there are currently simply no truly viable mini x86 builds which offer sufficient CPU and GPU performance for a 3D workstation. For an x86 3D workstation you are more or less forced to go with a big-box-under-the-desk build.

    Cheers,
    Ferdinand

    posted in General Talk
  • RE: Cache Proxy Tag

    Hey @JohnThomas,

    Thank you for reaching out to us. We just talked about your question in our morning meeting, and none of us does truly understand it. So, let me state a few facts about the literal question you asked:

    Specifically I'm trying to achieve the behavior shown in this clip, where the Text object is able to be changed by the Plain effector without being made editable due to its selection tag, while the Rectangle spline has to be made editable to be changed.

    âš  Plugin authors should treat caches as read-only although they technically are not. Internally, we pull a lot of caching tricks, as this is certainly possible and desirable in some cases. But you can also quite easily crash Cinema 4D when you do not know what you are doing. Especially allocations or deallocations are absolutely off limits, as something could have already established a pointer to some internal data. E.g., you cannot add or remove points to/from a PointObject when poking around irregularly in caches.
    1. Editing things without making them editable just means modifying their cache. So, for your Rectangle spline, you could call myRect->GetCache() and then find there a LineObject which you could edit. See geometry_caches_s26.py for an explanation of the cache model of Cinema 4D, as navigating caches can become quite complex.
    2. The natural model to modify caches are deformers, i.e., ObjectData::ModifyObject, as for example done by the Bend deformer. That is also what MoGraph is doing with its effectors once you enable one of the deformer modes. Tags in general or specifically Tcacheproxytagpointselection are only tangentially relevant.
    3. Another (although not recommended) way to modify the caches of things can be TagData::Execute or ObjectData::Execute, i.e., a tag or an object acting like a tag. You simply reach there into the cache and do stuff, but other than for ModifyObject you are not as well shielded for access violations/update anomalies there. The reason why one would do this, is to put a possible deformation step somewhere else in the excution pipeline (as you can specify when in the scene evaluation the Execute methods are called).
    4. Modifying the cache of an object is volatile, i.e., will just be discarded on the next scene update. So, unless you do it in regularly called places such as ModifyObject or Execute, this will not work. And when you do this outside of the context of these two methods, you are pretty much guranteed to crash Cinema 4D sooner or later.

    When I read here a bit between the lines, the implicit question does not seem to be actually about deforming the output of other generators but how selections work in the context of generators.

    As a rule of thumb we can say that selections do not work with generators. It is only for generators which yield a simple (i.e., one object deep cache) and some hard coded extra cases where you can put a point/edge/polygon selection tag on that generator and Cinema 4D then being able to interpret that selection tag correctly. Because a selection tag is effectively just a list of selection states such as [True, False, False, True], where this list would mean that the elements with the indices 0 and 3 are selected while the elements with the indices 1 and 2 are not selected. When you now have a scene structure like this:

    myGenerator (BaseObject)
    ├── Tags
    │   └── myPointSelection (SelectionTag): {True, False, False, False}
    └── Cache
        └── myNull (BaseObject)
            ├── poly.0 (PolygonObject)
            └── poly.1 (PolygonObject)
    

    The selection tag myPointSelection is ambiguous as it is not clear which of the PolygonObject instances in the cache of myGenerator it is referring to. So, Cinema 4D will just ignore it. Only when it is clear to which Point/Line/PolygonObject a selection tag is referring to, it will be used. There are some hardcoded exceptions in the case of MoGraph, but you must implement them manually in the 'user' of such selection, i.e., the thing that takes such selection as an input. So, long story short, this is why this works for the text spline but not the text object, one has a simple cache structure and the other has not.

    13ae9338-800a-4426-b864-0734391a2aa2-image.png

    Cheers,
    Ferdinand

    posted in Cinema 4D SDK
  • RE: Set RenderData framerate causing C4D to crash

    Hi I was able to reproduce the issue and fix it for the next version.
    The bug is that setting RDATA_FRAMERATE require the RenderData to be part of a document in case the "Use Project Frame Rate" is enabled on the render settings. If this is enabled and this is enabled by default the value you enter will be disregarded. "Use Project Frame Rate" is a new setting added in 2025.2.

    I will ping you once the fix is available.
    Cheers,
    Maxime.

    posted in Bugs
  • RE: Set RenderData framerate causing C4D to crash

    Hi @chuanzhen,

    The issue is not reproducible on my machine with C4D: 2025.2.1 (Build 2025_2_1_10be3ac9d371_1759753353) Win

    Cheers,
    Ilia

    posted in Bugs
  • RE: Adding an Object to a New Cinema 4D Asset Database

    Hi @d_keith,

    I would kindly ask you to check our Support Procedures, namely the "How To Ask Questions" paragraph:

    Singular Question: The initial posting of a support topic must contain a singular question. Do not ask ten things at once, that makes it extremely hard to answer topics. Break up your questions into multiple topics.

    Here you effectively have 4 different questions about Asset Browser, and these are candidates for 4 different threads on the forum. In your further postings please try to follow the aforementioned rules.

    Regarding your questions:

    1. Should I be able to mount a directory and have it auto-create a DB?

    Mounting database is effectively executing the AssetDataBasesInterface.SetDatabases. It has nothing to do with creating database neither semantically, nor is this mentioned in the docu. If you need to create repository, please use maxon.AssetInterface.CreateRepositoryFromUrl(), it will scan the directory for being already a database and create proper dir structure if it's not.

    1. Any idea why I need to re-try creating the Repo for it to work?

    If you face any errors in the script, please always attach at least the error message! In this case I assume you receive the following error, when executing the maxon.AssetRepositoryTypes.AssetDatabase() for the first time after Cinema 4D started. Looks like a bug to me, I've created a bug report for that (ITEM#585831).

    The error message:

    Traceback (most recent call last):
      File "console", line 1, in <module>
      File "C:\Program Files\Maxon Cinema 4D 2025\resource\modules\python\libs\python311\maxon\interface.py", line 5049, in __call__
        self._cachedObj.R = _maxon_mapping.GetAssociatedDataType(dt)
                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    Exception: unable to find datatype
    

    As a workaround you can just execute the following line first in your main():

    maxon.AssetRepositoryTypes.AssetDatabase()
    
    1. ... about multiple DBs ...

    You're giving your databases unique IDs with the line repo_id = maxon.AssetInterface.MakeUuid(str(url), True). If you need them to be the same, just pick one instead, e.g. repo_id = maxon.Id('net.maxon.sdk.cool.things.repo')

    1. ... revealing assets doesn't work...

    I've created a bug report for that, as it looks like a bug with refreshing in the Asset Browser. As a workaround you can reload databases and reopen the AB before reveling your assets, e.g.:

    def RepenAssetBrowser():
        CID_ASSET_BROWSER = 1054225
    
        # Close the Asset Browser if it's alredy opened
        if c4d.IsCommandChecked(CID_ASSET_BROWSER):
            c4d.CallCommand(CID_ASSET_BROWSER)
        
        # Open again
        c4d.CallCommand(CID_ASSET_BROWSER)
    
    def main():
    	# ...
    	# assets = []
    	# ...
    	# assets.append(asset)
    	# ...
    	
        maxon.AssetDataBasesInterface.ReloadAssetRepositories(True)
        RepenAssetBrowser()
        maxon.AssetManagerInterface.RevealAsset(assets)
    

    Cheers,
    Ilia

    posted in Cinema 4D SDK