SharpEars

This is a classic case of knee/elbow joint overlap issues that can be solved by a combination of C4D bones and skin in combination with vertex weighting and the proper topology to allow for good realistic bends. There are a few youtube videos available that illustrate the technique.

I wonder if the Vonc gap selection works for any arbitrary contiguous polygon selection run (i.e., all selected polygons in the chain share one edge), regardless of the sequence of actual polygon indices within the selected polygon object. In other words, does it actually follow the chain of adjacent polygon selections from beginning to end (or from some starting point until it comes back around, for the case of a loop/cycle)? If it does do the above, does it handle forking selections properly, as well?

I understand the future trend with Scene Nodes, but they are: 1) A far lower construct and do not offer the same high-level functionality as XPresso presently offers (on a node for node basis) and 2) not yet tightly integrated with the rest of Cinema, and especially Object Manager. If only there was some way to embed them into an XPresso node, XGroup, or some other similar alternative to bring them into the nodal set that corresponds to a single XPresso tag, which I don't believe there is, they would be far more useful.

Here is a project with a replacement for the Matrix2Vector node as a Python based XPresso Node. Please take a look and play with it if you are interested: CustomVector2Matrix.c4d

Just wondering if there is any good website or other source to download and or purchase additional XPresso nodes, to add to the ones already included with Cinema 4D.

Let's show what happens due to this bug in a larger context. Say you are an adventurous chap and decide to use the XPresso Vector2Matrix node, in accordance with its documentation in the Cinema 4D Help, to control the alignment of a simple spline in the shape of an arrow (that initially has world alignment and is pointing up [i.e., in the direction of the positive Y Axis]). Judging from the bewildered look on your face when you saw the results, things did not quite turn out as planned (where "as planned" is defined in this case as a no-op with respect to re-alignment!): Note especially the direction of the Arrow object's X axis as compared to the world X axis, thanks to the assignment of a negative scaled combined with a 180 degree bank rotation, resulting from the aberrant matrix that was constructed from a simple Y Unit Vector by the Vector2Matrix XPresso node. Let's take a look at what the Help says for this node, shall we: Above is the current help text in which I highlighted the portion of particular relevance to the issue at hand. I suppose the node is doing what the documentation says - the Y Vector component of the Matrix is pointing in the correct direction. I take it that the added "benefits" of arbitrarily corrupting the X Vector of the Matrix to a value that "only its mother could love," to such an extreme in fact that our poor Attribute Manager is doing its best to make sense out of the ensuing mess by displaying a Y Scale value of -1 and a Bank angle of 180 ° (as pointed to by the hand drawn ᒋᘓᑯ ᙉᒋᒋᘮᗐᔑ in the second attached image), is par for the course?

If a simple Y Unit Vector goes through the Vector2Matrix transformation XPresso node, whose Function Node property is set to Y-Axis, the end result, as displayed by a Result node configured to display Matrix values, is quite surprisingly the following (with the seemingly erroneous member vector in question shown in red text): [ 0;0;0 | -1;0;0 | 0;1;0 | 0;0;1 ] The expected result is: [ 0;0;0 | 1;0;0 | 0;1;0 | 0;0;1 ] Attached is an image highlighting the issue in the context of other possible transformations. Please note that for all other cases, whether fundamental or where the input Unit Vector is transformed to the direction of an alternate Axis, there is never an inversion in sign. The seemingly incorrect sign is only present for the case marked in red:

Here is a screenshot of the latest souped-up XPresso (only, no Python) based version showing a more complex "Torus Knot (11,3)". In terms of enhancements, I've added additional functionality, automated pretty much everything, and added lots of helpful guides. I also fixed a few bugs/shortcoming in the prior version. The following image shows all available guides just as as showcase of features. Realistically, only a few of these would be enabled at any one time depending on what aspects are of interested and/or are being worked on in related scenery, so as not to add unnecessary clutter and complexity to the knot topology that is shown. (External image, click on it (and click once more, when the magnifying glass appears, afterwards) for a full-res version:

Taking the "Only use functionality that is already built into Cinema 4D" approach a step further with the aid of XPresso and specifically, without resorting to any Python code: (Link to sharp full resolution version)

What a coincidence, I also thought of the "helix along a circular spline idea" today, as well. I tried it out and it has some pros and some cons. I am still going to do this fully custom, as of right now (i.e., no helix spline, and no circle spline). Having said that, the helix along a curve does provide a good point for comparison for correctness checks of my implementation, once you get past the difficulty of converting arbitrary p and q knot values into the aforementioned conglomeration. Most certainly, that would be a job best suited for some serious (read, "sinister") XPresso! With regard to the plug-in, one of the overarching goals is to provide full Python source for users to be able to customize and modify it to their hearts' content, as well as to get an idea for how a somewhat complex plug-in is implemented in Python. Update: I've taken a look at your attached scene file and your approach in terms of a helix around a circle is very similar to mine (sans the Sweep and conversion of the parametric circle to an editable spline), but I am sure you did that just to add thickness to the knot for visibility. Also, I saw how you tried to play with the tangent handles to get the "corners" to be more sharp, that was an interesting idea, but I believe the solution to match Spiros, is to modify the parametric formula, with the big question being of course, "What modifications should I make to get the generated knot to match?" BTW, your ideas have most certainly not derailed me. If anything, they have given me additional tangential ideas for future consideration, so keep 'em coming 🙂 . This is the current updated generator properties UI, but I still have to implement a lot of this and I've set the generated spline type to always be Bezier, for the time being:

Not bad, and with the ornate shapes, I suppose you could send them through the remesher and/or volume builder (or both) to reduce the polygon count.

Is the topology of the shapes quad based or "hacked together" and imported from solids modeling application like Fusion360?

How in the world is the guy who wrote the Spiros plugin getting a knot like this. The curves of the knot seem to go around the circle of the virtual torus corresponding to its Major Radius (i.e., the large imaginary circle that can be drawn approximately around the star shaped knot's points, of the knot shown below) in non-uniform angular steps, with seemingly smaller angular steps near the circle's circumference (i.e., near the knot's points and farthest from the knot's center, as pointed to by a yellow arrow in the image) and much larger angular steps away from the circle's circumference (i.e., closer to the knot's center with, as pointed to by a cyan arrow), where the curves become almost flat and linear. There is some mathematical trickery here:

All of the knots at the top of your post are already possible, because the Trefoil and the other ones mentioned are torus-knots: The values of p and q can be specified independently, but there is of course a mathematical relationship between them when used to form the knot. So, in answer to your question, no, one is not a function of the other - they are both independent input parameters. With regard to the SLICE parameters (not yet implemented), the idea was to create a cut of the knot between two angles, or more formally based on the "to be written" descriptive help: Slice Start and End Angles Allow the user to restrict the generation of the knot to only the portion that is contained within the volume of a right circular cylindrical sector with: - Angle 𝛳, defined to be the absolute value of the difference between the angles specified and oriented accordingly - Its axis made coincident with the axis of the virtual torus around which the knot is circumscribed - An unbounded radius (or more specifically, a radius that is no smaller than the sum of the major and minor radii of the virtual torus [i.e., the distance from the central point of the torus along its axis to any of the equidistant points along its surface where the points lie at the farthest possible distance, radially from its center on the toric section formed by an imaginary equatorial plane used to bisect the torus]). Or, in layman's terms, it allows for the creation of an arbitrary pizza-pie slice portion of the knot, just as it does for some of the built in parametric spline/polygonal shapes. Also, thanks for the links to the Spiros plug-in. I can use that for ideas of what other features to add.

Ah, yes, good catch! I'll fix that of course. I have a few more ideas, before I put it up here in an "alpha" version: - Add the various Bezier/B-Spline/Cubic curvature interpolations (aka, the various forms of soft interpolation). At the moment, it's a single segment closed Spline Object with interpolation set to Linear and composed of joined straight line segments that are relatively uniform in length, forming the knot that is generated based on the settings. That means that one has to use a pretty high line segment count, especially for complex knots, in order not to see the corners formed at the points where consecutive line segments connect with each other (i.e., small line segment counts can lead to very sharp corners, just like one would see when the specified number of intermediate points is too small [for uniform and natural interpolation] or large angles are used [for adaptive interpolation], while modeling with the various built in Cinema 4D Spline based parametric shapes). - Add some popular built-in torus-knot types to allow for quick generation of the most common knot forms. - Add useful help and tips: - A clear, minimal math explanation of what p and q represent and the role they play in the form of the overall knot. - The importance of co-primality between the values of p and q, and the issues that can arise when this gets violated. - A warning when the user selects less than ideal p and q values, explaining exactly what is mathematically wrong with them, in layman's terms, with as little (advanced) math as possible, allowing the user to make corrections to the values and hopefully achieve the topological result they are looking for. - A minimal guide to the parametric equations in R3 that produce the knot itself, in case people want to make changes to them for whatever reason, possibly to create some custom variation of or modification to the torus-knot spline point geometry/topology.

My Torus Knot generator that I hope to upload to the Core 4D site, when complete. It is Python based and the Python source code will be made available and fully commented when uploaded here. If you can think of any other useful attributes, please feel free to chime in and I will consider them for the plug-in (depending on implementation difficulty, of course). Progress so far:

I think the key to accomplishing something like this is to treat each piece of similar geometry as a clone of some template master object, possibly with minor procedural mutations that can be calculated very quickly and/or baked. That way, you have variation, but only need to store a large number of objects as instances of a master object rather than a full on triangulated geometrical data set.

I am glad to help and there is no need to offer payment. I take joy in the fact that I've helped you with your issue and that the advice and steps above, with regard to axis movement, may be of help to others who search for this topic, while experiencing similar axis movement related issues. I only wish that one day, a Wiki site will be created where detailed tip steps can get consolidated into a single cohesive, hierarchical structure perhaps even on this site. Maxon can do a great service to its customers by creating a Wiki that allows for 3rd party contributions with regard to documentation/help and by opening up its GitHub examples for additions by 3rd party contributors. For the time being, this web site and its forums is all we've got for comprehensive Cinema 4D help, advice, and instruction.

If I understood correctly, the issue you are describing is that when your objects are children of a Null Object and you use the View Center command on said Null Object, the axis of the Null Object gets repositioned, but its children get left behind at their original locations. If that is the case, let me offer a trick that few are aware of that can be used to overcome this issue, described more generally, as follows: Performing axis repositioning commands on a parent Null Object will move the Null Object (axis) but leave its descendants at their original positions, rather than follow the Null Object to its new position. In other words, the move operation on the Null Object's axis does not correspondingly cascade to its descendants as is perhaps expected. Problem Description and Solution Initial State You have a hierarchy of objects inside of a Null Object, with the axis of the Null Object located somewhere in the neighborhood of the center of the group or some other convenient location that makes sense for the object grouped by it. Normal Behavior When you use the Move Tool to move the Null Object, its descendants follow it. Desired Behavior Perform an "axis operation" on a grouping Null Object that results in the repositioning of its descendants in a manner identical to the repositioning of the Null Object group, as a single atomic unit, afforded by the Move Tool. Issues Encountered 1. Axis operations move the Null Object but do not accordingly reposition its descendants. 2. If there is more than one child under the Null Object, selecting the descendants and using the Center to Parent command does not produce the desired outcome. It causes each descendant to individually get centered to the parent Null Object, rather than all of the selected Descendants to move in tandem as a group. An important aside regarding Issue #2. If you wind up in this predicament (i.e., that your objects lost their placement with respect to each other because you tried to perform a multi-child-object Center to Parent operation or some other related command), I recommend that you revert the undesired behavior using several Undo Action commands (i.e., Shift+z) and not the usual Undo command (i.e., Ctrl+z), or you may get into an unrecoverable historic state that loses the initial placement of the child objects with respect to each other or with respect to the parent Null Object. The Steps to Resolve the Issues, in Detail Select the direct children of your Null Object and group them, creating a new direct parent Null Object for them which will be the only child of the original Null Object that was their original parent. I realize that the preceding is confusing, so let me break this step up and illustrate. a. The initial state showing two polygonal objects grouped inside of a Null Object, with the polygonal objects selected: b. Create a new parent Null Object for the selected polygonal objects. This can be accomplished by holding down Ctrl+Shift+Alt while clicking on the Add Null Object button (this button looks like a large Null Object icon and is normally found on the vertical toolbar that is directly to the left of the Object Manager). The resulting hierarchy should look as is shown in the following image: To avoid any ambiguity for subsequent steps, Let's rename the newly create Null Object to Temporary Null: Select (only) the Original Object Parent Null and reposition its axis, using an axis repositioning command (e.g., View Center). This will cause the axis of the Original Object Parent Null to move, but the Temporary Null we created in the previous step will remain at its original position, thus preserving both it and the original placement of its children in preparation for the next step. At the end of this step, the Original Object Parent Null will be the currently active object (i.e., the only object that is selected) per the initial selection in this step: Select (only) the Temporary Null we created, bringing the state of the Object Manager hierarchy selection state back to what is shown in the image at the bottom of Step #1. Note that the axis that is displayed in the viewport with the Temporary Null Object selected, should be positioned at the initial position of the Original Object Parent Null., before its axis was moved via Step #3. Ensure that the Object Manager selection state at the completion of this step is as shown in the following image: We will now reposition the Temporary Null and, more importantly, its descendants in relation to it, to the new location of our Original Object Parent Null. To do this, we will use the Center to Parent command which will now produce the desired behavior - move the children of the Temporary Null, as a(n atomic) group, to the new location of the Original Object Parent Null, while ensuring that the placement of the children with respect to each other is retained, contemporaneously (a nice new word to add to your vocabulary). The result of this operation is our desired outcome: To move the Original Object Parent Null object's axis to a new location and have its children follow it to its new destination, while retaining their relative positions within the group. Delete the Temporary Null object, it is no longer needed. To do this, right click on it to bring up a Context Menu and use the Delete Without Children command found about three-quarters of the way down the menu: This will revert our Object Manager hierarchy to its original state, except that the Original Object Parent Null will be the active object: We have now reached our desired outcome. The Original Object Parent Null as well as its children have been moved together to a new location using an axis operation on the Null Object. Summary A temporary Null Object was created and used to overcome the issues encountered when performing repositioning operations on a grouping Null Object that are restricted to its axis. Unfortunately, such operations come with the limitation that they reposition the grouping Null Object itself and do not result in an oft-expected corresponding accompanying movement of its descendants, as an atomic group (i.e., preserving their relative positions with respect to each other), in-tandem with their parent. I hope that the detailed procedure above will be of help to you as well as others that run into similar issues.

1. Select the object to position at the currently focused Viewport's center. 2. (Option a - recommended). Press Shift-C to open the Commander. Type View Center into the Commander's edit box, followed by the Enter key, in order to execute the command. The following image depicts what should be displayed in the Commander right before you press the Enter key to execute: or (Option b - for Cinema 4D beginners). From the Cinema 4D Main Menu, use the Tools -> Axis -> View Center command to perform the desired operation: The resulting outcome of the above steps is that your object should get repositioned to the currently focused Viewport's center. More precisely, it is the axis of your object that will be used to position it at said center. If your object's axis happens to lie in the middle of the object (i.e., the middle of its points), which is true for many, but not all objects, then your object itself should be positioned at the current viewport's center. If not, you may need to either adjust the object's axis independently of its points or vice versa, which is a separate question/topic (helpful tip: with the object selected in Model mode, use either the Center Axis to or the Center Object to command, respectively. Use the image above to assist you in finding these commands on the menu, if you have trouble locating them). Then reposition the (axis adjusted) object once again at the view center using the aforementioned steps or further manually tweak its position to your heart's content. Additional note: The View Center command does not change the object's rotation or scale. It is only useful for altering an object's position (assuming that the object is not already at the view center). Primarily, this command is used to bring a "run away object," as is often the case upon initial object creation (but also after pasting from a different scene, as is the case for your particular scenario), to the center of the Viewport, making both it and its axis tool visible. This makes it easier to further refine the object's position within the confines of the vantage point offered by the currently focused Viewport. I am hopeful that the detailed answer I've provided above is "idiot proof."

Yes, with Thea render dropping support, Indigo development very spotty at best, and Maxwell, who knows where that is headed and it is no match for Thea or Indigo, Luxcore is pretty much the last remaining truly unbiased renderer that can do proper caustics and physically based materials justice. There is one other purportedly unbiased renderer that support Cinema, whose name I won't mention, but it is so buggy that I am surprised any professional uses it.

This thread is a great idea. I would suggest that you place it on GitHub or on an editable Wiki, so that others can contribute.

Why not just assign the objects to be hidden to a new "Hidden Objects" layer that hides them from the Object Manager? For objects already assigned a layer, a new "Hidden Objects" layer could be created as a child of the currently assigned layer, if not already present, and this layer would inherit all of the attributes of its parent (except for OM visibility, of course). Then if you want to show them again, you can reassign them "up a layer" to wherever they were previously (i.e., no layer assigned or the parent of the "Hidden Objects" layer, respectively).

More items to consider for this thread: - Optimize 1.0 (I'd give the current optimize, v. 0.1-alpha) - Weld tool 1.0 (I'd give the current one maybe v. 0.5, given what we have today when there is a need to weld multiple points to multiple other points) - The forever dreaded snap functionality - Cloner 2.0, with more dynamism in the clones than just having to make do with an RGB color that can be assigned to them and with which the can have at least some semblance of dynamic changes, that make them differ from the original objects being cloned and each other. Access to the clone index from each clone (since it is known at the time that the geometry cache gets built) would also be of value.

Wow, that's a great find. Those really should get ported over to Python and I am hopeful that their original author would not mind such a conversion. Also, it would be nice if the source for the plugins mentioned in this thread would be placed in the Maxon github repository for Cinema 4D, so that other can learn from the steps used to implement them.