Cerbera

So, to clarify, select phong tag, and reduce its angle to something under around 22 degrees. You may also need to turn off edge breaks. CBR

Oh - I did forget to set my f-curves to Linear in that file - if you do that you'll get constant rotation without stuff speeding up and slowing down. CBR

2. I think you just have to change the axis of the blue object you are trying to orient so Z is pointing in the direction you want to aim ? Most rigging type things want the length of stuff pointed down Z. So it is 90 degrees off at the moment, which is consistent with the results you are getting. You can do this with Axis mode (L), but be careful; a) to remember to deactivate Axis mode once it is correct, b) to do this on Frame 0 of the animation, and c) I don't know what other parts of the animation and rigging doing this may also affect, so you may have to adjust other things in the scene to compensate for that axis change... CBR

Oh I see ! 🙂 yes that's no problem. You just need that spline driving a spline wrap under a plane; then you can animate the offset in the Spline wrap, and keyframe that to get the belt to rotate. Spline Wrap CBR.c4d CBR

I don't understand the question; can you elaborate ?! CBR

1. We can limit a slider directly in the HUD, but shouldn't. Instead we should make a custom control (object user data), and range map it (that can be limited as you require) to the relevant rotation parameter via Xpresso, and we can then drag the UD control into the HUD, which will then do what you want, as demoed in this quick video below... User Data.mp4 CBR

It's not the ngons specifically it has problems with. It is the Isolated nature of the islanded points inside the perimeter. M-M generally doesn't work in these circumstances either. But, if you cut from an inner surface loop to a perimeter one and then continue that cut along the border some distance, then back into the inner groups and to the point you started the cut from, it WILL work, as will all subsequent cuts after that. I reported this some time back, but to be honest, now I know the workaround It hasn't really bothered me since, although I accept it is perhaps not ideal, and hope they find a way to address it. Hopefully this video explains, and gives you the work-around. Line Cut and isolated ngon islands.mp4 Interestingly, I believe the old knife tool (pre R18) COULD do the original cuts you are trying to make, and that would APPEAR to have worked, but actually the resulting mesh would be in an error state afterwards and would cause problems later because of it, hence the decision to prevent its success in these circumstances since it got rewritten. But I don't know if it's most limited tool in the industry - I don't think it's the worst ! 🙂 Max's knife has been inserting quasi-random extra points with knife cuts ever since it was introduced, and that persists right to the current version and has been like that for over 30 years ! As someone who uses the knife tools at least 500 times every day I feel I can honestly say that our own knife tool isn't that bad, and works in 95% of the circumstances I give it, the one you highlighted being a very rare exception to otherwise consistent performance. But that said, of course I agree we should be aiming for the full 100% ! CBR

Feature nobody expected / wants: Thought Control input (free headband / electrodes included). Feature sneakily removed without telling anyone: All legacy input methods (mouse / KB etc). CBR

Yes if there is going to be dissing, let's at least have equal opportunities dissing ! CBR

What is your computer, and which version of the software are you using ? Because it sure as hell ain't R32 ! CBR

I suspect we may have been without it too long to change it now. Most Cinema users of old are very entrenched in the way it works now and has always worked, or have hardware solutions for it (like I do on my Space Explorer for example), that are no slower than a combined gizmo would be. I actually prefer the less cluttered one-mode gizmo we have now I think... CBR

Oh OK, yes we are talking at cross purposes. What mash said. CBR

Yes, that is correct, and happens because in the lower picture, the edges there simply do not exist yet ! You can't expect to have lines showing at intersections until those intersections are actually there, which is what the boole does in the first image... 🙂 CBR

It's not obvious what the issue is, and you haven't given us enough information to be able to tell ! Please upload the c4d scene file, so we can see ALL the relevant settings. CBR

There is a simple answer to that one. Delete any existing material tag from the object, and drag the material again from the manager onto the selected polys in the viewport. Whatever happened last time should happen again ! CBR

The only keywords I ever needed were 'C4D UV mapping'. That found me this tutorial specifically, which is what initially began to 'clear the fog' on the subject and gave me a good theoretical foundation on which to build. That was way back in the day, and reviewing it now, I am less convinced it's the best intro to the subject, and of course some functionality in Cinema has changed since his version (right back in in R13), but I still think it is useful in terms of introducing the main concepts, even if the execution of them might be a little different these days. CBR

No, you HAVE got answers to your question, but you appear to be lacking a fundamental understanding of how UVs work which may be preventing you from taking them in ! I will endeavour to explain it in the simplest terms, thusly: When a primitive is created its UV data is also created along with its physical properties. So each polygon in a primitive has an equivalent UV polygon. Initially those 2 things are identical, and if they stayed that way you would never have a problem. But a UV canvas is a 2D square, and the chances are your mesh is not ! Take the Example of a Plane Primitive, which does start off square. That has a Flat projection baked into its UV by default, which is generally speaking the most helpful for that object. Now, when you make that editable its UVs become permanently baked into the square UV canvas, and for the first time they are directly accessible to us. Anyway, so you now continue modelling, and you (presumably) change the form of the plane into a different shape, or at least move some of the points away from their initial positions. So the physical points move, but the UV equivalents do not move with them, because they need to stay on the square UV Canvas. and so then we have discrepancy between the physical size of the polygons, and the physical size of their UV equivalents on the UV canvas. This will be unnoticeable until we add a texture that is not a single flat colour. And as soon as we do we will see distortion in that texture wherever the size or the aspect ratio discrepancy exists. So, in the normal order of operation we complete the modelling, whilst entirely ignoring what the UV is doing so far. THEN we have to decide what to do with materials. If we decide we can use any of the standard projections, then the UVs become unimportant, and it doesn't matter if they are not right, because now the texture projection is not based on the actual polys, we are just projecting a texture on to them. But if no standard projection will do, then we have to use the UV mapping mode instead, and thereby have to worry about what the UVs are doing, which is where UV 'unwrapping' comes in. That is the process of making sure that your UV polys match your edited physical ones on the model in terms of relative scale and aspect ratio, which returns the texture to looking correct again because it is no longer distorted. And of course, if you then change the points or polys in the model after doing that, then you will need to UV unwrap again to match the new point positions, which should answer your question about why this happens to your paths when you make them wider. It also explains why I was suggesting you tried a flat projection, because then it wouldn't matter what you did to the paths at any stage because the texture is independent of the geometry. CBR

Lovely - one can never have enough of those... CBR

There are different basic projections for every primitive - we'd need to know what you made your landscape out of to know which was was the original. If you could include something helpful like a screenshot of it we might be in a position to guess which one will work ! In the absence of that I would guess flat mapping is probably what you want, but you'd probably also need to go into texture mode and rotate the projection so it was planar with the majority of your object. If the terrain is more angular than Flat projection can reasonably cope with then Cubic will be the next best option. If you end up with visible seams using that then you might have to make a triplanar mapping setup, which is like Cubic except without the seams. CBR

Yep, as Srek points out, adding a new map is not necessary - you just need to reproject the one you have once you have changed the path sizes ! Do you definitely need to UV map this is a question we haven't asked yet ? Are you sure none of the standard projections will work for you - in which case order or operation becomes less important, and the texture remains independent of the geo so doesn't need adjusting if you change it. CBR

Well if textures stretch when polygon sizes get changed you must be using UV mapping as the method. In which case you just need to pay attention to the proper of order of operation in Cinema, which is to always finish your modelling before you do UVs. So if you change the path sizes you need to do the UV mapping again. CBR

No, if the source meshes are animated, then necessarily the volume mesher will have to be constantly reconfiguring its points and point order, which makes the whole concept of vertex maps here irrelevant / unworkable, because they depend on point order remaining unchanged. So I'm sorry to say the answer here is 'no, that is not possible'. You will have to find another way to control the colours. CBR

This is excellent forum-ing. Well done everyone. CBR

Yep, I can also do it with the move tool EXCEPT if the axes of the objects the null contains are exactly coincident with the axis of the null itself. Then we can't even do raycast selection with ctrl and r-click because if we do hit the null icon with R-click held, then it'll go into axis extension mode. May I ask why you can't / don't want to just select nulls in OM ? CBR

That's interesting. In my tests I am unable to select Nulls in vp if they have no icon / shape, but as soon as I add any type of icon (even dot) then Rect Selection can get them for me. CBR