administrators

Private

Posts

  • RE: Best way to hide a child and get best perfomance

    I do not quite understand your problem and more importantly what your goal is. Where does 'my path is no longer processed as GetRealSpline' happen? I assume with 'processed' you mean that you call BaseObject.GetRealSpline on something?

    1. Using CSTO as a stand-in for GetRealSpline sounds like a bad idea.
    2. It is better to use caches when possible, because there you do not have to copy whole documents to ensure that all dependencies are included. But you still have to copy something (the cache) but that is less expensive. When the whole thing happens for splines, the issue is that splines return LineObject and not SplineObject as their cache. See here for details. You can sort of just ignore the issue and treat the LineObject instances as if they were SplineObject instances, but that might cause issues here and there. Some tools/objects such as the Extrude Object also accept LineObject inputs even though a user can never manually create them. But there is no guarantee that everything that can deal with SplineObject instances as inputs also supports LineObject.
  • RE: Best way to hide a child and get best perfomance

    Regrading @ThomasB snippets, in the context of a GVO call I would curate my C4DAtom.GetClone more, e.g., with COPYFLAGS_NO_HIERARCHY, COPYFLAGS_NO_ANIMATION, or even COPYFLAGS_NO_BRANCHES. Copying a full node can otherwise be quite costly because it is not just "a node" but a whole subset of the scene graph with all the things which are attached to it.

    And that is exactly the problem I talk about in the SMC example I linked to above: Copying can be expensive. And in the broadest scenario you will always need everything, because dependencies can be complex. And even go beyond a pure "down"-dependency (with for example base link fields) where this copying approach then fails.

    • COPYFLAGS_NO_HIERARCHY: Means no children or deeper hierarchical descendants are copied.
    • COPYFLAGS_NO_ANIMATION: Means that no animation tracks or keyframes are copied (which are a form of branches).
    • COPYFLAGS_NO_BRANCHES: Means that no branches are copied. Children are not branches but pretty much everything else is. tracks, curves, tags, special data, etc., they will be all lost. Editable polygon- and spline objects store for example their point, tangent, and polygon data as tags, so you would loose all that. But it can make sense to use this on generator objects (e.g., "Cube Object" or "Circle Spline") to strip them of everything, as they are self contained capsules.

    For @ThomasB case it is probably more performant, to just build the caches for the inputs, i.e., the splines. Which will include all the crazy MoGraph fields and deformer dependencies with which splines could be modified, and then just use that cache as the input for the sweep. The caches of SplineObject instances will be LineObject instances, which is a little bit wrong to put them under a sweep. So, to make it perfect, you would just grab all the points and segments of the line object and re-express them as a new linear spline object.

  • RE: Best way to hide a child and get best perfomance

    Hey @Tpaxep,

    Thank you for reaching out to us. There are few things to unpack here.

    Hiding Input Objects

    Input objects are hidden automatically when you implement an ObjectData plugin that uses the flag OBJECT_INPUT and 'touches' its input objects, by for example calling GetAndCheckHierarchyClone on them as you do. This only works for direct children of the object, not grandchildren or even deeper descendants.

    Under the hood, this causes the input objects to have the flag BIT_CONTROLOBJECT to be set and then being touched which among other things will delete their cache, resulting in them becoming invisible. Technically you can do parts of this yourself (to hide also objects that are not direct children of your object) but:

    • Cinema 4D evaluates its scene graph hierarchically top down. This is also why you need GetAndCheckHierarchyClone so that you can build the cache of your descendants which has not been build yet when you are being built because fundamentally your child objects come after you in a hierarchy. I cannot unpack this in all detail, but trying to sidestep the cache building logic of Cinema 4D is not recommended and not trivial. Your inputs should always be direct children of yourself, otherwise you will land in a world of hurt sooner or later.
    • 'Hiding' inputs is actually deleting them. BaseObject.Touch literally marks the cache of an object for deletion and BIT_CONTROLOBJECT then later prevents the object from rebuilding it when it is its turn to naturally build the cache. No cache means there is nothing for the object to draw into the viewport. You can technically also hide objects with things like NBIT_OHIDE, but there you run into threading issues (see the section below) and also update issues. When your plugin does miss some case, the user ends up with a permanently hidden object in his or her scene, destroying his or her work. So, using NBIT_OHIDE in this context is not a good idea.

    Threading Restrictions

    Your code violates the threading restrictions of Cinema 4D. You run a modelling command in the GVO of your object plugin directly on an element attached to a loaded (in this case active) scene and with that risk crashes and loss of data. The subject is also explicitly being discussed for modelling commands in this code example (also read the file doc string as it explains some things).

    In general, you cannot change the state of scene elements from any threaded function such as ObjectData.GetVirtualObjects as this will sooner later lead to crashes. Functions such as GetVirtualObjects or ObjectData.GetContour will always only be called in parallel. Functions such as NodeData.Message might be called from the main thread (you can check with c4d.threading.GeIsMainThread) and therefore you can then manipulate the scene from there. E.g., implement a button in an object or tag plugin UI that inserts another object, deletes something, etc.

    Cheers,
    Ferdinand

  • RE: Batching Slider messages

    Hey @SteveHill3D,

    it's okay, the start is always a bit chaotic. That snippet alone would have told me some things.

    Yes, sorry, MSG_DESCRIPTION_POSTSETPARAMETER is fired within the drag event (the parameter has still to be set). The final description event is MSG_DESCRIPTION_USERINTERACTION_END. But I still do not really understand what you are doing. What is triggering the updates? Just dragging one of the sliders will not update the tool in our edge cutter tool example (because it does not really implement the interactive mode that comes with description tools).

    So, the tool should either fire when you have keyboard or viewport inputs and implemented MouseInput or KeyboardInput. When you click Apply, it should call DoCommand. You can of course hook into Message to react to all sorts of things (and that is indeed how you implement the interactive mode), but you message implies that your tool fires on your own. Which it should not.

    Cheers,
    Ferdinand

  • RE: Advice on implementing undo/redo in a Tool

    Hey @SteveHill3D,

    Storing a tool state in a tag is possible, but a bit unusual. But generally you are on the right track. Tags are also internally often used as hidden data containers. When you write a modelling tool, you probably already found out that points and polygons are are actually stored in hidden tags on objects.

    I am not sure though if using tags in tools is a good advice, as injecting all that data all the time into the scene graph is probably not the fastest. It depends a bit on what you are doing, but in general the solution is a bit unusual.

    Cheers,
    Ferdinand

  • RE: Batching Slider messages

    Hey @SteveHill3D,

    Thank you for reaching out to us. It depends a bit on what is your 'tool'. When it is a 'classic' tool, i.e., implemented as a ToolData with a GeDialog, then BFM_DRAGEND would be the way to sort out BFM_ACTION events for a slider that are the final action of a drag event. When you search for the message symbol BFM_DRAGEND and its sibling symbols BFM_DRAGSTART and BFM_ACTION_INDRAG here on the forum, you will find multiple code examples around the topic of sliders. I think there are also some examples in the C++ SDK.

    When your tool is a DescriptionToolData, i.e., a node in disguise, then you cannot handle drag events yourself. Your tool should fire on its own only after MSG_DESCRIPTION_POSTSETPARAMETER has fired for your node, i.e., after the final value of a drag event for some slider has been set.

    Please have a look at our Support Procedures, we require users to post code for pretty much all questions, as it minimizes the guess work on our side. As for example me here writing about two cases.

    Cheers,
    Ferdinand

  • RE: Tile rendering with Cinema 4D

    @karthikbp

    As far as I can see this at a glance, this seems to be correct. You already did the most important thing by using RDATA_RENDERREGION and not some camera cropping tricks, so it renders with the full scene data for each tile.

    There is however one issue, and it depends on the render engine how it is handled. At verbatim, kernels applied to your rendering (e.g., a box filter) will be slightly wrong, because for the the seams of a tile, there is data missing (the seam pixels of the neighboring tile) which would exist in a full rendering. E.g., when you have this,

    --------------- ----------------
                  x y
        Tile A    x y    Tile B
                  x y
    --------------- ----------------
    

    a rendering split into two tiles Tile A and Tile B, where x are the 'seam pixels' of Tile A and y are the seam pixels of Tile B. If you would have rendered the whole image in one go, processing one of the xs with a kernel would have included neighboring pixels, i.e., also what is now the seam pixels y of the other tile. So, at the borders of the tile, any filter kernels you will apply will not be quite the same.

    To prevent that issue, Redshift does render region tiles with an extra border of the maximum size of the kernels used for that rendering. But the standard renderer does not do that. Other render engines which might support our render region setting might not do that either. In such cases, you would have to either live with the small error or render with an extra border yourself, depending on the kernels that will be used., and then crop the final result back.

    Cheers,
    Ferdinand

  • RE: 2025 SDKs missing files

    Hello @atg,

    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: How to Ask Questions.

    About your First Question

    I can see why would think that, but you mixed things there a bit up. The CMake SDK build system was introduced with 2025.2.0 and became the standard with 2026.0.0. Between 2025.2 and 2025.3 we supported both build systems as a grace period for developers to get accustomed.

    Chances are very good, that you can just copy the CMake setup, i.e., the cmake folder and files such as CMakeLists.txt, CMakePresets.json, and sdk_modules.txt to a 2025.0 folder and it will generate a correct build system for you.

    But the supported range is only 2025.2+. For older projects you would have to use the old project tool based build system. Since I know what you are trying to do, I would recommend trying copying before you get into the old build system of ours.

    Cheers,
    Ferdinand

    edit: You will only find the old project tool tooling in old extended SDKs which supported it, such as 2025.2 or 2025.0.1

  • RE: CUSTOMGUI_QUICKTAB trigger twice when click

    hey @Gene,

    So, you were just trying to add information for future readers? That is of course very welcome and explains my inability to extract a question from your posting.

    I would not have been that generous with the word bug either. Since this has never been fixed, chances are high that we came to the same conclusion internally.

    In general, you should not expect Command calling patterns to make perfect sense in every case. There are multiple cases where Command is triggered more often than one would think at first glance. I would also not try to interpret some deeper sense into all that.

    Cheers,
    Ferdinand

  • RE: CUSTOMGUI_QUICKTAB trigger twice when click

    Hey @Gene,

    Thread-necromancy is often not so good, because it almost always derails the original topic and often also lacks in clarity. I also here do not understand what your concrete question is?

    When I click on the Quicktab, the first event returns True, while the second returns False.

    What do you mean by "the event returns true"? It is you, the developer, who returns the result for an event (or you do not handle it at all). Are you talking about something like BFM_ACTION_VALUE?

    If I drag over two entries on the Quicktab gadget (click on one entry, then drag to the next entry and let go of the mouse,) Command triggers three times, msg[c4d.BFM_ACTION_INDRAG] returns True the first two times and False for the last one. Also, the first entry returns True for its IsSelected() check on mouse down. After dragging, the the second entry's IsSelected() is True. Second entry's IsSelected() is also true when I let go of the mouse.

    I do not see any question here, so what is the goal?

    Regarding Command triggering twice, is it because of the mouse events?

    GeDialog.Command is just a convenience wrapper for GeDialog.Message events (most from the BFM_ACTION family). If you want the full picture, use Message. I struggle to see a tangible question which I could answer, what do you want to achieve?

    Yes, some controls fire multiple times in Command, it is impossible (and also somewhat futile) to reconstruct the reason for each of them. Someone thought at some point it would be convenient to forward this kind of event to Command for some feature in Cinema 4D.

    I am not familiar with the exact issue discussed in this topic, but at a glance, what Maxime wrote then looks a bit overkill with the hashing, I would just store the last selected element and be done with it. Alternatively you could design your code so that you do not tie any heavy logic to a tab being activated (which is IMHO not a great idea in general), so that you do not mind when such code runs multiple times.

    Cheers,
    Ferdinand

    class MyDialog (c4d.gui.GeDialog):
        ID_TAB_1: int = 10000
        ID_TAB_2: int = 10001
    
        IDS_TABS: tuple[int, ...] = (ID_TAB_1, ID_TAB_2)
    
        def __init__(self) -> None:
            self._activeTab: int = MyDialog.ID_TAB_1
    
        def Command(self, cid: int, msg: c4d.BaseContainer) -> bool:
            """
            """
            if cid == self._activeTab:
                return True
            elif cid in MyDialog.IDS_TABS:
                self._activeTab = cid
    
            if cid is MyDialog.ID_TAB_1:
                foo()
            elif cid is MyDialog.ID_TAB_2:
                bar()
    
            return True