Cerbera

Hmmm. No. Is working over here. Maybe do a support ticket about that ? Command is c4d.CallCommand(1036224) # CBR

No no, in fact I'd say FBX was superior to OBJ in every way, except possibly wider compatibility with really old software !

I think the more apposite question might be 'Why is OBJ so much more inefficient than every other format?' !! It's true OBJ files can be huge. I don't know specifically why this is, but feel sure it must have something to do with 'legacy', given that OBJ is a very old and 'first gen' format that should have been retired a while back, but (presumably) for backwards compatibility and 'library' reasons, hasn't been. CBR

Need more infromation, and the scene file. Is this Bullet dynamics or new Rigid Body sim ? CBR

I will get round to testing this myself - just having a mad busy week that has stopped me getting to it so far. I think there have been some changes / upgrades / tweaks in the sim system between the 2 versions you mention, which may explain this change. CBR

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