Interest to have some many control points is to permit to modify "locally" an object! ;)
Like polymodeling! :)

Hi Pilou,

I'm glad to hear you again...

Well...as always it depends on what's your modelling goal.

But, in general, local editing and "control point editing" it's not the best feature of a Nurbs modelling package.
Also Rhino with its powerful MoveUVM command has a hard time in that type of things.
Very rarely Nurbs modelling give its best in point-modelling (or box-modelling).

So much so that for this type of task, exist very sophisticated software like Clayoo or T-SPlines, which mimic poly-modelling in a Nurbs environment,
but not always with very good results.

Best,

- Marco (mkdm)

Hi Marco, so I know these are case studies for your own experiments but I should mention that optimizing entirely for surface control point count can come with negative side effects, like increased modeling time and some decrease in model accuracy since the new object now deviates from a true offset surface by some unknown amount.

For most modeling cases these negatives, particularly increased modeling time, will likely outweigh the positives. In your particular case here exporting the "bad" object (I know you didn't say bad, but it's easily implied to others that one is "bad" and the other "good") to its own 3DM file result in a 74KB file, while exporting your approximated offset object results in a 42KB file. So here you're not saving MB worth of data, only KB worth of data.

So unless you're replicating this object many hundreds of times I would really recommend not worrying so much about the offset surface control point count. And in the future replicating objects will be done by instancing and that will make it even less of something to worry about.

- Michael

Hi Michael and thanks for sharing your point of view, that certainly is more technical than mine.

But I would like to clarify just a couple of concepts that should have been clear in my previous posts.

Well...

> Hi Marco, so I know these are case studies for your own experiments but I should mention
> that optimizing entirely for surface control point count can come with negative side effects

My intention is absolutely not to model "everything" and "always" with some, good or not, manual techniques to
minimize the control points count.

What I'm trying to do is to gain experience with a bunch of techniques that in some particular situations could help me to
work with minimalist and lightweight models, in order for example to create lightweight assembly.

> like increased modeling time and some decrease in model accuracy since the new object now deviates from a true offset surface by some unknown amount.

As I pointed out in my previous posts, my intention is to use the manual techniques only when I don't need the extreme precision
that, for example, a standard Offset or Shell command can offer.


> 74KB...42KB

The model I uploaded it's only a tiny example but with a big assembly or a very complex model I bet that
we could experiment a non-negligible difference.

Anyway, I wish to thank you for giving me the chance to better clarify my "case study" (why and for what).

Best,

- Marco (mkdm)

Hi Marco,

> My intention is absolutely not to model "everything" and "always" with some, good or not, manual techniques to
> minimize the control points count.
>
> What I'm trying to do is to gain experience with a bunch of techniques that in some particular situations could help me to
> work with minimalist and lightweight models, in order for example to create lightweight assembly.

Certainly, that can make sense for those particular cases, although it may need to have a pretty high repetition count for it to make a very noticeable difference.

I'm sorry I didn't say in a better way that my comments were not really targeted at you, more at others who could easily view this as a tutorial on how to best create surfaces in general and then spend a lot of time doing this on every single object that they create.

A kind of hybrid approach for this type of object shape would be to offset just the generator curve and then revolve that along with the original curve, that will make a lighter surface than the one that uses surface offset since it will only have the offset density in one surface direction but still give very high accuracy.

In the future it might also be possible for MoI to make procedural offsets rather than generating fitted NURBS surfaces for the offset command, one reason it does not do that currently is so that all surfaces can run through a single general display routine rather than needing to have special cases.

- Michael

Hi Michael and good morning.

> I'm sorry I didn't say in a better way that my comments were not really targeted at you,....

Michael, first of all I want to say you that I never had any problem with your comments on my posts in general,
and also regarding my "case study" !! :)

I always greatly appreciate any of your suggestions and I value them a lot.

These experiments are clearly my own personal practicing, and I never thought to tell anyone : "Hey guys, I've found the perfect modelling technique! Follow me!".

I want simply to become more skilled in Nurbs modelling (curves and surfaces),
and if someone thought that my results are good, I will be happy to share them.

> A kind of hybrid approach for this type of object shape would be to offset just the generator curve and then revolve that along with the original curve...

This is exactly what I'm doing. Working first of all on CURVES.
But not limited to the Revolve situations. Often I need offsetted surfaces but not simply revolved ones.

> In the future it might also be possible for MoI to make procedural offsets...

This is really a GREAT news!!

Thanks again for all your suggestions and best wishes for all.

I'll keep doing experiments on other "case study for a lightweight modelling" :)

Best,

- Marco (mkdm)