Cerbera

It would help to know which versions of both Cinema and Octane you were using... Have you tried baking to Alembic ? CBR

We only need to eliminate ngons (leaving quads and tris), which we do by checking for stray ones in points mode, and ctrl-sliding those into neighbouring points. We can let triangles pass here because SDS will turn them into quads for us. Here, I fixed yours... JAEE pickball wrap 01 fixed.c4d Only modelling purists like me would feel the need to chase all quads in the base mesh. CBR

Were we to want to model the holes, we can do so fairly painlessly by applying our SDS to the mesh by CStO, and then doing Pattern select to get us staggered groups of 4 polys to inset, fit circle and delete, which gives us this sort of thing, under Thicken... I just did a small section to show you how that stands up to close detail... CBR

Change Extrude direction to Y. CBR

Now, in Stage 3 we were needing to move the points into the shape general shape of the handle. Presuming the bat is facing down Z, the current orientation of our spiral is not optimal (left, viewed from above). By rotating the object 22.5 degrees on H (360/(8/2)) in the coordinates manager we can sort that out in one easy hit, which we should follow by enabling Axis mode, and resetting it to 0, thus preserving our previous axis position, which will continue to be helpful where it is (right). Using this view we can easily select groups of vertical points in pairs and move them to get the correct handle profile, thusly... where we can then select these edges (being careful to exclude any that comprise any quad solves at the ends), and bevel them... If you bevel with 0 segments you can keep the corners quite subtle. ...which means they will hold their shape under SDS, but relatively gently... like that... Now just need to get an FFD under it to match the dimensions we are still missing in our reference. Lots of Y segments here isolates just the areas we want to affect. ...and that way we get our flares top and bottom (XZ only again, and don't forget Z, which you need to angle in at the top from side view as well), and we're pretty much done, apart from adding small thickness, which we can do procedurally using thicken, or manually using extrude (with caps and up to 3 depth segments). CBR

Quick sidestep to show you ideal bat topo... CBR

Ok, here's a closer look at stage 2 where we have just made our overlapping extrude editable... and then on the right, once we have added loops top and bottom and at 50%, which helps with SDS tightening later. The entire bottom and top loops get scaled in on XZ (presuming Y is up) with subtly different amounts, and we use the Remove A / B option in Plane Cut to decapitate it flat at both ends... Solving that to quads at the ends can be done a number of ways, all of which are quite hard to put into words, so I'll show you a closeup of what I did at the top for example... we don't actually have to be this tidy (will be covered in black wrap) but it's nice if we are... This gives us the following SDS result, which is looking fairly decent, but of course remains cylindrical so far, so we need to sort that out next... CBR

If you need assistance at that level of detail you may be waiting a while I'm afraid - quite a heavy workload at the moment, and those sort of posts take hours to compose. However I have built it (to proof-of-concept level), and so can give you edited highlights now... There are about 4 principal stages, thusly... 1. Helix spline in Extrude, but with very specific settings. In the helix the number of points is 8 x number of complete rotations. The end angle is -360 x number of rotations. Do 1 more spirals at each end than you need (I did 8 total), as you will be slicing this flat at both ends later. There should be zero spline interpolation, so that each full turn contains no more than 8 points in the resulting geometry. The Extrude should also have no (depth) segments initially, but should be deep enough to overlap itself by about an 1/8th of the depth of each band. 2. At this point we need to take an editable polygon copy of that via CStO, so we can edit and add loops to it. We need to add loops using Loop Cut (K,L) to both top and bottom of the spiral, so that the border edges can be scaled in on XZ to fix the overlaps and tuck the wrap under itself nicely. A further loop can be added to define the narrow darker strip at the bottom of each wrap at this point. 3. In the next group of steps we need to re-orient the model (but not its axis) by 22.5 degrees on H, top and tail it to flat, non-spiral borders at both ends using Plane Cut (K,J), solve the ends to quads and scale groups of edges apart to better match the elongated shape, before selecting the edges and bevelling them to gain additional support loops there, and harder creases on the corners. 4. Last stage is FFDing that with a great many Y segments so you can match XZ curvature around the handle from top to bottom of it... I will pop back to add further detail as time permits this week... CBR

Ah, so NOT a hexagon then - an oblate octagon ! Useful to see it with no wrap so we can see where it angles in at the top. OK, working with the assumption that we do the holes with texturing (a lot more faff if we have to model those too) I will show you the main stages of how to make a slightly overlapping skewed helical band matching that profile. Essentially it'll start off with single band matching the profile, but with ends offset, cloned, unified, conformed and FFD'd into the right shape down its length. CBR

That's doable. I have done many such wraps before. Are you going to handle the tiny holes with textures or with modelling, and is that a hexagonal handle profile ? CBR

Ok, we're going off at a tangent here. I didn't suggest the Projection Deformer at any point; only that we use the project to surface function within the Fit Circle tool. But I did you give you some slightly incorrect advice at that point - I had forgotten that this 'project to surface' function shouldn't need an additional object to project to - I imagine I initially thought it did because because your holes were pre-existent before you tried to round them, and I wasn't sure it could still predict what the absent surface was doing. However, in subsequent tests today I have confirmed we don't need an additional object for Project to Surface to work in Fit Circle. In poly mode, with the hole polys pre-filled that works reliably. With that said, the way you are wanting to go about this is still not the best way. I'll say it one more time in an attempt to save you the work, but trying to get topologically perfect circles, in that pattern, on a standard sphere, presumably planning on using SDS to negate your relatively low polycount (?) there is a very high chance you will never be able to get a fully perfect sphere and perfectly rounded holes. You will always be able to detect a subtle pinching or concavity around the holes because if you choose this approach it is simply not possible to keep polygon spacing even enough to avoid them ! But by all means progress with your current methods and find out for yourself ! 🙂 To give yourself the best chance of this working I would suggest that you put a spherify deformer in a null with the parent SDS of your mesh. Then at least it can work with the SDS result where the polygons will be more even and a lot more of them, rather than with the base mesh directly. Again, you need to do this before any thickness is added. CBR

First off you have to lose the thickness - fit circle can't acknowledge it for the purposes of reprojection. Then get another parametric sphere (VERY high segments and Reset PSR it to the same position (and scale to same size) as your ball to act as the reprojection surface. Then, select all the holes (poly mode, ctrl-A, then U,Q (outline selection) to grab all the hole borders at once) and chose the following options in fit circle... That should take all your hole outlines, make them exact mathematical circles, even out the edge distribution, and reproject that onto the high poly standard sphere you temporarily put underneath, all in one easy move. When happy, re add the thickness back.

Depends which version you have (profile doesn't say only 287 posts later ! 🙂 ) If you have a version that contains Fit Circle natively there's your answer, otherwise you need HB modelling bundle or an alternative points to circle plugin / script, but note that the only useful ones here are the ones that also re-project to surface (Fit to Circle / HBMB)... others won't help because they will force the geo flat. Using the boolean methodology the ONLY control you have over the shapes is the amount of segments you choose in the operands. My holes are almost flawlessly round because I kept those numbers high enough to preserve the roundness despite what the boole did later. There are so many edges on my holes that the new ones the boole adds can't affect the shape so there is no need for correction later. CBR

Your topology density is way low. Increase segments on sphere to at least 192, and cylinders in boole to at least 64 segments and everything will be perfectly round. CBR

No. Boolean based geometry is not controllable at the polygon level whilst it is parametric. However the example topology shown is not great, and if used with SDS will produce a highly artefacted mesh which will be a long way from properly spherical, which is why we shouldn't use that method as I explained above... CBR

Sure the scene file wouldn't be more helpful ? Pickleball CBR 01.c4d CBR

That second file is confusing. Your pusher plane is facing +X, and its normals are correct. Meanwhile, in the collider tag, the collision surface is set to front, which I would expect to be correct, given the facts above. However 2 things confound me... 1. For me there is no effect at all on the coins, no matter how much I play the simulation, which is what I would expect if the collider direction was wrong. 2. ...and it IS wrong ! If we set that to 'Back' then I have full interaction of the plane with the coins every time. So, that is apparently the solution here but doesn't explain why front and back are seemingly reversed in the RB tag NOR why you are getting some coins moving some of the time... I would expect that to be an 'all or nothing' thing. CBR Update: There is something odd about that pusher object - in further tests it started doing nothing at all regardless of the front / back setting ! But a newly created plane seems to work fine, even if I use the same collider tag from the original pusher object... pkrAllIn2 CBR.c4d

In answer to your question, there's a few issues to sort out there. 1. Collision accuracy. Coins are poking through that floor due to 0% geometry accuracy in the dynamics tags. Turning that up sorts it, but slows vp right down, so I presume that is why you set it that low, temporarily ? 2. We can control the exploding and lack of settlement with the deactivation controls, which in 2024.3.0 are enhanced, as I recall, to encompass angular, linear, sleep and damping thresholds, which I found had great effect in stabilising your coin pile collapse, thusly... pkrAllIn CBR.c4d CBR

Worry not - a fair few people make that mistake, some of them repeatedly, even when it is pointed out ! It warms my moderated heart to see that you care 🙂 CBR

Yes, that theory holds water, unlike the balls themselves 😉 So here, in this fully parametric setup, we have 2 cylinders, a smaller one doing the top 4 holes, and then a larger one providing the 2 rows of 8 underneath that. These are all variously offset radial cloners using a target effector on all 3 to make the cylinders point down Z at the centre of the sphere. Those 3 cloners are then given Y symmetry to get the other half, and dumped wholesale in a Connect where they can be used as operand B in a Boolean Set in 'A without B' mode. If we set cylinder and (standard type) sphere to atypically high segmentation (64 and 192 correspondingly in my example above) then we get perfect spherical representation and no visible faceting without further help. Live remeshing (ZRM mode), which is an option that can be deployed above all this, can actually have negative visual effect here, as it can compromise a) the look (no phong tag on remeshed objects by default) and b) inconsistency in edge distribution around the holes which can lead to visible artefacts you then have to work to fix. For those reasons I was getting cleaner results (though less toplogically sound) without remeshing. We mustn't forget that 99.9% of clients don't give 2 shits what the mesh looks like anyway, as long as it's fine in render... Lastly we can bevel the hole edges a suitably tiny amount if we need to, which I like to do on a CStO of the main setup using a selection tag (U,N / Select All, Store Selection) for additional realism; they may be sharp, but not infinitely so. Lastly we should consider that these balls are made out of weak, insubstantial plastic, and get twatted about, meaning their likelihood of remaining perfectly spherical is... low. So should we wish to show that too we can pop a crafty displacer (large scale perlin noise) or an FFD (for more directly art directable wonkiness) in with our parametric setup, or, as I would prefer, under the copy of it I made later (avoids constant remesh recalculation if you use it)... CBR

We'd need the scene file to be sure what was causing it, but it'll be something geo/ phong / normal-related. CBR

That's an interesting nodal method, but I am not sure that blue noise is quite matching the reference pattern there, although if it can be made to do so via the settings then that is indeed a very simple way to get a fast, topologically sound, satisfyingly spherical result, and doubly helpful in that we also neatly avoid all the pitfalls and traps inherent if we get SDS involved ! (pinching / non-spherical perfection) AND can easily get the holes to have sharp enough edges... The actual pickleball pattern is best visualised thusly... As we can see, it is divided into the polar caps, which contain 4 (characteristically unevenly distributed and meant to be extensions of, and line up with the founder's centre 'X' logo) holes apiece and we have 4 bands of 8 offset rows of holes between them. We can also note that there are 2 different dimensions of holes in a single model, so that is probably helpful too. So, were I to have to recreate this nicely using trad modelling techniques, which is I suspect is what you're after, and accepting presumably that you are happy with a slower but more accurate approach, then I would let the pattern dictate the patches I would prepare for spherical layout. Whereas things like golf balls are based on a tesselating hexa-triangular patches, this notably isn't. It's 2 poles and a band, so we should do that too. So I would prepare the polar patches flat, based on an orthographic TD view of the ball. When finished with those I would use offset Wrap deformer to 'polarise them'. Then I would make each row, or perhaps all 4 of the centre bands at once as a flat strip, possibly using mograph's honeycomb array distribution to save me a few manual steps, which I would then also wrap deform into a general spherical band between the 2 poles, being careful to make my holes narrower than default (different amounts per row), so that they become as near round as possible when later deformed / stretched. As a side tip, best to UV it while it is still flat as well if you need a UV, which we probably don't if we're honest. And here a little modelling skill and XP is required, because you'd have to make the radial edge count of your polar patch sections match the edge count of the top and bottom sections of your centre strip for this plan to be successful without remeshing. Having done that however, it then would come down to combining the 3 (or more) meshes into a single model, and then subdividing and spherizing the result, after which I'd be adding procedural thickness with Thicken, or manually extruding with caps to finish it off. I am fairly rammed with work at the moment, but will post my result if I get time to try it later. So that would be the SDS way, but unusually for me, and in a world where increasingly faster is better, we might get a speedier and less brain-taxing result if we combine the 2 approaches suggested so far. For that reason I would be tempted to use the boolean / remesh method but instead of a blue noise nodal distribution, merely accurately recreate the pattern of cylinders using the info above and several radial cloners, for arguably the best of both worlds ! CBR

You may be forgetting that with Loft objects the resolution is not derived from source splines but from the object itself. Massively increase U segments in Loft Object... I don't like this method for doing this sort of thing because it is quite difficult to get (and verify) identical segmentation on each side unless you symmetrize later. Also note distribution of edges, which is kinda arbitrary and not that great if we're honest. By the time you have sorted that out for regular spacing and whatnot, you may as well have modelled it from polygons with symmetry and got a more usable base going forward ! If we definitely want to use splines, then Extrude is the better generator because that does take its interpolation and point counts from the spline, and it is trivially easy to add the little ridge bit on one end later... Of course if you need splines for further modelling tasks you can still use the ones you have, or generate them anew from your evenly divided model using Edge to Spline... CBR

Unfortunately Q behaviour has regressed elsewhere 😞 They really gotta stop making that affect any other generator except SDS, and ESPECIALLY not do symmetry... I've had to work around that with a script or I would find it borderline unusable for modelling. Excellent use of it in nodes tho ! 🙂 CBR

I wonder if there's an OSL shader that does that or something very similar - did you check on GitHub ? CBR