Hi Michael,

You are right. They definately seem to be complimenatry to each other. Though a friend of mine uses Rhino and a product called T-Splines I think, which seems to be somewhere in between from what I can tell.

Thanks for the beta information as well. I look forward to V3. Will it have major innovations or more of a refinement of what's already there?

This may come across as a silly question, but how complex would it be to add say that T-Spline type functionality? Do you know the product I'm referring to?

And lastly, do you take requests while in beta? or do you know where your headed from your roadmap?

Cheers
Charles

Hi Charles,

> Though a friend of mine uses Rhino and a product called
> T-Splines I think, which seems to be somewhere in between
> from what I can tell.

Yup, that's kind of a hybrid or bridge type mechanism - T-Splines works with a SubD control cage but can produce NURBS surfaces instead of only producing polygons for output.


> Will it have major innovations or more of a refinement
> of what's already there?

Well, kind of a refinement I guess - I mean I want to put in quite a lot of new features, but at the same time it is a major goal to try and keep the basic essence of MoI intact as I add new features instead of it getting a bloated and complex feel to it.

So hopefully if all goes will it should get new tools and new capabilities but the overall feel should be more like a refinement and close resemblance to the current version instead of something hugely different.


> This may come across as a silly question, but how complex
> would it be to add say that T-Spline type functionality? Do
> you know the product I'm referring to?

Yup, I'm familiar with T-Splines. So basically T-Spline modeling _is_ SubD modeling, just that it can produce NURBS surfaces as the output. But all the toolset for how you make T-Spline models and stuff like that is all the same as a SubD modeling toolset. And the thing is, the tools that make up a SubD toolset are fairly different than the tools that make up a regular NURBS modeling toolset, like I mentioned before the overall strategies and how you do things are fairly different between these modeling styles. So adding in "T-Spline" support into MoI is not about adding in just 1 thing, it would be about adding in an entire different toolset and modeling approach containing a whole variety of different tools with it.

So that's quite a large amount of work to implement an entirely different modeling paradigm within the same software especially without adding in UI bloat and complexity. It may be something that's possible in the future at some point, but there is still quite a bit of stuff in the regular NURBS world that I want to add in still, and I don't really want to go off in some completely different direction too early before MoI's current toolset gets further refined.

> And lastly, do you take requests while in beta?

Yes, definitely! In fact the beta is generally guided by requests and feedback and not so much by any exact predefined plan.


> or do you know where your headed from your roadmap?

Well, I do have quite a few ideas that are shaped by all sorts of previous requests and feedback.

Of course combined with feedback I also have things like feasibility and amount of work required for particular things, so for example if some requests would require several years of full time work for me to implement, it will probably will not be able to happen anytime too soon.

Another thing that tends to happen is requests that would require significant new UI design tend to get done more slowly (adding in T-Splines for example would fit in this category), and on the reverse requests that can fit in well and add functionality without adding a lot of UI tend to get the highest priority.

- Michael

Hi Michael,

Wow, thanks for your honesty, it's quite refreshing.

And thanks for the explanation regarding T-Splines. I didn't realise it was SubD that produced nurbs, I thought it was a nurbs cage of some sort. Knowing that, I would agree with you that adding this feature would be confusing, especially considering what MoI is, and like you say it would be a huge effort to incorporate. I like the idea of maintaining MoI's current philosophy. What you have said makes total sense, and is logical.

I do have one question though, and btw let me know if I'm getting annoying :-)

When you have a solid, say a sphere, you can show points. However when you boolean the object with another, points are no longer available. I know there a reason for this, however would it be possible to show points on a booleaned object? See image below.


Show points.



Cheers
Charles

Hi Charles, it is possible to show points for a booleaned object, but when you do so you'll probably see that the points are not as you are expecting.

To show points on your booleaned sphere, use Edit > Separate on it first to break it apart into individual surfaces, then show points will work on those individual surfaces.

When you do that, you'll see that the surfaces involved there are actually larger than the edges - that's due to the structure of how NURBS solids work, where when things are trimmed or intersected, the underlying surface stays the same and only new trim curves are created. Trim curves are kind of like markers that live on a surface and mark different portions of the surface as being active or inactive, making holes in it.

But the shape of the surface (and therefore what you would alter by pulling points around) comes from the underlying untrimmed surface and not the trim curves directly, except in the special case where the trim curves are the same as the full outer boundary of the surface.

MoI will not turn on control points when you've got joined pieces that do not have surface control points that touch each other because it would be too easy to create gaps and holes in the model since pulling the points around would just pull one part of a surface around and not pull the edges more directly.

This all is another big difference between NURBS and polygon modeling - in poly modeling the edges that you see are always the exact same thing as the edges of the surfaces involved, so pulling edges and pulling the surface are equivalent. With NURBS where you have a trim edge, that's a kind of separate thing from the surface and there is not the same concept of pulling around the edge directly.

However, this entire structure is also the reason why boolean operations work better with NURBS surfaces than they do with polys - with polygons when you do booleans the boolean code has to create a lot of little slivered polygons, and the more booleans you do the more dicing and chaotic little fragmented pieces are generated.

With NURBS surfaces on the other hand, when you do booleans and trimming the underlying surface itself stays the same and only new trim curves are calculated that mark areas of that surface as being holes. No matter how many cuts you do on a surface it does not fragment into a bazillion little shards like poly booleans do. And you can also do stuff like erase the trim curves to get back to the underlying surface.

See this FAQ answer here: Why does show points work for some objects but not others? for some more information and some illustrations about this.

- Michael

Hi Michael,

Thanks for the education. I've had a play with separating solids and re-joining them again after manipulation, and I've managed to came up with something quite complex that is a solid at the end. It's given me another methodoloy, which is always cool. More bows for my arrows so to speak.

Thank you sir, I will continue to play.

Cheers
Charles