Hi @mp5gosu,

I am sorry to inform you that we talked about the issue, implementing an overloaded version of BaseContainer::Sort, and decided that this is not something we want to do in the near future and probably also not at all.

Cheers,
Ferdinand

Hi @mp5gosu,

I can ask, but I doubt that this will added, because it is ultimately something that can be "fixed" relatively easily from the user side (see end of posting for example). The only meaningful explanation I can give is that BaseContainer.Sort was implemented for a very specific reason. BaseContainer is not really meant to be a replacement for a sortable collection data type.

Cheers,
Ferdinand

"""A little workaround for the somewhat odd BaseContainer sorting behavior.
"""

import c4d

def cleanSort(bc):
    """A little helper for BaseContainer.Sort().
    """
    # Sort the container.
    bc.Sort()
    # Get out when the IDs 0 and 1 are not of type string.
    if (bc.GetType(0) != c4d.DA_STRING or
        bc.GetType(1) != c4d.DA_STRING):
        return bc
    # Save the value of ID 1
    valIdOne = bc[1]
    # Remove the ID 1 and reinsert it in the "right" place.
    if bc.GetIndexId(0) == 1 and bc.RemoveIndex(0):
        bc.InsDataAfter(1, valIdOne, bc.GetDataPointer(0))
    return bc

def main():
    """
    """
    data = {3: "d", 1: "b", 2: "c", 0:"a"}
    bc = c4d.BaseContainer()
    for eid, value in data.items():
        bc.SetString(eid, value)

    print ("Before:")
    for eid, value in bc:
        print(f"id: {eid}, value:{value}")
    print ("")

    bc = cleanSort(bc)

    print ("After:")
    for eid, value in bc:
        print(f"id: {eid}, value:{value}")


if __name__=='__main__':
    main()

Hi @mp5gosu,

thank you for reaching out to us and thank you for pointing out this behaviour. However, this is not a bug, but an intentional feature which is linked to the fact the sub-menu titles will be stored under the ID 1 in a BaseContainer. Because of that the method will not be fixed and it is also very unlikely that we will update the documentation, as explaining the reason for this behaviour would require revealing more of the non-public API than we are currently comfortable with.

However, since this is an intentional behaviour, you can rely on the fact that this will only happen with the ID 1. I.e., when you place your BaseContainer IDs in the range [1, +MAX_INT32], the sort method should work like intended.

Thank you for your understanding,
Ferdinand

Hi @C4DS,

sorry, I was probably a bit cryptic when I talked about a "shift in design". The reason why I was so cryptic is that such design decisions formally fall out of the scope of support (see Forum Guidelines: Scope of Support). It is not because we are lazy, but such decisions often come with a certain vagueness and uncertainty which makes is either very hard or impossible to give reliable answers. So please take my following ideas with a grain of salt.

I would look at it from the standpoint of reducing complexity. The major problems seems to be the ambiguity of caches. One way to circumvent this could be moving from a SceneHook to a ObjectData plugin. The idea would be to write a thin wrapper around Cinema's SDS object. In GVO you could just collapse all the input objects into a single polygon object and then just return that collapsed object as a child of a SDS-object. In Draw you could then just evaluate this very simple cache of your object (the input would already be taken care of due to the collapsing), i.e. you could directly draw your vertex-to-vertex relations. This would of course come with a considerable amount of overhead due to the collapsing.

Another approach could be to try to introduce tags as markers which will allow the user to guide your plugin what is considered to be the original. I cannot say you anymore than this without doing it myself (which falls out of the scope of support). The small insight would be here that for humans that decision what is the "original" might often be trivial.

For the SDS/subdivision vertex-to-vertex relations: My first instinct was that Cinema's subdivisions do not change anything about the index order of the source vertices (i.e., the vertices object that is going to be subdivided) due to the unnecessary overhead that would be introduced by inserting the new topological connected points in the index neighborhood of an "old" vertex. A quick test seems to confirm that, both for the SDS object as well as the "subdivide" command. If you want more clarity on this subject, I would have to ask you to open a new topic on that, so that we can keep topics in a single subject order.

The selected vertices are all of index 8, the object in the middle was the source for the objects on the left and right.

Thank you for your understanding and cheers,
Ferdinand

Hi @blastframe,

thank you for reaching out to us. And again you are right, the documentation is here unfortunately also not the greatest. As a somewhat immediate fix, you could do this:

prevKey = curveY.FindPrevUnmuted(keyDict["nidx"] - 1)
nextKey = curveY.FindNextUnmuted(keyDict["nidx"] + 1)

I.e., you cannot include in the key index of the key you want to search from, because the logic here will be otherwise: "Well, the next/prev unmuted key to the passed key is the key itself, since it is a unmuted one). Which is being reflected in the argument description:

index (int) – The key index to start the search from: 0 <= idx < GetKeyCount()

but does not mesh very well with the method name. We are also going to fix also the documentation on this one (here including C++). And just for clarity, you can always iterate over the keys of a CCurve, i.e., just access them by their index:

for eid in range(curveY.GetKeyCount()):
    key = curveY.GetKey(eid)
    print(eid, key)

I am sorry, I understand your CCurve documentation experience was probably not the greatest, but we try to improve.

Thank you for your understanding,
Ferdinand

Hi @blastframe,

thank you for reaching out to us and for reporting these errors in the documentation. We will fix both the erroneously attributed short description of AddKey as well as the code example in an upcoming update of the C4D SDK Python docs.

Cheers and happy coding,
Ferdinand

Hi @blastframe,

thank you for reaching out to us. One built in solution you could use is CCurve.AddKeyAdaptTangent() instead of CCurve.AddKey(). It will allow you to insert a smoothly interpolated key between two other keys and the result will look something like the attached image. I also attached a modified github ctrack_create_keys_r13.py example at the end. You only have to read the snip parts, everything else is unchanged.

I hope this helps, if not, I would have to ask you to restate your goals.

Cheers,
Ferdinand

"""
Copyright: MAXON Computer GmbH
Author: Manuel MAGALHAES
Description:
    - Creates position Y tracks.
    - Adds two keyframes.
    - Sets their value and interpolation.
Class/method highlighted:
    - CKey.SetInterpolation()
    - CKey.SetKeyDefault()
Compatible:
    - Win / Mac
    - R13, R14 R15, R16, R17, R18, R19, R20, R21, S22, R23
"""

import c4d


def CreateKey(curve, time, value, interpolation):
    """
    Creates a Key on the given curve at the given time with a given value and with the given interpolation.
    :param curve: The Curve where to add the keyframe.
    :type curve: c4d.CCurve
    :param time: The time of the keyframe.
    :type time: c4d.BaseTime
    :param value: The value of the keyframe.
    :type value: float
    :param interpolation: The interpolation of the key along the curve.
    :type interpolation: c4d.CINTERPOLATION_XXX
    :return: They key and the index of the key in the CCurve.
    :rtype: tuple(c4d.Ckey, int)
    :raise MemoryError: If for some reason, it was not possible to create the key.
    """
    # Adds the key
    keyDict = curve.AddKey(time)

    # Checks if the key have been added
    if keyDict is None:
        raise MemoryError("Failed to create a key")

    # Retrieves the inserted key
    key = keyDict["key"]
    keyIndex = keyDict["nidx"]

    # Sets the value of the key
    key.SetValue(curve, value)

    # Mandatory: Fill the key with default settings
    curve.SetKeyDefault(doc, keyIndex)

    # Changes it's interpolation
    key.SetInterpolation(curve, interpolation)

    return key, keyIndex


def main():
    # Creates the object in memory
    obj = c4d.BaseObject(c4d.Ocube)

    # Creates the track in memory. Defined by it's DescID
    trackY = c4d.CTrack(obj, c4d.DescID(c4d.DescLevel(c4d.ID_BASEOBJECT_POSITION, c4d.DTYPE_VECTOR, 0),
                                        c4d.DescLevel(c4d.VECTOR_Y, c4d.DTYPE_REAL, 0)))

    # Gets curves for the track
    curveY = trackY.GetCurve()

    # Creates a key in the Y curve with value 0 at 0 frame with a spline interpolation
    keyA, keyAIndex = CreateKey(curveY, c4d.BaseTime(0), value=0, interpolation=c4d.CINTERPOLATION_SPLINE)

    # Retrieves time at frame 10
    keyBTime = c4d.BaseTime(10, doc.GetFps())

    # Creates another key in the Y curve with value 100 at 10 frame with a spline interpolation
    keyB, keyBIndex = CreateKey(curveY, keyBTime, value=100, interpolation=c4d.CINTERPOLATION_SPLINE)
    
    # --- snip ---
    
    # Add key in between the keys A and B.
    bt = c4d.BaseTime(5, doc.GetFps())
    curveY.AddKeyAdaptTangent(bt, True, True)
    
    # --- snip ---

    # Inserts the track containing the Y curve to the object
    obj.InsertTrackSorted(trackY)

    # Inserts the object in document
    doc.InsertObject(obj)

    # Pushes an update event to Cinema 4D
    c4d.EventAdd()


# Execute main()
if __name__ == '__main__':
    main()

Hi @Yaroslav,

yes, you are right, LineObject are not meant to be presented to the user directly, but are the underlying discrete geometry of a spline. In case you do not mind a little overhead, you can also use SendModelingCommand, specifically with MCOMMAND_CURRENTSTATETOOBJECT (link to example), to get "a linear version of the spline". The advantage here is that you do not have to worry so much about the details, but at the cost of a little bit of overhead.

Cheers,
Ferdinand

Hi @Yaroslav,

thank you for reaching out to us and thank you @mp5gosu for providing an answer.

However, and I might be mistaken here, I think this is not what @Yaroslav was asking for; feel free to correct me when I am wrong. Cinema's splines are all parametric, even the editable ones, so changing the interpolation type from SPLINEOBJECT_TYPE_BEZIER to SPLINEOBJECT_TYPE_LINEAR will give you something linear, but also a vastly different curve geometry (depending on the input).

To resample a spline in Python, you can use c4d.utils.SplineHelp, specifically SplineHelp.GetPosition(). Or you can use SplineHelp.GetLineObject() to get the underlying LineObject of a spline. In C++ you also have SplineObject::GetLineObject.

In case you are actually interested in changing the interpolation type of a spline object (and not resample it), then @mp5gosu did provide the correct answer for you.

Please also note that we require postings to be tagged with essential meta information regarding the OS, Cinema 4D version and programming environment for the question. You can read more about the tagging feature here.

Cheers,
Ferdinand

Hi @C4DS,

so we talked a bit about it and there is unfortunately no way to do this with built in functionalities of the SDK. I do not fully understand your solution in all detail, but you seem to have to come to the right conclusion that this will have its limits for array-like generators where the caches can get very complex. This ambiguity of what is then "original" is ultimately also why Cinema does/can not offer this functionality.

I cannot tell you anymore than that and depending on what you are trying to do, a general shift of design might be necessary when you run into major problems.

Cheers,
Ferdinand