Hi Larry,

re:
> Can we get staggered releases for 5.0 for Windows and MacOS, if 5.0 is ready for one OS earlier
> than the other?

They're built from a common code base in MoI v4 so they are ready at the same time. There usually isn't any separate porting process that needs to be done just for one OS. Not now anyway - it did take a lot of work to arrive at this state but it's infrastructure work that does not generally need to be repeated again.


> Also, if you perform improvements on importing in 5.0, can you please keep my step files on hand to test with as well?

Yup!


> The models I import to MOI are solids only, so closed surfaces.

So by "closed surface" I was meaning something like a cylinder surface that has a "seam edge" in it where the surface is closed in one direction. It's these kinds of surfaces that different CAD systems can have pretty different ways of representing trimming boundaries.


> I downloaded the trial version of CAD Exchanger and was able to convert the mould model to .3dm
> with that but it still did not import correctly in MOI 3.0. I've attached it.

Hmmm yes this seems to be quite a bit worse than the STEP import. There seems to be a lot of messed up UV trim curves being generated. I'll try to investigate it some to see if I can figure out why that is happening.


> If that's the case then I consider the issue resolved or a non-issue to begin with. Unfortunately, I cannot check and
> confirm that it's Meshmixer misrepresenting the edges of very thin triangles as a seam or cut in the mesh.

Can you please upload the .obj file for this one here? :



I can take a look at it to see whether there is any actual seam in there or if it's a really skinny triangle. It would be good for me to test with the same mesh settings that you used when generating it.


> I only used the 'Divide Larger than' on curved surfaces because it made no sense to also use on flat surfaces as
> well as it would just inflate the poly count needlessly.

It's just a way you can reduce very skinny triangles if those are undesirable for what you're doing. They're kind of hard to reduce without using a different triangulation method which would be a lot more time consuming.

Thanks,
- Michael

Hi Larry, re: .3dm file from CAD Exchanger not working better - does CAD Exchanger have any option in it for what version of .3dm it will write out? If so can you try writing as a Rhino v2 .3dm file? That may avoid what seems to be the problematic area.

- Michael

Hey Michael,

Again, thank you for all the time you've taking to extensively answer all the inquiries in my walls of text.

1. Hi Larry, re: .3dm file from CAD Exchanger not working better - does CAD Exchanger have any option in it for what version of .3dm it will write out? If so can you try writing as a Rhino v2 .3dm file? That may avoid what seems to be the problematic area.

A: CAD Exchanger lets you choose which version of Rhino .3dm to export as. The first time I converted the .step file to .3dm with it I defaulted to exporting as a Rhino 6 .3dm but when I tried to open that in MOI nothing displayed at all. So I then exported again but as a Rhino 5 .3dm and that's the .3dm file I attached to my last reply.

I've now exported the .3dm as a Rhino 2 one :



and it appears to import better in MOI for the most part. But there still appear to be artefacts:



And the 5 different components in the original .step file are regarded by MOI as the same piece, when imported from the Rhino 2 .3dm file. So if I use this approach, I'll need to export each component to its own .step file and then its own .3dm file individually.

Moreover, when I exported an .obj file from the Rhino 2 .3dm of the model, with all the solids merged into one, there were tessellation issues with the obj model :



I thought maybe this is because all of the solids got wrongly merged together into one upon conversion from .step to Rhino 2 .3dm. So I then opened the original .step file in 123D Design again, deleted the 4 quarter mould pieces and kept just the cage and only exported that as a .step file. Then I converted that .step file to another Rhino 2 .3dm file and imported that into MOI. However, the tessellation issues were worse now :



These are the settings I used to export that .obj, from the Rhino 2 .3dm file of just the cage, without the 4 additional parts inside :



Unfortunately, it seems I deleted the original, native .123dx save of the model, from which I exported the original .step file containing all 5 components of the model. I only retained that one original .step file so I can't try to only export just the cage as its own .step file directly from the native .123dx save, to then convert that .step file of the one component to Rhino 2 .3dm and import that into MOI to see if it would make a difference. I don't think it's likely it would.

MOI does see both the Rhino 2 .3dm of all 5 pieces merged into one solid as a solid (not a Joined SRF) and the Rhino 2 .3dm of just the cage itself as a solid as well, not a joined SRF. So I don't think that the issues are due to the .step files I am converting from themselves being corrupted or faulty in some way. Also, I take care when modelling to never do things which might be ambiguous to the software 123D software I use and result in non-manifold edges or non-watertight solids.

I uploaded a 7z archive of :

a) The original .step file with all 5 components, converted to Rhino 2 .3dm instead of Rhino 5 .3dm (mould.quadlobe.toy.rhino.2.b.3dm).
b) .step file obtained by re-opening the original .step file with all 5 components in 123D Design, deleting the mould components and exporting just the cage (cage.only.stp).
c) .3dm file obtained by converting that new .step file to Rhino 2 .3dm (cage.only.3dm).

You can get the file at : https://drive.google.com/open?id=1N3Ebs5gmhwbd-oZst1bFXpTeiDRpT4Dq .

All conversions to .3dm were done with CAD Exchanger as that's the only other software I currently have that supports importing .step and exporting .3dm.

2. It's just a way you can reduce very skinny triangles if those are undesirable for what you're doing. They're kind of hard to reduce without using a different triangulation method which would be a lot more time consuming.

A: Thank you. However, the skinny triangles are non-issue for me, as long as they're not redundant cuts. My only concern is whether those additional seams shown by MeshMixer are false positives or they are indeed actual cuts / borders between islands in the mesh. If they aren't actual cuts or borders, it's a non issue and I'll stop using Meshmixer to check for this since it would mean it's generating false positives.

If they are actual cuts in the mesh, it would be nice if they can be prevented in 4.0 but it's not really an issue if they can't be helped. As long as the redundant cuts on the top/center/tip of curved surfaces don't result in the normals of vertices along those cuts being parallel to the face normals of the respective neighbouring triangles they belong to rather than divergent from those respective triangles' face normals.

For instance here :



there's additional cuts between each of the triangles which share that one vertex, right at the tip of the circular spherical cap. Even if those extra seams / cuts are indeed there, as long as the normals of the duplicated vertices are the same between the duplicated vertices rather than divergent from each other and parallel to their respective triangles' face normals, the extra cuts shouldn't matter when rendering.

This does indeed appear to be the case but can't say for sure due to the small size of the triangles in question it's hard to say for sure whether flat shading is going on or not. It doesn't seem to be resulting in flat shading, that I can tell.

Even if this results in flat shading, that's not an issue on flat faces :



3. Can you please upload the .obj file for this one here? :

A: Sure. I've uploaded a .7z of them here : https://drive.google.com/open?id=1xwWi19v1ORaR0eN-MtpjuVJ56ffxnh-z . You can also download the .obj files of just about any of my impeller models from grabCAD and they'll show the extra seams on the bottom plane and on the tips/tops/centers of bulging circular surfaces or sphere caps.

The ones here : https://grabcad.com/larry.v-1/models?page=4 . You can also download the .step model of any of them as well.

This one here : https://grabcad.com/library/impeller-design-02-2-1 doesn't appear to be a false positive due to skinny triangles. I've uploaded both its .step and .obj here :

https://drive.google.com/open?id=1VRlXPAT2w7gAgpBk9cftSscmdqZ5r-8I

It's not a bid deal if this can't be helped. I'm only asking about it because it's triggering my OCD :)

4. I can take a look at it to see whether there is any actual seam in there or if it's a really skinny triangle. It would be good for me to test with the same mesh settings that you used when generating it.

A: I checked with a different model and it doesn't appear to be due to skinny triangles. That's the model here :

https://drive.google.com/open?id=1VRlXPAT2w7gAgpBk9cftSscmdqZ5r-8I

Generally, I use the settings shown above or values close to them. Depending on the complexity of the model and the triangle count of the resulting mesh. For instance, for 'Divide larger than' I normally choose .1 and for avoid smaller than I choose '.01~.02' but that would result in way too high a poly count for the model of the cage.

Sorry to be taking so much of your time with this minutiae.

Best regards,

Larry.

Hi Larry, so for the MeshMixer unexpected seam display, I closely examined your file impeller05.obj which was this one:



There is indeed a seam here:



There is no seam or "island separation" to be found in the other area you circled though. I tested this by isolating the bottom face in Rhino and pulling the points, each one is a single point connected to everything else and they don't pull apart. Here they are each one point that has a long edge coming from it pulled slightly to the outside of the original circle:



So there is no seam to be found at that spot, there is however some very skinny triangles and a particularly skinny one in that area. It is just quite skinny though, not reversed.

So my best guess is that MeshMixer does not like such skinny triangles, maybe it considers it within some tolerance of being non-manifold.


re:
> This one here : https://grabcad.com/library/impeller-design-02-2-1 doesn't appear to be a false
> positive due to skinny triangles. I've uploaded both its .step and .obj here :
>
> https://drive.google.com/open?id=1VRlXPAT2w7gAgpBk9cftSscmdqZ5r-8I

I took a close look at the flat face of impeller02.2.obj using the above process and could not find any seams other than the one horizontal one.



re: saving as v2 - that's too bad that wasn't without it's own issues. I tested loading in your cage.only.3dm file into Rhino and also saw various meshing artifacts in there as well, here's what it looks like in Rhino:



So the save as v2 won't be viable, it has a different kind of messed up UV curves. So the problem in the original .3dm file is that MoI isn't able to use the UV trim curves on cylinders, cones, and spheres special case type objects. That means it has to make its own UV curves but there's a bug in that process somewhere. When you do a "save as v2", those special objects are converted into regular NURBS surfaces which means that MoI is able to use the UV curves from the v2 file. But the conversion of the UV curves from analytic UV space to NURBS UV space is not very good in the OpenNURBS toolkit. The weird artifacts in both MoI and Rhino are because of poor quality UV curves.

I'll investigate some more to try and see if I can figure out why MoI's UV trim curve generator isn't doing too well on your original converted 3dm file. It looks like it's sometimes going in the wrong direction when the first or last points of the 3D edge curve are on the seam edge of a closed surface.

Thanks,
- Michael

Hi Larry, so I was able to find a bug in MoI's 3DM importer that was messing up the mould.quadlobe.toy.3dm import, that's the first one that you posted from CAD Exchanger in Rhino v5 format.

I've fixed that up so the next v4 beta will be able to import that file ok, thanks for reporting it.

- Michael

Hello Michael,

Thanks for the update! That's fantastic.

I've converted the problematic propeller model to Rhino 5 .3dm as well and testing I found it's likewise not importing correctly in 3.0.

Can you please test your latest v4 beta version with this one as well? I've attached it to this reply.

Thank you for your time and consideration.

Best regards,

Larry.

Works as solid for obj export in V4 ;)

Hi Larry, yup good news the same bug fix solves that one as well. Here's what it will look like in the next v4 beta with the bug fix:



Thanks for reporting it! I'm still going to investigate the step import some more but it is usually quite a bit easier for me to figure out what's going on with .3dm imports.

- Michael

Hi Pilou,

re:
> Works as solid for obj export in V4 ;)

Nope, it's not working in the current v4 beta, it just looks ok from that angle because the messed up part is on the bottom.

But it will work fine in the next v4 beta though.

- Michael

This ?

Hello Michael,

Thanks a lot for confirming! Can't wait for the release v4 release!

About that, will the release 4.0 version need to be installed over 3.0, in the same folder? As an add-on or expansion of sorts? Or will it be a separate installation?

If it comes as a separate installer which can be installed in a separate folder, if I install it over V3 would it retain the plugins I installed? I'm sorry if these questions were already asked and answered earlier in this thread.

Thanks for your time and consideration.

Best regards!

Larry.

Hey Pilou,

That's indeed where the import issue in 3.0 is and it looks similar to your screenshot from the current beta of 4.0 so it was probably the same issue as in 3.0.

Best regards,

Larry.

Hi Pilou, yes that's the problem area, it will be ok in the next v4 beta though.

- Michael

Hi Larry also I should mention that I'm hoping that the next v4 beta will be the last one and after that I'll switch to a very conservative mode trying not to make any more changes if possible to avoid introducing new bugs for the final v4 release. So if you have any other .3dm files that don't come across well now would be the time to send them to have a chance at getting them fixed for v4.

So far it seems that CAD exchanger .3dm transfer is working well other than this one particular bug though.


> About that, will the release 4.0 version need to be installed over 3.0, in the same folder? As an add-on
> or expansion of sorts? Or will it be a separate installation?

It's meant to be a separate installation, it's best not to try and install it directly in the same folder as v3.


> If it comes as a separate installer which can be installed in a separate folder, if I install it over V3
> would it retain the plugins I installed?

I'm not quite sure what would happen. It's best not to try and intermingle a v3 and a v4 installation directly over top of each other in a single install folder. It's intended that v3 and v4 should be in separate folders. Probably what would happen is you would have a v4 that worked and the current v3 installation would be broken. Many of the binaries for v3 and v4 have the same file name like MoI.exe, etc... so if you tried to put them in the same folder the v3 ones would get overwritten.

For plugins, most plugins are installed by copying them into the commands folder, you would just copy those from v3's commands folder into v4's commands folder. Also v4 now supports an additional commands folder located in appdata, outside of the main installation folder. It's good to put plugins there instead because then future versions will find them them there instead of needing to copy them around.

- Michael

Hey Michael!

It doesn't look like I have any more models which don't import correctly either as .step files or as .3dm files, after conversion with CAD Exchanger. From what I can tell, it looks like I'll be able to reliably use this pipeline going forward.

Thank you!

Best regards,

Larry.

Thanks Larry, that's great!

- Michael

Hey Michael!

Me again, just came across another .step model that doesn't import correctly as Rhino 5 .3dm in MOI 3.0. What's unusual is that the .step file appears to import correctly.

I'm fairly sure this is fixed in the latest beta of 4.0 but just thought I'd report it anyway.

Thank you!

Hi Larry, thanks for sending it. Yes that is indeed another case of the same bug and it will come in ok now in the next v4 beta.

- Michael

Will the next Beta contain the dimension tools?

Hi Rudl,

re:
> Will the next Beta contain the dimension tools?

Yes!

- Michael