Jump to content

SharpEars

Registered Member
  • Posts

    103
  • Joined

  • Last visited

Other groups

Limited Member

Profile Information

  • First Name
    SharpEars
  • Location
    Chicago

HW | SW Information

  • OS
    Windows
  • CPU
    i9-7980XE
  • GPU
    Nvidia 1080Ti

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

SharpEars's Achievements

Apprentice

Apprentice (3/14)

  • Reacting Well Rare
  • First Post Rare
  • Collaborator Rare
  • Conversation Starter Rare
  • Dedicated Rare

Recent Badges

18

Reputation

  1. As a good general rule of thumb, I agree, but I would start the "rule of thumb" at six sides, because it is a very useful starting point for many real world scenarios, rather than at eight. The one thing I am sure we both can agree on, is to keep the number of sides even!
  2. None of these can produce a "true" cylindrical form under subdivision, although the difference decreases very rapidly as the number of sides increases. Even an eight sided or any-sided cylinder, regardless of the levels of subdivision, will pull in more at its vertical edges than the flat surfaces. For example, here is an eight sided-cylinder with 5 levels of subdivision, compared to a circle spline with a ridiculous adaptivity setting of 0.001°, the closest I could get to a true circle: of course the distinction between edge and side collapse is far more visible with a four-sided cylinder, where it is far more extreme:
  3. Primarily, because when moving a single selected point via dragging, you can't "grab" said point while the Move Tool Axis is visible - it is in the way. You have to click and hold the left mouse button down, away from the Axis, causing the point to jump and start movement at the clicked mouse cursor position rather than its initial position which you immediately lose track off (there is no breadcrumb displayed indicating where the point started the move, which would have been a nice feature). This especially matters if you are using the initial point location as a reference for the direction of movement or to help decide the final placement of said point. Also, sometimes the Move Tool Axis obscures an important part of the scene that happens to be behind one of its many accoutrements (i.e., arrows, axis lines, triangular wedges, etc.). I guess this is the primary reason that Maxon added the Show/Hide Axis command in the first place.
  4. @Cerbera, just a brief question about something you said: What's wrong with four and/or six radial segments for a cylinder, pre SDS? Six segments is especially useful when the finished object requires six-way symmetry (or 12, or 36 [24 and 48 were excluded, being divisible by 8]), There are fewer uses for four segments, unless your object happens to have a conic tip and you want nice rounding under SDS, then four is your friend (e.g., SDS applied to a four-sided pyramid atop a cube (this object started its life as a four-sided cylinder with one height segment, conveniently providing us with an "X-marked" top surface which allowed for the shifting of the central point in the middle, upward to form the "roof") to form something resembling half of a capsule or a handgun fired bullet's head):
  5. (R25) Interesting, I think I understand what the issue is and it's not View related. While using the Move Tool, if you hide the Move Axis via Alt-D and grab a point and attempt to move it by dragging it to another location, trying to position it over the axis of the Null or the axis of any other object, the point you are moving via dragging using the Move Tool refuses to snap. If you move the point while the Move Tool's Axis is in the visible state, either by clicking on one of the triangular wedges of the Axis to constrain motion along 2 axes or one of the axis arrows to constrain motion to a single axis, or by clicking off of the Move Tool Axis altogether to cause it to jump to the clicked position and move from there while being constrained via the normal X/Y/Z constraints (if set) on the toolbar, then the point snaps to any Object Axes just fine, because in any of these cases the Move Tool Axis is in a visible state. So, the issue is one of: Snap to Object Axis does not seem to work while the Move Tool Axis is hidden (e.g., via Alt-D on Windows or Opt-D on the MAC). Other types of snaps seem to continue to work just fine while the Move Tool Axis is hidden - they are not affected. A workaround I have found is to create a zero length Line Segment Guide and place it as a child of the Null positioned in the same location as the Null modeling axis itself by resetting all transforms of the Guide object after making it a child of the Null, (in case the Null already contains other children). Then, with "Snap to Guides" enabled, you can logically snap to the Null's Axis (by actually snapping to the degenerate 0-length Line Segment Guide [or physically, the two coincident points that form said guide which are located right at the Null's axis]), regardless of whether the Move Tool's Axis is visible or hidden.
  6. Does anyone know why axis snap works fine for an empty Null object in the Perspective and Parallel/Orthographic Views, but not in any of the six Primary Views (i.e., Top, Bottom, Front, Back, Left, and Right). You can try it for yourself: - Create a Null object (you may want to set its shape to "Locator" to make the position of its Axis point easier to see) - Turn on the "Axis Snap" snap option (and turn on Snap itself, of course) - Then take an editable point object and try to snap one of its points to the axis of the Null - Try this in Perspective Mode or Parallel Mode, and it works fine - This this in a Primary Mode like Front or Top, and you can't snap the point to the Null's axis I wonder why this is. It seems like a bug to me, unless this was done intentionally for some reason that escapes me.
  7. Are there at least Release Notes for R25.117?
  8. You are largely correct, with one very large exception. Because objects can be fairly complex and the Python API is barren (as compared to the C++ SDK) and is implemented (strictly) from a "easy to use" rather than a performance perspective, the transfer of information from inside C4D to Python (and back) is often done very inefficiently. The general paradigm is to copy data and create new Python containers (i.e., lists) rather than make incremental changes to whatever data the Python programmer already has available or has received back from a prior call. There is also, within Cinema 4D the need to (deep) clone objects over and over again, but that's a separate topic that is orthogonal to the use of Python. This "copy everything on request or submission" paradigm in particular is what makes the Python API slow when it comes to creating and/or manipulating the guts (i.e., points/edges/polygons) of large objects, splines with many points/segments, and/or object hierarchies consisting of many objects. If you ask me, the Python API should be enhanced with more performant versions of calls, with backward compatibility, of course, and further enriched. Then there would perhaps be a hope and a prayer towards (better) performance. I did not mention the issue of threading in the above, but that is another Python limitation that is far more difficult for Maxon to address from an API evolution perspective, since it is a limitation within Python itself.
  9. It's Python after all, the language for quickly "banging something out," unless you expect it to also be performant, that is. Everyone that doesn't wear the "blinders of ignorance" knows that you can't do much worse than choosing the poster child for "slow, poorly performing code" - Python.
  10. Here is a picture of a few, for reference, created with the following parameters: First one: Radius: 25, P: 2, Q: 3, Cross Section Radius: 4 Second one: P: 3, Q: 4, (all else same) Third one: P: 4, Q: 5, (all else same)
  11. Hey, where is the obligatory, "WARNING: Not for the squeamish tag?" 🙄
  12. Or they want to fix the other dup bugs that have been found in addition to the ones fixed, and release a .116 (?) hotfix.
  13. First pass attempt at scripting this via a Python generator (make sure to view full size, it's 1080p, sized down from 4k): The reddish circle Nulls identify misaligned neighboring points. The green marker Nulls indicate where the master of the two points should be, in order for them to merge into and occupy one shared point as a result of the Symmetry generator (i.e., mid-point). Another example: Somewhere on the Platonic, below, which has been converted to an Editable Object, lies a point that divides an edge, that shouldn't exist. See it? Neither do I! I just got done cutting one of the many edges into a smaller part and a larger part. But, having zoomed out, they all look the same and even I can't tell or remember which edge it was. Sure, Optimize, with the correct settings (usually found through trial and error, btw!) can fix this and get rid of the smaller (sub-)edge via welding, but where in the world is it? Will Optimize weld correctly, retaining symmetry and alignment? (Note: Probably not, if experience is anything to go by!) Will it remove any points that should not have been removed? Who knows... OK, to be fair with regard to this particular case, all of the edges, except for two, are of the same length, so Optimize will probably do the right thing once set up correctly. Anyhow, enough about Optimize. We plop the object into the Python Generator I've started writing the code for, let it do its thing, and we get the following: Ahh, there it is (i.e., well, there they are - the points that make up the shorter of the two edges)! Let's zoom in and take a look at the situation, now that we know where on this complex map, it lies. I have gone ahead and selected all of the points of the modified Platonic, in order to make things more clear. The red circle Nulls (overly large for this case, I know) mark two very close adjacent points. The green sphere Null marks the midpoint to which they can be welded, if so desired. Of course, we can always choose to weld to one of the two points - it's our choice to make: Correctly choosing among the three possibilities, with human understanding of the object's point layout, symmetry, role, and context (i.e., something Optimize could never do), we perform a proper spot-weld and restore our poor cut-up Platonic to its former beautiful symmetric glory.
  14. Not sure what you mean by the abbreviation of VP, but certainly an option to Optimize would be welcome, or perhaps an addition to the Mesh Checker, not sure how. I just might script it up myself, in the direction of the fourth example image perhaps with an additional target null marking where the point should be moved to, assuming the midpoint is the correct place. This is complicated by the fact that there may be more than two points that are in close proximity and need to be welded together. Also, turns out that optimize doesn't even weld to a location in the middle! It just welds one point to the location of another, somewhat arbitrarily (perhaps having to do with point order or how optimize works). I guess I can compare my results with those of Optimize to make sure I am doing the right thing...

About Us

We are a community of passionate 3D artists, hobbyists and professionals. We welcome everyone, and encourage artists of any level willing to share, discuss, learn, and generally contribute positively to the community. If you are a Cinema 4D, Blender, Houdini or Unreal Engine 5 artist then our Core 4D community is the best place to hang out and meet like-minded people! :cowboypistol:

×
×
  • Create New...

Copyright Core 4D © 2022 Powered by Invision Community