Leaderboard

A pretty common workflow in Houdini is to copy geometry to points. When dealing with a large amount of points, the copy process can be a bit slow, and make the viewport sluggish. A good way to preview the copies and tweak their sizes and colours without actually copying any geometry to the points is to change the display of the points themselves to Lit Spheres in the Viewport Display options (press D with the mouse cursor over the viewport to bring up the options). Here is a preview of 10 million points running effortlessly on my old GTX 1080 Ti:

Well, they are still error-state polys at the end of the day, that are interpreted by other apps arbitrarily and differently, so in today's infinitely extensible world best to avoid them if we can surely ? Or at least be very familiar and clear about when they matter and when they don't. In the example I was referring to they were deforming into a cylinder (or at least that's what I thought), hence my initial confusion about how that was possible... But I would venture that Ngons have never been great - merely 'functionally adequate in limited circumstances'. I don't think we could ever describe them as 'ideal', and they do tend to produce weak, unstructured meshes that can affect such diverse things as negatively affecting UV relaxing to disrupting future modelling and selection operations (though I must also acknowledge that in other circumstances they can actually facilitate moves that would not be possible without them). It's not that I think they don't have any place in modelling, I just think they are not something we should be aiming for in general. There should be a persisting 'avoid if we can' rule-of-thumb going on at the back of our minds during most modelling projects (that aren't just text !). I think they have achieved a certain stigma through their own misuse, because they tend to be the hallmark of the new, the inexperienced and the lazy - a lot of new people initially think they can use them anywhere, or instead of actual edge flow and topology, or to avoid having to actually 'solve' any topology, and they may get that impression from the people who use them casually and 'properly' and yet either don't acknowledge them at all, or are unclear about explaining why they are getting away with it on their planar surfaces. Yes, that ! 🙂 CBR

Ugh never again ! This bloody thing took a month, on and off a few hours here and there before work and single handedly changed my out look on life XD. it’s based on a Tie Interceptor, most of the greebles are my custom design an interceptor 2.0 if you will and was over all a massive pain in the rear end 😄 it was more a test of modelling prowess for me anyway 🙂

I had however looked in this direction without arriving at your result. Many thanks Cerbera for the time for the explanation; I understand better now how to go about it. 😀

There are indeed lots of approaches to this sort of thing. The simplest would be to make a null at the centre of your large sphere. Position the smaller sphere exactly on the surface of the bigger one somewhere, then make it a child of the null. If you want to position that accurately, simply create the large sphere at world centre, then add up its radius and that of the smaller sphere, and set that value in coordinates manager... Then get a vibrate tag on the null, and give it 360 degrees of rotation in all axes, setting a frequency of around 0.1 - 0.3. Press play. Smaller sphere will appear to roll randomly over the surface, but actually isn't rolling, just moving with a fixed offset which makes it 'seem' to chase the surface. But unless your spheres are textured with some sort of pattern that will not be obvious, so if the rolling sphere is just a block colour, or chrome or something then it wouldn't have to actually roll... If it does need to physically roll, then you can add bullet rigid body dynamics to that setup, and carefully balance follow position / rotation with the non-dynamic animation so that you still get the movement of the vibrate tag but also have physical collision properties, which if got right, will make it actually roll on the surface. For that you may need an attractor force placed at the centre of the large sphere to drag the rolling sphere inwards onto the surface, and a lot of friction on both objects, the larger sphere being the collider that prevents that smaller ball ever reaching the source of the attractor... Update: I didn't even need the attractor - just lots of friction ! rotating sphere CBR.c4d CBR

Oh those are looking superb 🙂 No 3 is my clear favourite so far, though they all have their own charm... CBR

I do. And yes, I started from the basic shape before any insets. Yes, angle has to be high enough to 'get over' the acute corners, and as you say leaves just the single points at each junction to correct, which can be done by eye, but it frustrates me that 'by eye' seems to be the best we can do here - ideally I would like to know we can get these things correct in a mathematically precise kind of way... Personally, I think we could do with a brand new 'Shell' tool that deals exclusively with adding thickness to things and is immune to the pitfalls our other tools succumb to in these sort of circumstances. Max has this, and it has a special 'straighten corners' checkbox that just magically corrects these sort of corner issues. I have suggested to this to Maxon in the past, and again more recently in response to your post. I know they continue to take trad modelling seriously, so remain hopeful they will listen. CBR

Thanks so much for your help Cerbera. Having said that, I'm having a hard time following the steps you did to get the result! "I started off by removing the ngons in the base shape caused by that rogue vertex in the middle on one side." You mean the dot on the back in the basic shape, right? Does that mean you started with this model, not the one with edge cuts? "Instead we will apply a bevel in Solid mode so that we get box corners everywhere" This basically creates the version I have put at the top inside "Subdivision Surface.2", correct? If I then extrude I get the issue of the split edges on the backside so I guess I'm not doing it right? But then I did the extrude and increased the max angle to the point where no edges are split, and looks like the only this leaves me with an extrude that looks pretty even and good when subdivided. The only 'off' points are the absolute outer points of the 4 corners and they can easily be moved back to their expected position. Is this what you were doing in the last alinea?

Alright, not a big deal! Really appreciate your help 🙂

I´m fine with n-gons on flat surfaces. I was only ask for wires because of your first post where flat surface contain a lot of n-gons (looks like) and then are screens with bended that surface. In case n-gons are not solved some way, you could see bended surface deformed. And on screens looks good, so expect some internal software solution which produce nice result. And Igor´s post in the middle of previous page show screen based on your example and there´ s visible huge subdivided mesh (which ofcourse produce nice mesh with enough phong settings (or whatever is called in Houdini))

It's a fair point. SideFX has only very recently shown a keen interest in making Houdini more approachable. I started with v17, and things were pretty brutal then - almost no beginner learning material, and a very heavy reliance on VEX to get even very basic stuff done. If their development pace since then (which has been astonishing) can be maintained, hopefully things get a lot better Soon™.

Your desired result is also incorrect if the aim of this enterprise is to avoid UV distortion. For that to be correct A and B would have to be the same sizes as the corresponding parts in the cap islands... And if that were corrected that would give you 1 very long island that would be a crushingly inefficient use of the UV space and force your cap islands to be unnecessarily small if equalising island size is something you need to do, and it probably is. Now, we can get your desired result, or rather the correct version of it by doing an automatic UV in cubic mode, and then manually realigning and terracing the rim blocks into one contiguous piece. But that is not a good idea for the reason above. What we could try is planar projecting the front cap and rims, then relaxing just the rims outwards from the cap, like so (closeup)... ...which seems to get us less distortion than I was imagining we might get, but if we want something that is truly mathematically distortion-free, then we really need to slice every single one of those radial corner edges to get that, as shown in this video by C4D leviathan Noseman... the circumstances are the same, in that we have curvature in more than 1 direction along the rim. In your case though, this curvature is restricted to a very minimal area, so the distortion consequences of that are not so apparent using the approach above, and indeed that may be a reasonable solution in your case. But if not, here's what you need to do to do it right ! CBR

No, not at all. The first example was from @eikonoklastes- which had ngons. I'm learning Houdini so took that and reworked it a different way - just for the exercise. My version was quad based. It was just a different approach. I thought I'd better get it done in quads, because I thought you'd be along shortly 🤣 PS: @Igorand @eikonoklasteshave been great support in getting my Houdini journey started,

The short answer is that this is one of those very rare shapes that Extrude alone cannot deal with ! The reasons for that are to do with the way it averages / combines contributing edges' angles of conjunction at points of termination and the extrapolation thereof, in which there is scope for error, and the way that error manifests is the inaccurate positioning of the newly extruded surface. Simple hey ? No, but I am less interested in the 'why does it do that ?' than in the 'how do we get around it ?' once we accept it does, as we surely must...🙂 I started off by removing the ngons in the base shape caused by that rogue vertex in the middle on one side. Then we have the option to Inset all faces, but we shouldn't do that. Instead we will apply a bevel in Solid mode so that we get box corners everywhere, which are the best chance of controlling and defining the geometry there particularly in relation to keeping corners sharp after any future subdivision. But it also has a corollary effect of allowing Extrude to better know what is going on and thereby allow it to work in a (slightly) more easily correctable way. Now, some things to note. If Extrude fails, so will a Zero-extrude and subsequent Normal Move; they both use the same 'averaging' calculations to get the result, so the same errors will occur. So instead we have to do the extrude, and fix its fail points manually, which isn't ideal, but is what we have to do ! I would be interested to see if the extrude functions in Blender and Houdini can do better. So we need X-ray mode at this point, so we can see exactly what is occurring throughout our extrude process, and thereby see what we need to correct to make up for its shortcomings. And in most cases we will have just a single vertex to move at each of the major points of the model. Initially we should do that by eye, but when you are close you can break out such new tools as Straighten Edges (or HB_lineUp if you have HB Modelling bundle) to further repair things. This one took me about 5 mins to clean up to a standard I would call 'reasonable' ! If there is a way to do all this automatically I have not yet found it, and suspect I never will, unless scene nodes can come dramatically to the rescue, but alas I don't have the time today to get into those... UPDATE: Fellow C4D alumni Noseman has since pointed out that we can see the erroneous extrude directions if we look at the Vertex normals (with the phong tag set at a similarly high angle to that we needed to use in the Extrude)... As those are not directly editable, that would seem to be the end of that particular avenue, at least as far as auto-type solutions are concerned... CBR

Welcome Christoph! Top work on your site!

Very welcome Christoph!