Jump to content

Cerbera

Community Staff
  • Posts

    17,792
  • Joined

  • Days Won

    696

Posts posted by Cerbera

  1. 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

  2. 8 hours ago, kweso said:

    to any mod: 

    Something about the new website design confused me. So I posted this in discussions instead of the cinema4d forum. Would you be so kind to move this to the right board? If at all possible. Sorry and thank you very much!

    @Hrvoje

     

    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

  3. Yes, that theory holds water, unlike the balls themselves 😉

     

    image.png.ccebc443c95e8e1e5ab6f15a96858850.png

     

    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

  4. 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...

     

    image.png.e2e34b32460a9edb909db8531791e98c.png

     

    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

     

  5. 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...

     

    image.thumb.png.8b934aa7f6392fd78dcdadd2a678457a.png

     

    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...

     

    image.png.38234fe01385f2ef59b1cd7be92ab1e9.png

     

    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

     

     

  6. 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

  7. STEP import improves with every recent release - it is already leagues better than it used to be, and will continue to improve further as time goes on, but for now it is not perfect. Geo tends to come in just fine and fully controllably via the import controls (max edge length / angle etc) but materials are less robust currently - at the moment we are lucky to get material tags / selections assigned different colours, and that is about the best we can hope for IME. Generally, you need to redo the textures in Cinema / PS etc...

     

    CBR

     

     

  8. Then I am afraid the phrase 'shit out of luck' might apply here, at least as far as out of the box tools go ! There will invariably be scripted or Xpresso ways to achieve it but those are a bit outside my wheelhouse so I am not best person to advise on those...

     

    I agree there should be a way to easily do that though, and don't think I am missing any existing ways (geo axis node no good either for same reason) and you'd think it could be relatively simply achieved with the addition of a 'leave' checkbox or 3 in the main Axis Centre dialogue, the selection of which greys out the slider, a bit like we do in Set Point Value at the moment. I'll suggest that on your behalf if you like...

     

    CBR

  9. 6 hours ago, HappyPolygon said:

    I noticed something weird in the Orientation function in cylinders. I could be on every primitive though...

     

    Notice how the edges allign in the left image when the cylinders are positioned using the common rotate tool/coordinates.

    But on the right image they don't. This is prevalent only on an odd number of rotation edges which leads me to believe that using the automatic orientation function (here -Z) it also flips it on an other axis.


    image.thumb.png.9809aa46c4857f3886e76dbc9d27847b.pngimage.thumb.png.3815615a2fe714bd45a54a6615c1f5b9.png

     

    Maybe this is linked to the Line Capsule who's also been mentioned a "bug" with the orientation although it was noted that it wasn't a bug but users where still not satisfied...

    orientation.c4d

     

     

     

    I can sort of understand why that might happen, but it's not helpful behaviour; if the segments are the same in both cylinders they should align regardless of  segmentation being even or not. That's what everyone'll expect to happen.

     

    Also a regression, as this doesn't happen in 2023.x.x.. anyway - I reported it, and thanks for sharing.

     

    CBR

  10. 9 hours ago, Pistol Pete said:

    Is it the phong angle?  It seems to fix it when I select:  Style=Angle and Area Weighted / Phong Angle=180

     

    No no, we shouldn't have to effectively disable phong (angle =>180) to avoid those issues, or resort to alternative phong modes for that matter...

     

    image.thumb.png.0eae0878662494dccb61cfcec46776f5.png

     

    The reason they appear initially might be to do with using boolean operations / single object in the creation of the union between the 2 shapes, or because there are no loops along the lengths of the cylinders to clearly tell the phong tag what to do.

     

    But optimizing the mesh after collapsing a boole, and bevelling the intersections with a fair amount of segments should negate that and result in perfect smoothness everywhere with what I would describe as 'regular phong settings', thusly...

     

    image.thumb.png.18a79726c7ae9aa6c272794cd40b85ae.png

     

    So in summary, a few ways to get this done with no SDS.

     

    1. Boole Union, then optimize and bevel intersection edges.

    2. 45 degree cuts (line cut / angle snap) from centreline

    3. Volume Builder Union using curve options to negate bevels

    4. Any of the above + remesher stage (X + Y symmetry, hard edge selection etc)

     

    CBR

     

  11. Yep, neither of those can have additional windows. I guess it was thought that only Attributes and OM really needed that ability.

    I can't honestly say I have ever needed more than those 2 to have additional managers myself.

     

    CBR

  12. 7 hours ago, zeden said:

    What exactly is wrong? The blur of the red box?

     

    The problem isn't motion blur not appearing - it's that it breaks the physics of the bullet simulation about half way through the cached animation, where half the cubes suddenly start flying in a straight line and not reacting to gravity.

     

    CBR

  13. That is very odd behaviour, and especially curious that a) it only started a few days ago, and b) that it happens 70% of the time you undo. I can't imagine what could be going wrong there - if this was a problem intrinsic to 2024.2.0 we would have heard about thousands of cases of it it by now, and I'm pretty sure I haven't come across this before...

     

    Either way, it is going to be almost impossible to investigate unless we have a scene file that demonstrates the problem. Can you upload one, and more importantly have you done a support ticket to Maxon about this and sent them a problem scene ? - it is them who really need to see that happen...

     

    CBR

×
×
  • Create New...

Copyright Core 4D © 2023 Powered by Invision Community