Hi Michael.

Actually it was not in priority order, but UV nesting would have been my # 1. Glad to see that should be possible. The # 2 priority for me would have to be creating a single disjoint mesh object from multiple nurbs objects. In the future, i would imagine this could be done automatically by referring to groups or layers. But you've mentioned the layer management system hasn't been fully envisioned yet. So this might be a solution until then...

Also- Do you know that cancelling during an export will erase the existing file by that same name? This is potentially a very dangerous problem! Not sure if this happens suring a "save" but certainly does during export...

thanks,
jonah

> Also- Do you know that cancelling during an export will erase
> the existing file by that same name? This is potentially a very
> dangerous problem! Not sure if this happens suring a "save"
> but certainly does during export...

Whoa - nope, didn't know about that one. That's definitely not cool, thanks for reporting it!

This only happens if you cancel the additional options dialog (beyond the file name dialog), so it didn't come into play for saving .3dm files.

Definitely got to fix this one up, I guess I will put out another DLL patch after every few bug fixes like this.

- Michael

Just a little idea concerning meshing:

If you save a file as e.g. an *.lwo-file, the first thing moI does is to calculate the meshes based on the default setting of 12 degrees. After this is done, you are provided with the settings-dialog where you can refine your meshes.
I think it would be much better to first provide the dialog and then let the user start the process of meshing from there. This is because the way it currently works, you always have to wait for the initial meshing to complete even if you are sure you will need to customize the settings. On complex meshes this can result in a significant time to wait - definitely enough to get a coffee ;-)

Another nice improvement would be to provide a way to save custom mesh-settings as user defined presets. After all, meshing is not unlike printing and every decent printer driver should offer a way to save and recall settings.

Thanks cronbg, I've added these wishes to the list as well.

For the first one, I'm actually planning on making the meshing process interruptable which should solve that problem. It's just one of those things that I didn't quite get to for v1.

- Michael

Hi Michael.

I would also like to add one more thing - When using n-gon export with high threshold angle settings, there is a situation where vertices of the n-gon sitck out and cause a folding of the polygon face. Right now the only solution is to use a lower angle threshold (which drives up the poly count). Is there any way to pull those wayward vertices back in towards the connected faces without lowering the angle threshold (and thereby increasing the poly count)?

Thanks,
jonah

Hi Jonah, in general using a coarse mesh can produce artifacts that are hard to avoid.

But I'm not sure if I completely understand this particular issue from your description alone - can you please post an example that shows it off?

- Michael

Hi Michael. Here is a simple case which produce at least 3 wayward vertices if you set the threshold angle to 34.41. I've also seen where the vertex would actually fold the face backward on itself (I don't remember how i created that particular situation). It's easily fixable by increasing the tesselation. but these stray verts are not so easy to catch unless you really look for them...

jonah

Hi Jonah, I see what you mean now.

But those vertices are not exactly out of place - they are positioned on the surface and on the edge curve as expected. This is generally one of the kinds of artifacts that can happen when generating a very rough low poly mesh.

I guess what you would prefer in this situation would be for another subdivision to happen on those longer n-gons so that they match up better with the outer boundary. I may be able to add some kind of analysis to try and tune up situations like this, I guess it would involve some kind of measurement to detect significantly non-planar n-gons and divide them some more. But the tricky part is to find some measurement that is not dependent on a hard-coded distance so that it works on objects of any scale.

This artifact will happen only for certain angles, because you'll see it when the angle is right at some kind of boundary condition, like one piece of the surface is just barely within that angle next to another spot that is just outside of that angle, that leads to different levels of subdivision which causes this.

You can also use some of the other controls to try and produce some additional subdivisions to solve it - for example Divide larger than 2 units, or Aspect ratio limit 20 in this case, but that will produce some additional details elsewhere as well.

- Michael

yeah, it sort of relates to that discussion we had about "magnifying" the tesselation near extreme curvature changes... Are you planning to put in a control for max distance to surface, like Rhino's? I use that a lot to get nice results...

jonah

> Are you planning to put in a control for max distance to surface, like Rhino's?

I don't know... I've kind of been trying to not have too huge of a set of options but maybe I'll have to add this one in as well.

- Michael

Always very interesting to see some topics about meshing... ;-)

Can you please explain what UV nesting is ? It's not a familiar concept for me

Thx

Schbeurd

UV nesting would be a different way to handle the UV coordinates that are exported by MoI.

Right now it uses just a simple system where every separate surface in a solid gets texture coordinates that span from 0,0 to 1,1 - that's across the entire texture image.

So for example say you have a cube and you put a texture on it using the UV coordinates generated by MoI - each face of the cube would have an identical full image displayed on it. If you were to paint on a face to modify the texture map, you would see the same paint applied to all the other faces as well.

UV nesting would change this so that each different face of the cube would be situated in its own smaller piece of UV space. With each face having its own separate chunk of mapping space it means that each one is independent so for example if you were to paint on one face to modify the texture map, it would only affect that one face and the other faces would remain unchanged.

- Michael

Here is an example of UV nesting, exported from Rhino as OBJ into Modo. You can see that all 26 faces in the polysurface are sharing the UV space with no overlapping. this makes it much easier to deal with texture mapping. And yes, i know this is a heavily tesselated mesh but that wasn't the point!!! :)

jonah

Thanks,

It's perfectly clear now !
It's really a cool way to do the UV mapping for you ! ;-) Definitely something I'd like to see in MoI as soon as possible. So useful with texturing software that use projection painting, where you don't really need UV "continuity" (like Modo or ZBrush). You virtually don't need to edit your UV map by hand anymore with that option ! Maybe just scale or move some of the parts in the UV space...

Is there any way you can control it in Rhino (for example to force some parts to "stay together" ?)
Would such control be possible in MoI ?

Can't wait for it ! ;-)

> Would such control be possible in MoI ?

I don't know - it is pretty hard to imagine how to control that without a pretty elaborate UI...

Some programs can automatically calculate this kind of separation for you in their UV editors, for example I'm pretty sure someone has mentioned Blender can do it. But I'm not familiar enough with its UV editor to be able to give you the details.

- Michael

>> Some programs can automatically calculate this kind of separation for you in their UV editors, for example I'm pretty sure someone has mentioned Blender can do it. But I'm not familiar enough with its UV editor to be able to give you the details.

Yes, you can usually do that in UV editors, by selecting the parts you want to UV and where the seams will be. I was more thinking at some sort of "pre-process" during the creation of UV map with UV nesting. It's some sort of "lazy" solution... ;-)

mmm. lazy good. work bad... :)

I think you should already have a natural seam in the UV coordinates for all the polygons that make up each face in a solid. Like for instance when you have a cylinder, UV coordinates are not shared along the seam of the cylinder, only 3D points are shared there. I wouldn't think you should have to manually specify seams.

Anyway, it would definitely be more convenient to have this done automatically instead of needing to do an extra editing step.

That's kind of one of the additional nice things of using a NURBS modeler, since every NURBS surface has its own UV space you get a UV mapping for everything automatically.

- Michael

Hi Jonah, that file-overwrite-on-cancel bug you reported earlier in this thread is fixed in that latest patch update.

Thanks,
- Michael

very cool! thanks Michael...

jonah