Also, wanted to share the result of following the ideas in this thread on a parametric Cissoid object being deformed by a Twist modifier.

The green stars and blue circles indicate the deformed spline points/knot positions, respectively, and the magenta stars and orange circles indicate the pre-deformation spline points/knot positions, respectively. (Types of) Intermediate Points were set to Natural and Number was set to 4, resulting in about four times as many knots (circles) as spline points (stars), as can be seen from the image. You can see some of the effects of the Natural type on the rightmost vertically oriented curve at the bottom of the deformed Cissoid coming to its lowest point in the image. As a result of being relatively straight, it has a more sparse arrangement of spline points (and knots) than the more curved vertical portion immediately to its left.

The varying sizes of the circles/star point markers in the image are not due to perspective distortion, at least not in total, but rather due to them being scaled based on the distance of surrounding spline points and knots, respectively, so as to try to reduce collisions among the markers with respect to other markers of the same type (the null shape radii were multiplied by 40% of the smaller of the distances between a point and its surrounding points resulting in a tiny gap between markers of the same type, at least when viewed along the normal of any particular point):

Michael

@m_adam Hi Maxime, thanks for your detailed reply. I had a feeling that EventAdd() performed an asynchronous operation (i.e., placed an event on the event queue) and therefore it didn't matter, since control of the main thread would not be relinquished until both EndUndo() were called (regardless of sequence). However, as C4DS and you yourself pointed out, it makes more sense to call EndUndo() prior to EventAdd().

This is not only true from a safety perspective, but the calls to StartUndo() and EndUndo() can be wrapped in a Python Context Manager, along exception handling and cleanup to be done automatically and correctly when a scope is exited. If one is going to undo whatever operation in case of an error, anyways (e.g., as part of said exception handling), it makes sense to call c4d.EventAdd() after we know that the entire action was successfully performed.

I am going on the assumption that if my code performs some action inside of a StartUndo() / EndUndo() sequence, possibly consisting of multiple sub-actions and changes resulting in multiple AddUndo() calls, then sees mid-action that there is an and it cannot continue, and assuming the Start/End undo sequence is wrapped in a Python context manager class. Python will call EndUndo() on my behalf, as part of exiting the block governed by the context manager and then in the exception handler, I can perform an undo of the last action, undoing whatever sub-action did perform successfully (and added their AddUndo() pieces). Since this will hopefully leave everything in the same state that it was before the action was started, I am going to assume that there is no point in calling c4d.EventAdd() after the undo of the action is performed in my exception handler.

To summarize, here is an example scenario:

try:
    with MyUndoContextManager(doc) as undo_manager: # Calls StartUndo() as part of its Context Manager __enter__() method
        # undo_manager will make the calls to AddUndo() based on our actions
        DoSomethingAndCallAddUndoOnTheDoc(undo_manager);
        DoSomethingElseAndCallAddUndoOnTheDoc(undo_manager);

        DoOneLastThingAndCallAddUndoOnTheDoc(undo_manager); # Oh, oh, fails and throws exception
        # Note: EndUndo() will get called as part of the implicit call to MyUndoContextManager's __exit__() method
        #       which will automatically get called when we exit this block due to the exception being thrown
        c4d.EventAdd(); # This code will not get reached due to exception being thrown above
except:
        # An error occurred, get back to the initial state prior to the action
        # Undo whichever action sub-steps were performed successfully and AddUndo()s got called for, if any

        # Since the undo_manager object no longer exists, call DoUndo() on the doc object, directly
        doc.DoUndo()

        # Since, we reverted to the initial state before the action, there is no need to call c4d.EventAdd(), right?

(edited by Manuel : I splited this thread from this one)

@m_magalhaes said in Post Deformer Spline:

SplineToLineIndex

Hi Manuel,

I am not the one who asked the original question, but your find of the SplineToLineIndex() method in SplineHelp is a good one!

I must have look at SplineHelp's API over a dozen times and never noticed it was there. I thought one would have to traverse all of the LineObject's points and correlate them with points on its parent SplineObject based on position, in order to come up with the mapping from SplineObject point index to LineObject point index. So, this feature of SplineHelp is really valuable, since it offers this very mapping as part of the core Python API.

I guess this also implies that there is always a 1:1 correspondence between a point of a SplineObject (which represents one or more B-Splines via formulas) and a point of its underlying LineObject which represents a bunch of line segments connected together. I wasn't sure if this was always guaranteed to be the case.

Now, for a somewhat related question to what has already been discussed, while we are on the topic of SplineHelp, is there some top secret way to do the opposite of what the GetPointIndex() method of SplineHelp does, that is to get the offset (i.e., 0<=offset<=1.0) along a spline's LineObject that a particularLineObject` point idx is located at? This would also be really helpful.

Let's look at an example:

Say you create a Rectangle parametric spline object that has a width and a height of 100 cm, so basically a square. We'll set the Intermediate Points setting to None, so that the spline object and its line object have identical point counts (i.e., four, for the four points that make up the corners of the square). Now, let's say you perform a Make Editable operation to convert the (parametric) Rectangle into an editable closed spline object, consisting of one segment with four points. If you go into the Structure Manager, you can see that the points are indexed 0-3 (since, there are four of them) and you see their coordinates, as well.

These points are located, with regard to offset, at 0%, 25%, 50%, and 75% of the length of the spline (or offsets of 0.000, 0.250, 0.500, and 0.750), respectively, since our original parametric spline shape was a square. Since this is a closed spline, GetPointIndex() will return the (sentinel or logical) idx of 4 (i.e., the count of the number of points in that segment of the LineObject) if asked for the nearest point to 100% of the length of the spline.

Now, given for example the point at Index #1, so the second point of the spline's LineObject, which is obviously 25% of the distance along the spline as previously mentioned, what method could you use on the SplineObject, it's underlying LineObject, or 'SplineHelp' to get a 0.25 offset value from that LineObject point index of 1.

The GetPointIndex() member function of SplineHelp takes a (Spline space) offset value and a segment idx, and returns the closest LineObject point, by index, to that spline space offset value.

As described in the above example, how do you go in the opposite direction, from a LineObject point, by index, to an offset value along the LineObject in spline space?

I'd like to hear what the canonical way of doing the following sequence, is:

# Start a chain of undo actions
doc.StartUndo()

# ... Whatever actions that need undo and their associated calls to doc.AddUndo

# Call EventAdd() before ending the undo chain
c4d.EventAdd()

# ..., then end the undo chain
doc.EndUndo()

or:

# Start a chain of undo actions  
doc.StartUndo()   

# ... Whatever actions that need undo and their associated calls to doc.AddUndo()

# End the undo chain first
doc.EndUndo()

# ..., and then call c4d.EventAdd()
c4d.EventAdd()

In other words, should the call to c4d.EventAdd() come before or after the call to EndUndo() on the document object. I've seen code doing it both ways and am wondering if makes any difference or if there is some advantage to one of the two orderings of calls.

Let me be specific:

Extrude Inner Tool
In toolextrudeinner.res (resource\modules\model\description subdirectory of the main install location), in the MDATA_MAINGROUP group, the following line:
REAL MDATA_EXTRUDEINNER_SUBDIVISION { MIN 1; MINSLIDER 1; MAXSLIDER 10; CUSTOMGUI REALSLIDER; STEP 1;}
should read:
REAL MDATA_EXTRUDEINNER_SUBDIVISION { MIN 0; MINSLIDER 0; MAXSLIDER 10; CUSTOMGUI REALSLIDER; STEP 1;}

The correct MIN value for the Subdivision property of the Extrude Inner tool is 0 .

Also, toolextrudeinner.h documents the property as follows:

MDATA_EXTRUDEINNER_SUBDIVISION						= 2170, // LONG

Yet, in the actual tool dialog box, it's type is specified as a REAL . One (or both) of these is/are clearly wrong, it doesn't make much sense for the subdivision value to be either a FLOAT or a LONG, it should be an INT!

I should also add to this that if one was to start using the Extrude Inner tool and to drag the Subdivision property into the Python Console in C4D, they would see:

>>> ExtrudeInner[c4d.MDATA_EXTRUDEINNER_SUBDIVISION]
0

..., and if one was then to do the following to see what the actual underlying type is:

>>> type(ExtrudeInner[c4d.MDATA_EXTRUDEINNER_SUBDIVISION])
<type 'int'>

They would see that the actual type is the very type (int) that I suggested should appear in both the .res and .h files, above!

Note: The help documentation is also in error, regarding the Subdivision property of the Extrude Inner tool, listing its range as follows: Subdivision [1..+∞]
It specifies this and then goes on to present a diagram showing the perfectly valid examples of using values of zero (which is out of the range just documented, but perfectly valid as far as the actual tool is concerned) and two, as the text under the figure indicates:

Subdivision set to 0 and 2.

See the following section from which the example above was taken: Extrude Inner/Tool

The actual range in the help should be changed to: [0-+∞]

Fortunately, when the tool itself is employed, the Subdivision value does correctly default to zero, in contradiction to the Dialog's definition and constraints in the .res file, so I am not sure what is happening behind the scenes in the C4D source code which seems to correct things (at least as far as the tool goes).

However, the issue becomes apparent when tools try to use Extrude Inner functionality including its dialog groups (e.g., Py-Extrude Inner Modifier that is part of Py-Parametric Tools at Maxon Labs) and cannot change the Subdivision property to a value of zero, even though this is possible using the actual Inner Extrude tool that is part of C4D core functionality.

Please take a look at this and consider the fixes/changes described above.

@m_adam said in PolygonObject.SetSelectEdges() and the Neighbor() class, a giant dilemma:
...

Hope it answers your questions,
Cheers,
Maxime

Thank you Maxime, this is a lot of useful info. Let me think through all of this and reply here if I have any further issues.

@m_magalhaes said in Copying All Compatible Properties from One Object to Another?:

Hi,

as you may know, if the object's type were the same you could use CopyTo
But in your case, there's no builtin function do to it.

I've checked how it's done for external compositing programme and there's nothing helpfull.

Cheers,
Manuel

What about copying data from the BaseContainer of the source object to the destination object only if the ids in the source BaseContainer are relevant and/or are already present in the destination object's BaseContainer (i.e., copy only those key/value pairs that are applicable to the destination)?

@zipit said in PolygonObject.SetSelectEdges() and the Neighbor() class, a giant dilemma:

Hi,

edges are globally indexed by polygon_index * 4 + local edge_index (see PolygonObject.GetEdgeS), where the local edge index lies in the interval [0, 3]. So the edge between the points c and d of the polygon with the id 10 would have the index 43. You will have to pass edges in this form to SetSelectEdges, the function will then turn your partial edge selection into a full selection by selecting the corresponding global edge indices of polygons that share the selected edges.

You can also do the same by using the Neighbor class and do it manually by retrieving the polygons attached to an edge defined by two points.

Cheers,
zipit

The whole point of SetSelectedEdges is not to do the 4*PolygonIdx+PolygonEdgeIdx math and have to supply multiple physical edges where a single logical edge from Neighbor will suffice).

Please reread the below quoted portion of my post and especially the part I marked in bold:

SetSelectedEdges(self, e, pSel, ltype)

..., method takes a pSel argument of type BaseSelect.

The help for this method further tells us that:

The edges are indexed uniquely by a Neighbor object, so each
edge has a single index.

This tells us that we should not use the 4*PolygonIdx+PolygonEdgeIdx formula to specify the edge indices for the BaseSelect, but instead refer to the logical edge indices as determined and governed by the Neighbor object after it does its calculations. The problem and crux of the question is that we don't know what those edges are, since they don't seem to be accessible to code that is outside of the Neighbor object. This information seems to be encapsulated within the Neighbor's guts and hidden from the users of the object, making it inadequate for its intended role in this case: The selection of a subset of the logical edge indices from the Neighbor as required by the pSel argument of SetSelectedEdges().

My point with regard to which edge indexes to use is further driven home by the following sample code that appears in the help for BaseSelect.SelectAll() which shows the correct usage of the BaseSelect with the SetSelectedEdges() method and coincides completely with what I am asserting:

def main():
    nbr = c4d.utils.Neighbor()
    nbr.Init(op) # Initialize neighbor with a polygon object

    edges = c4d.BaseSelect()
    
    # Select all edges in the range [0, nbr.GetEdgeCount()-1]   
    edges.SelectAll(nbr.GetEdgeCount()-1) 

    # ### Dev Comments
    # ### ============
    # ### The preceding line clearly demonstrates that Neighbor based
    # ### logical indices should be used with the BaseSelect since
    # ### nbr.GetEdgeCount() returns the number of Neighbor deduced
    # ### logical edges and not the total number of (potential)
    # ### physical edges (i.e., which would be 4*num_polys), at least the
    # ### the way I understand it.

    # Select all edges from our edges selection
    op.SetSelectedEdges(nbr, edges, c4d.EDGESELECTIONTYPE_SELECTION) 
    c4d.EventAdd() # Update Cinema 4D

if __name__ == '__main__':
    main()

Note: The Dev Comments portion in the above code was added by me to point out what can be deduced from the line of significance in the sample code from the help documentation.

PolygonObject's

SetSelectedEdges(self, e, pSel, ltype)

..., method takes a pSel argument of type BaseSelect.

The help for this method further tells us that:

The edges are indexed uniquely by a Neighbor object, so each 
edge has a single index.

OK, makes sense so far. We use the edge index from the Neighbor object to identify an edge once, rather than N times where N is the number of polygons that share said edge.

But, in order to use a "logical" edge index from the Neighbor object, we need to be able to tell which edge and/or edges this logical edge maps to. Unfortunately, the Neighbor class offers no way to get the properties of the logical edge to physical edge mapping, that it stores internally, given a logical edge index.

There is only one method in the Neighbor class that has anything to do with the logical indexes that it stores, and that is Neighbor.GetEdgeCount(). This puts a cap on the number of logical edges, which are clearly indexed from 0 to Neighbor.GetEdgeCount() - 1.

But, how in the world does one get info about these logical edges (by logical edge index) in order to decide whether or not to use them with the PolygonObject.SetSelectedEdges() method, if the representation and properties of the logical edges are completely opaque to users of the c4d.utils.Neighbor class? There is not a single method in this class that gives the developer any information about which physical points, edges, or polygons a logical edge, as referred to by its edge index in the Neighbor class, represents.

Without any information and mapping to something physical and concrete, how can one refer to a "distinct logical edge" by its index within Neighbor and use that as the basis for forming the selection criteria inside a BaseSelect object as required by the pSel argument of the SetSelectedEdges() method of PolygonObject?

TL;DR: If I can't tell which actual edges the edge indices of a Neighbor object refer to, I can't make use of Neighbor edge indices for any operation that requires them.

Am I overlooking something, or is this API completely broken?