SharpEars

This is just awesome! I'd give you 1,000 likes if I could. I have thought about creating something like this for a long time, but as you can imagine it would be a complex beast to tackle, perhaps even 10/10 in the difficulty department, with all of the things you've thrown in above (plus all of the "secret" features built into measure and construct that most people don't even know exist).

Was there a partial point select present, when you tried to optimize? You must either have no points selected or all points selected (or minimally all of the points you want to optimize should be selected, if any selections are present) for optimize to correctly perform its function.

You are correct, the impossibility of dropping a point inside a quad or even allowing for the (perhaps temporary) addition of a single edge that is only connected to one side of a quad (and not two) and whose other point lands, for example, in the center of the quad, even if that means that the quad is no longer a quad and temporarily becomes part of a non-convex ngon with a shared side, makes the entire process of making arbitrary cuts very onerous. That was quite a complex explanation, so let me present a simple example. As shown in the following image, a Plane Object with 2x2 subdivisions has been made editable. Subsequently, the edges labeled c and d were removed (using the Melt command), leaving an ngon as a result and the representation shown, with ngon lines made visible. (Note, further details continue below image...) With the geometry in the above image as the starting point, neither the edge labeled a nor the edge labeled b can be removed in isolation - without, as a necessary side-effect, also causing the removal of the other inner edge (i.e., removing edge a would result in the automatic removal of edge b and vice-versa). Removal of either edge using the Melt command would leave us with the geometry shown below, now devoid of any inner edges. Note: For the remainder of the discussion, we can continue to use the above image, pretending that the leftover points that bisect the rectangle's edges and the corresponding ngon lines they create, are no longer present leaving just a simple rectangular quad with four sides and four points as its corners. It's a square, actually, but that aspect doesn't matter, since the following applies to properly formed convex quads, in general. If we want to add an inner edge to the quad, we must place both of the edge's endpoints on the edges that make up the rectangle's sides. To be more precise, any single edge that is added must connect two sides of the quad, and cannot have one or both of its points be positioned anywhere else, and more specifically, anywhere in the quad's interior. If an interior endpoint is desired for the edge, a second edge would need to be added that would connect this interior point to one of the polygon's sides, as was the case in the original image with the two edges a and bh, forming, as a result, an interior quad and causing the original quad shape as a whole to once again become an ngon. This inability to remove only one of edges a or b , while leaving the other edge intact, is one of the limitations of Cinema 4D that makes arbitrary cuts impossible.

Since a good explanation would take some time, let me provide you for the time being, a direct solution to your problem, while also answering some of your questions: If I understood correctly, you want to take a spline with Type set to "Bezier" and Intermediate Points set to "Uniform" and use those uniform intermediate points to drive the position of an Align To Spline tag (or more specifically get the position values for the intermediate points, as percentages along the interpolated spline). If this is the desired behavior, you can do the following: 1. Select your original Spline Object, which I will henceforth refer to as the Original Spline. 2. Do a Current State to Object operation on it. This should place a new spline object right below your current one with the same name as the original spline. 3. To avoid confusion going forward, rename this newly created spline to "Interpolated Spline" and I will refer to it as the Interpolated Spline going in the following steps. 4. If you click on the Interpolated Spline to select it, you will see that the Type attribute has been set to "Linear" and that the Intermediate Points attribute has been set to "Adaptive". You can change the Intermediate Points to "None", since for a linear spline, there are no interpolated points. Now, let me explain what we have done, above. We have created a new spline, that is a copy of the old spline with the following differences: Original Spline - composed of a mathematical representation describing its curves, combined with an interpolation of that mathematical representation based on your interpolation settings (e.g., "Bezier", "Uniform", and some number of intermediate points you've entered). Interpolated Spline - composed of straight line segments representing the Line Object that was used to back your Original Spline's mathematical representation 5. Use the Interpolated Spline rather than the Original Spline to drive your Align To Spline tag(s). You can hide the Interpolated Spline object from the Viewport, since the Original Spline is already visible (otherwise you will have one spline on top of another). However, do not disable the Interpolated Spline by clicking on the green checkmark next to it to change it to a red x, or you will not be able to use it as a source for any operation. 6. By attaching your Align to Spline tag to the Interpolated Spline, instead of the Original Spline, you will be able to use the expresso node layout on the previous page to get the positions as percentage locations of all of the points. Likewise, the Align to Spline tag will correctly track your Interpolated Spline, as you see it on the screen (and on the screen when in Modeling Mode it should look identical to the Original Spline), rather than track the mathematical representation of your Original Spline, which you can see by selecting the Original Spline and entering Point Mode. I hope this is helpful, has resolved your issues, and answered at least some of your questions in the process. Take-aways: 1. The Align to Spline tag tracks the mathematical representation of the Source Spline object that is specified as the tag's Spline Path. Setting the source original spline's Intermediate Points value to "Uniform" allows for smoother more uniform (i.e., less jumpy) motion between (mathematical) spline points, but does not otherwise change the spline representation that is being tracked by the tag. Another way to phrase the above is that the Align to Spline tag does not track what you see in the viewport in Modeling Mode. This view is the interpolated representation of your spline. Instead, it tracks the "perfect" mathematical representation of the curvature of your spline, as it would be presented to you by Cinema 4D while in Point Mode (i.e., the viewport representation showing your spline's actual mathematical point positions and any tangent handles associated with them, which are displayed for the points of the spline that are in a selected state). 2. In order to track uniform interpolated points, you need to create a new Spline Object with Type set to "Linear", that represents the Line Object backing the mathematical representation of your "Bezier" (or other type of mathematically based) spline. 3. The aforementioned Line Object based spline can be generated by performing a Current State to Object operation on the original mathematical spline. It's Type will automatically be set to "Linear" and it, rather than the original spline, can be used to drive an Align to Spline tag with the expected behavior of a uniform spline. Bonus Take-Away: 4. When a Cloner or a Matrix object is set to "Object" Mode and the Distribution is set to "Vertex", it is the vertices of the underlying Line Object that get used and not the vertices of the mathematical Spline Object. In other words, with regard to the points used for placement, these generators do the "opposite" of what the Align to Spline tag does in the context of the above discussion.

I think what you are suggesting here can only be done by converting an odd number of cuts into an even number by doubling the number of divisions and then removing the excess geometry. For example, to do a radial cut with five parts, you would do a radial cut with ten parts using properly oriented plane cuts. Then you would remove the extra edges/points after the cuts are made, to reduce the number of cuts back to five. I can think of no other way, due to how C4D handles ngons. other than to recreate the geometry (being cut) from scratch with the odd number of cuts already in place.

Patience, an explanation is forthcoming (the slight amount of blurriness, is temporary)...

It seems to me that given that the Spline Pen has other fine tuning features like: - Edit Tangents Mode - Lock Tangent Rotation - Lock Tangent Length ..., it would make a lot of sense to add: - Maintain tangent length ratios ..., to those, going forward, to fit the scenario I described - a scenario which is frequently desired.

When using the Spline Pen to move a tangent handle of a single point of a spline, there does not appear to be any way to keep the ratio of the lengths of the two tangent halves constant. That is, there is no way to change the length of either half-tangent and have that change automatically be applied to the other half (even for unbroken tangents and perfectly symmetrical (linear) tangents with equivalent half-tangent lengths). For example: You have a point with two (unbroken) tangent handles of equal length. You want the length of the tangent handles to remain equal as you use the Spline Pen to change the length of either the "left" or the "right" half of the tangent, by dragging its respective tangent handle away from or towards the point of the spline it controls. Other ways to accomplish this: Resorting to the general Move Tool, on the other hand, does offer this functionality, perhaps even to excess! It allows you to do all kinds of things with the tangent handles while ensuring that the ratio between the lengths of the respective tangent halves remains constant. In fact, the length ratio between the two tangent halves is maintained regardless of whether the tangent halves are of the same length, different lengths (e.g., a 2:1 length ratio), and even when the tangent has been broken (i.e., its halves are at different angles with respect to each other [and possibly different lengths, as well], such as when the spline has a sharp corner at a particular point). I can find no way to get this functionality with the Spline Pen. When it is used to adjust the length one half of a tangent, the length of the other half is never changed. This lack of functionality forces one to switch between the Spline Pen and the Move Tool when editing spline points, if the length ratio should be maintained during tangent adjustment. More often than not, one just wants the two tangent halves of a simple linear tangent (i.e., an unbroken one) to maintain identical lengths as either tangent half is lengthened or shortened via its respective handle. Perhaps someone knows of a top secret way to get this functionality with the Spline Pen?

On the topic of the removal of additional clutter (workplane, axes, horizon, etc.), I would certainly agree if they obscure the material presented or lead to confusion.

There is a way to do this correctly, but involves Python, understanding the LineObject behind the Spline used for the SplineTag, etc. It is quite complex, unfortunately, and poorly (where poorly should be interpreted as, "not at all") documented. Perhaps I can make a tutorial explaining the finer points, since this seems to be a question that many modellers have struggled with over the decades, given how obfuscated the whole thing seems to be. I.e., What the heck does the "Position" as a "percentage" in the spline tag mean and how do I get the percentage "Positions" of actual points along the spline (actually these would be points of the underlying LineObject, more would be explained in the tutorial) to use as values for the Position? Is this sort of tutorial of advanced spline topics something of interest?

Tags: Contrast Level of Importance: 8/10 When showing a polygonal geometry with wires, it is not at all helpful if the wires cannot be seen. This is best illustrated via an example that is intended to show the edges of a simple cube, when using a 4x4x4 segment scheme: I purposely saved this image as a medium quality JPG, in order to further convey the topic being discussed, since on-line training videos are heavily compressed using similar lossy compression techniques. Can you clearly see the wires on the right side and bottom sides of this cube? No? Why not? The answer is obvious: The wires lack contrast with respect to the polygons/faces they are a part of. When a presenter shows enables the display of wires, but said wires have very little contrast with respect to the face to which they belong, little to no explanatory information gets conveyed. Present/future watchers of the video/stream, who are possibly viewing it on phones, tablets, TVs, computers, etc., simply cannot be expected to make out or possibly even see the wires/edges. The problem is at its worst when the role that the wires play and/or their layout is part of the very topic being presented. How can the lack of contrast be addressed? Let me show some examples: 1. (Good) Use a much darker shade of gray as the Project/Display Color: 2. (Better) In addition, instead of using the default Gouraud Shading (Lines), set the Viewport to use Constant Shading (Lines) as its Display Shading mode, allowing for the edges to be highly visible, regardless of the position of the camera with respect to the object (i.e., lighting/shading no longer comes into play as the view camera is moved around - all vantage points are equivalent with regard to shading): 3. (Best) Alternatively, use a slightly lighter and more colorful (default object) Project/Display Color, combined with a very dark Preferences/Viewport/Background, and a significantly lighter custom Preferences/Viewport/Edges color, presented using the Constant Shading (Lines) Display Shading mode of the Viewport. This will make the edges of the object clearly visible and the topology being illustrated much easier to grasp: I am hopeful that the above illustrations or something along their lines (pun intended), will help guide educators when making future educational videos with regard to how topology, edge flow, and/or edge layout get presented to the viewers. I will close with an important tangential side-note on a similar matter: It is perhaps an even greater faux pas to discuss the topology of an object, while using a display mode that does not show the points, edges, or polygons being discussed.

After receiving more than a handful of likes on a previous post I made on the various shortcomings of how educational material is presented, I decided to start a fresh stand-alone thread on this very topic. In replies to this thread, I will try to post specific, stand-alone examples of mistakes I see made in training videos/presentations on Cinema 4D. In order to be constructive, I will then offer my thoughts on how the issue(s) can be addressed combined with specific examples that illustrate how they can be corrected in future presentations. Others are of course welcome to chime in with their opinions on the ideas presented. I hope that present/future C4D educators will receive helpful guidance from these posts and take these items to heart while making future presentations.

Only for changes to the graph itself, not the inputs to the graph. If the structure changes a recompile of at least what changed would be necessary (and possibly structuring related dependencies of those changes as well). This is another reason that modularization of the hierarchy is so important (i.e., to break up parts of a complex graph into components), with a good amount of isolation and few dependencies between modules (with regard to structure, not data - data flow dependencies are always present, as they should be).

On the scene nodes/capsules topic, the biggest problem I see is that they are being abused in the sense that people create these completely uninterpretable monstrosities out of them, not because there is a flaw in scene nodes themselves or because they are a very low level toolset, but rather, just as with the deficiency found in most programs written by professional programmers, people just don't understand the following simple concept: As something gets more complex, you need to add meaningful names, create levels of abstraction, componentize (with further meaningful naming of entire assemblies of sub-components), layer (to allow for viewing of a subset in isolation), and in the end present multiple "vantage points," containing various levels of details and subsets of objects, from which the entirety of a scene can be viewed. This is not an issue that was introduced with scene nodes, it existed with xpresso and modeling in general. But, as items that are more complex, dynamic, and low-level get added, the problem becomes greatly exacerbated. To use an illustrative analogy, no auto-mechanic open a car service manual to find a single diagram containing every nut, bolt, part, and assembly that makes up the car. They wouldn't be able to find a thing or even comprehend the image as a whole - it is just too complex to be taken in by a human being. Furthermore, illustrations that are present don't show every screw, regardless of length, diameter, type, or use, as just: screw, screw.1, screw.2, screw.3, screw.N, making any similarities and differences between their various characteristics completely undecipherable. Instead, illustrations of various systems of the automobile are divided by subsystem, and even then, there are various levels of detail shown to make the diagrams both comprehensible and cohesive (i.e., limited to the function/component being depicted). Even at the highest level of detail, perhaps showing individual screws, said screws are labeled with meaningful identifiers or group labels and perhaps even given a context in order to help convey the role they play as part of a greater whole. This is the very thing that most modelers who create large scene node graphs seem to completely lack. I see very few (if any at all!) counter-examples to this. It's hard enough to find scene files where people actually label objects properly and use layers, often skimping on these barest of necessities, and leaving things named as they were originally by Cinema 4D when their testing/hacking ultimately evolved into a final scene. Even with all of the "smarts" in its engine, Cinema 4D could not possibly know the semantic meaning and role of every particular piece of geometry or group of geometries and come up with a meaningful label to (re)name it. We wind up with scenes containing sheer stupidity like Cube, Cube.1, Cube.2, Cylinder, Cylinder.1, and when grouping at the very least is attempted, we have Null, Null.1, Null.2, etc. I am not referring to test scenes made by someone who just started to learn Cinema 4D and perhaps polygonal modeling in general. These are scenes made by professionals and educators, across the board. How in the world can one make sense of such a scene, even if referring to the very person that created the scene, some six months down the road? Is it that difficult to label things when they are created, or if uncertain due to experimentation, to go back once things settle and (re)label them with meaningful names more descriptive of their final roles? Is it that hard to assign layers to parts of a scene to allow it to easily be viewed in meaningful cross-sections, representing subsets of the whole, rather than having to view every little thing with every last detail, all of the time? I am not only addressing this at modelers, but, even more so, at training presenters/professionals on Maxon's own YouTube channels, the very people who should be imparting these concepts on the more novice viewers, but instead are making the very same mistakes mentioned above and teaching "all the wrong things," as perhaps an unintended side-effect, indirectly affirming or conveying that this is standard practice for modelers. Here is an example from the Maxon Training channel of the very thing I am talking about, at least with regard to the naming portion, screen captured from Quick Tip #48 (with a small amount of sharpening, because it was a bit blurry having originated from a YouTube video screenshot): Take a look at the Object Manager in the right third of the scene, above. How can one possibly hope to make heads or tails out of those names with regard to the function they serve or the role they play? There are at least three critical flaws here that I would like to describe in greater detail: 1. The names are generic and completely non-descriptive of the semantics of each operation. Even worse for the case of this particular scene is that names are repeated, even though said names are highly ordering dependent (with respect to operations above and below them) and therefore, the operations they perform be completely different, depending on where they appear in the list (i.e., ordering). 2. The list is flat (i.e., linear) and not hierarchical, which combined with the naming makes it completely impossible to ascertain which items, when combined as a logical group, perform a particular higher level task. 3. There was no attempt to modularize and/or componentize, to present the above in the Object Manager using higher level functionality that the user could then drill down into, piece-meal, in order to see how a particular task was accomplished in terms of its underlying lower level node operations, in isolation (think of soloing a small group, rather than viewing the entire scene as a whole). Naming is important, levels of detail are important, organization is important, modularization/componentization is important, layering subsets is important, reuse (of the same object via instances/cloner/etc.) is important, and many more similar topics should really be stressed, taught, and engrained on junior modelers from the get-go, and this advice is even more applicable to presentations made by professionals for purposes of education. Just my two cents...

What about radial symmetry helpers. This is something that is needed so often! Rectangular (cubic?) symmetry is well and good, but many things that are modeled are cylindrical in nature and tooling for radial symmetry would be greatly appreciated. I am talking helpers well beyond just sticking things into a MoGraph Cloner or using a bunch of rotated MoGraph instances to help with this task.

Are there at least Release Notes for R25.117?

Or they want to fix the other dup bugs that have been found in addition to the ones fixed, and release a .116 (?) hotfix.

It would be nice if they updated their release notes when they push out an update! Or, is Twitter the new place for release notes?

News of a R25.115 is appearing. Was there a silent update and/or hotfix beyond R25.113 (i.e., SP1) and if so, what changed? It's not on Maxon's site, anywhere.

Epic list of fixes, indeed! About damn time, too, given the number of bugs in this release.

When a parametric object is placed into a Null, its matrix is in the context of it's parents matrix. How can the parent Null be moved without moving the child object. That is to say, calling Null.SetMg() not only changes the position of the Null, but moves its child/children along with it. What should be used to move the location of only the Null itself, without affecting its children. This would be similar to repositioning the Null tripod with "Enable Axis" (i.e. the L icon on the left enabled, to only affect the Axis of the object) turned on.

Hey Cairyn, a bit off topic, but they made a product with your picture on it: https://moho.lostmarble.com/

I just watched the Youtube video and it looks like it's just a basic camera rig created with XPresso. Or am I wrong and it has some great hidden features you're using?

Let's not forget the seeming abandonment of AMD's ProRender as a viable alternative for production rendering. Or, am I wrong on this point?

Now that is truly awesome - very glad to hear that! Rather than making the new Scene Node stuff completely isolated from all other existing C4D functionality, which I thought was the case, this capability allows for a smooth transition, since they can be used as sort of parametric and/or generated templates from which regular editable geometry can be made. If any features of C4D (e.g., fields, etc...) are needed that are not yet available for Scene Nodes, they could be (frozen and) converted to editable polys for that use-case and functionality, just like is done for other parametric geometry and generators/modifiers. This allows for a much smoother and more integrated transition of existing C4D functionality to the Scene Node system, as it gets further refined and more functionality is added to it. I guess from a wishlist perspective, I don't know if there are any changes related to Boolean in the new core, but I am very hopeful that new Boolean capability gets added sooner rather than later to replace what is presently in C4D. In my opinion, Boolean is a very important workflow catalyst, and having it function efficiently, correctly, and intuitively would be a very welcome improvement for modeling.