Is there a way to make Moi as fussy as other software? There are times I build something in Moi it says it is a solid but then I export it to Rhino or some other software and it shows errors. Can I change some settings in Moi so that it is consistent with other software?

Thanks

Val

Hi Val - does this happen with any kind of model or just one particular model that you are working on?

Like for example if you export a box out from MoI into the other program, does it say the box is a solid or not?

If it's something to do with your particular model I will probably need to see the model in order to give you some advice on it, you can either post the 3DM model file here or if you want to keep it private e-mail it to me at moi@moi3d.com

What specific errors are you seeing in the other program, does it really say that it is not a solid or does it complain about something else in particular like some tolerances or other issues?

Also what happens if you re-import the file you just saved back into a new session of MoI ?

- Michael

It's not so much a particular model that I am talking about. I can fix things by looking at the errors that Rhino sees and change them in Moi. I was just wondering if I can tighten up the tolerances in Moi so it's harder to make a solid? I was trying to figure out a way to use the deform tool as it seems to be the thing affecting the models. so lets say I bend something with the deformer, I would want it to be a set of surfaces (rather than saying it's a solid) that I could repair in moi without sending it out of the software to find the errors. Or should I just quit fooling with it and just build the object without the deformer?

Hi val,

> I was just wondering if I can tighten up the tolerances in Moi so
> it's harder to make a solid?

The tolerances it targets is already pretty tight - it shoots for an accuracy of 0.001 units. Is that particular tolerance target a problem for you?


> I was trying to figure out a way to use the deform tool as it
> seems to be the thing affecting the models.

It sounds like you're running into some kind of bug with the deformer. Do you have an example model that you can send to me so I can try to reproduce the deformation problem and work on a solution for it? In order to have the best chance at solving it I need to have the model in its state _before_ the deformation so that I can run the deformation on it and debug it to see what is going wrong with it, and test solutions.


> I would want it to be a set of surfaces (rather than saying it's
> a solid) that I could repair in moi without sending it out of the
> software to find the errors.

If the result of the deformation is mangled or out of tolerance in some way, then the solution is for me to fix the deformer code so that it generates a good result.


It would help a lot if I could see an actual example model that shows the problem you're having, particularly if I can reproduce the problem over here by being able to run the code that generates the bad model.

- Michael

Michael,


> The tolerances it targets is already pretty tight - it shoots for an accuracy of 0.001 units. Is that particular tolerance target a >problem for you?

the numbers aren't a problem. It's the fact that Moi says it's a solid but when I export anything done with deform not one other piece of software thinks it's a solid. This is clearly a bug in the deform. I attached a test. What the test shows is inside of Moi both objects are seen as solid but if you export both of them, lets say as stp files the deform object comes back with multiple errors in all other software packages. Moi is too tolerant. this is how I am using the word.

You did actually answer my question already though which is I can't tweak moi's tolerances. So I'm back to building things without the deform. Ah well... I will wait patiently.

Thanks

Val

Hi Val - in your test.3dm file I see one solid undeformed object, but I don't see what deformation you are running on it - is there some kind of base curve and target curve that you're using to deform it with Flow or something like that?

But I see you've got some sphere pieces in there - most likely you are running into a bug currently in the deformation engine that it does not process surfaces that have a collapsed down pole point in them such as spheres properly. If you zoom in closely to the pole of a deformed sphere you'll see it looks a little weird in a small area right near the pole point.

I think we actually discussed this a bit previously here? :
http://moi3d.com/forum/index.php?webtag=MOI&msg=4863.1

- Michael

Michael,

Sorry, uploaded the wrong file.

Yes we did discuss the aspect of the sphere and it's pole but I was asking a different question.

I was asking if I could modify moi to see the errors that other software sees as Moi doesn't see these errors. (clearly not)

What I was saying was if I could see the errors inside of Moi it would be easier to repair them than having to go outside of moi to look at the model and those errors.

You will also notice it isn't just the spheres that have the error but also the text is coming apart as well.

thanks

Val

Hi Val - if you're going to deform something like this into a closed loop, you will need to select the ends on the sides here:



And then delete those in your original object before doing the deform.

Right now you're keeping those caps in place and in your deformed result they end up being stacked up directly on top of each other making for a kind of internal double-stacked up wall at that spot on the resulting cylinder. That will probably cause problems in anything that tries to figure out how to process that model into a solid by surfaces.

You may need to do a Separate and then a Join again after doing this particular kind of rearrangement of topology in order to get all the edges of the result glued together.


> I was asking if I could modify moi to see the errors that other
> software sees as Moi doesn't see these errors. (clearly not)

I would like to add some diagnostics and analysis tools into MoI in the future.

It's not a particularly easy area to add though, it's hard to make stuff that's not overly technical and mumbo-jumbo-ish.


> You will also notice it isn't just the spheres that have the error
> but also the text is coming apart as well.

I'm not immediately seeing how the text is coming apart - are you sure you're not just seeing some of the visual bleed through of some other edges? When edges are displayed they are pulled forward towards the eyepoint so that they don't get all submerged underneath the surfaces - if you have thin walled pieces then this pull forward mechanism can tend to create some display artifacts where edges from some of the back pieces of the thin walls can bleed through. It's just a display artifact though and does not mean that your actual geometry is bad there.

I opened your file in Rhino and did an Explode on an it an then a "SelBadObjects", and only the 4 sphere pieces select as having any problems with them (which is that pole problem that we've discussed previously), nothing involving the text seems to be problematic there.


But for export to other systems it's not good to construct a result with internal overalpping end cap pieces like you've got here - that has a lot of potential to confuse things especially for IGES transfer where it just transfers surfaces and then the receiving application has to try and figure out how the surfaces should be joined together but that is not clear anymore with the internal doubled end caps.

- Michael

Just to help clarify what I mean by "internal doubled end caps", you can see them if you select the outer cylinder surface and delete it:



Then these are the internal walls that I'm talking about:



There are 2 of those right there, one for each side end of your original surface.

You don't want to have that kind of thing inside there.

- Michael

Actually I guess you've got a little tiny bit of space there between the ends, but it's really pretty small - it would be better to either have a larger gap or make no gap and not have the caps.

I've looked a bit more closely at your text now and I can't find any problems with it falling apart, I'll probably need to know which particular area you're talking about for that problem.

It's a bit easier to see the text by deleting the outer surface like in the above image and then looking at it from that outer side rather than from the inside. Or also you might want to temporarily hide all edges (go to the Scene browser Types section and click the eye icon next to Edges to hide them all) so that the edge bleed through doesn't get in the way visually for that particular stuff.

- Michael

Michael,

This really isn't my issue.

My issue is that Moi sees the deformed shape as a solid (when no other software does).

When I export that solid to another piece of software the next piece of software finds a problem. If I can't tell in the Moi there is something wrong then it's a problem for me. It means I can't trust that aspect of the software, which means I can't send the file on to other people because they don't use Moi.

What I need is for Moi to see the same thing as other pieces of software.

So if moi says it's a solid then I would hope other pieces of software would see it as a solid. If moi sees it a series of surfaces then I hope other pieces of software see it as a series of surfaces. I don't care what it is (a set of surfaces or a solid) I just want it to be consistent.

What I uploaded is a demonstration of moi seeing both, the deformed and the undeformed, as both solid. but when I export the file and open it up in other software. The other software sees the deformed one as an incorrect open model.

Make sense?

thanks

Val

Michael,

I'm attaching what I see in Rhino when I import the file as a STP.
The sphere pole errors are there and the letters are not lining up either. When I import the file as a 3DM into rhino it's fine. so there is something going on in the translation to STP from the Deform because this doesn't happen on the un deformed model when it is exported as a STP.

Thanks

Val

Hello,

If this helps this is what it looks like when opened in SCE 2011+. The plate imports as a solid, there are some curves and there seem to be two holes in the outside wall of the ring. Once the holes are closed using the Repair Missing Faces command the item becomes a solid, but not a closed ring, it capped that micro gap internally with two faces to make sort of a ring with a micro split. There are inexact edges according to SCE, but I think that's a tolerance issue, nothing that is preventing the generation of the solids. What is interesting is that the file provided has the two internal faces of that sphere but not the outer ones.

I have kind of run into this too. When I sent our engineering dept simple extrusions to open with Inventor the other day they had to play with the import options for a while. This is what I was told.

"With the default setting the geometry imports as surface data. If I turn on the Auto Stich and Promote options prior to import, they import as individual solid bodies."

I don't know anything about Inventor (or any other solid modelers than MoI) but I would just assume a solid in one program would be a solid in another. Maybe it's more of a problem with Inventor than MoI.

Hi val,

> My issue is that Moi sees the deformed shape as a
> solid (when no other software does).

This is not correct though - if you load the exact 3DM file you posted into Rhino v4 and then select your deformed object, and then run the "What" command, it reports that the object is a:

"Closed solid polysurface with 232 surfaces."


So Rhino definitely sees it as a solid as well - it uses the same definition as MoI where a solid is an object that has every edge joined between 2 surfaces.

However, there are some glitches in the model in the pole areas in the deformed spheres, and some other programs when you do the import into them by STEP format or whatever, will probably try to analyze the object and make sure that it's actually structurally sound and they would then probably see that there is a problem with those areas.


> What I need is for Moi to see the same thing as
> other pieces of software.

Yes, like I mentioned previously I would like to add some kinds of diagonistic and analysis tools into MoI in the future. It is not an easy area to add though because it's a difficult thing to do a good UI for without just giving some highly cryptic feedback like "Error number 252".


> So if moi says it's a solid then I would hope other pieces of
> software would see it as a solid.

This is happening already with importing it into Rhino.


> If moi sees it a series of surfaces then I hope other pieces
> of software see it as a series of surfaces. I don't care what it is
> (a set of surfaces or a solid) I just want it to be consistent.

I myself can't control what additional processes another program does to their imported geometry.

Most likely your other program is doing some kind of analysis of the imported object and deciding that although it has all edges joined it is not a proper solid and so decides to break it apart into surfaces instead of keeping it as a badly formed solid.

That's something that the other program is doing during some of it's processing, I'm not in direct control of what that other program decides to do.


As far as I can tell though, the root cause of your problem is like I've mentioned before that there is a bug in the deformer when deforming those sphere surfaces that have a collapsed down pole area in them. The deformed spheres are mangled in the small area near their poles.

Different programs may respond in different ways to mangled geometry.

- Michael

Michael,

Right, I said that already, if you load the 3DM file into Rhino it's fine but not everyone is able to view 3DM files. I need to export out a generic solid file. So if you export out a STP (from Moi) file the result is the screen grab that I posted. If you export out a STL file you will not get a water tight object and needs to be hand repaired. So yes the rhino screen grab that I posted is correct (I didn't fake it).

I'm not interested in diagnostic tools in Moi. I really like your approach to your software. It's why I use it. I think it's brilliant.
Simple, direct, uncluttered with specific tools. It really is a wonderful product.

I have said this already but I will say it one last time then I give up.

If you export out the un deformed object in any format every single package can read it as a water tight solid.
If you export out the deformed object in generic formats other packages come back with an error.

It's that simple.

There is something happening with your exporters and your deformer. There is no other possible answer.

You asked for people to report bugs. this is a bug.

thanks

Val

Hi val,

> I'm attaching what I see in Rhino when I import the file as a STP.

The best way to move geometry from MoI into Rhino is to use 3DM format.


> so there is something going on in the translation to STP from the Deform
> because this doesn't happen on the un deformed model when it is
> exported as a STP.

That seems to be some issue with Rhino's STP importer - it must be deciding that those edges are not accurate enough or something like that.

Again, I myself do not have direct control over additional things that another program may decide to do to change objects when they import stuff in. Some programs may have some options to control their behavior about changing things, like some programs have options to "heal" geometry, which can be turned on or off, it's not unusual for that of additional processing to make things worse instead of better.

But you will certainly have problems with the sphere pieces going into other programs, those pieces are indeed mangled.

In the attached files I've modified the object to have the mangled sphere pieces removed and to make the gap between the end cap pieces a bit larger instead of barely skimming right over each other.

The attached STP file generated from that cleaned up object reads into both ViaCAD and Alibre as a solid, and MoI is also able to read it back in from that STP file as a solid.

There does seem to be different behavior in Rhino's STP import, that could be some kind of bug or limitation of some sort in the Rhino importer, I'm not sure why Rhino behaves differently than other programs in this particular case, you would probably need to contact them to find out more details about that behavior.


As you can see here, different programs may do different things with imported data.

Your request to make MoI work the same as all other programs doesn't really make sense because the built in assumption there that all other programs behave in one uniform way is not correct...


- Michael

Hello,

I'm curious what package your using to load in the STEP. I loaded your test file into MoI, exported to STEP, and directly opened the STEP file in SCE 2011+. It actually produces a better result than trying to open the 3DM file in SCE. Both items are solids on import, no repair required.

> I need to export out a generic solid file.

You're going to need a non-mangled object in order to do this.

I've gone over this a whole lot of times already, but the root of your problem here is that the deform tool has made a messed up object out of those sphere pieces.

If you try to transfer the resulting messed up object into other programs, yes you are going to run into problems with it. You will have to remove those 4 deformed sphere pieces and construct them with some other technique in order to make a proper model which can then be exported to other programs.

Above I attached the result of doing that, and the resulting STEP file imports into both Alibre and ViaCAD as a solid.


> So if you export out a STP (from Moi) file the result is the screen
> grab that I posted. If you export out a STL file you will not get a
> water tight object and needs to be hand repaired.

Yes, again as I've written a bunch of times already this has to do with the mangled sphere pieces.

You are not going to be able to generate a properly formed STL file from the deformed sphere pieces, the surface or trim edges are messed up enough right in the pole spot and that will cause some kind of overlapping or otherwise messed up triangulation right in those spots.

Try exporting an STL from the above file where I've removed those sphere pieces instead.


> So yes the rhino screen grab that I posted is correct (I didn't fake it).

Yes, I do also see that there is some problem in Rhino's STP importer with handling the text. That problem seems to be something particular to Rhino's importer, I tried both ViaCAD and Alibre with the above file that has the sphere pieces removed and got solids into those programs.


> If you export out the un deformed object in any format every
> single package can read it as a water tight solid.
> If you export out the deformed object in generic formats other
> packages come back with an error.
>
> It's that simple.

Yes, as I've explained numerous times the deformed spheres are messed up and you are not going to be able to get a proper transfer with that messed up model - you will need to remove those particular pieces of the model and construct them some other way in order to get good geometry that can then be exported properly.

In the file above where I have done that, the resulting STP file can be imported into other programs (other than Rhino) without errors.


> There is something happening with your exporters and your
> deformer. There is no other possible answer.

Yes there is definitely a bug in the deformer with processing surfaces that have a pole in them. We've discussed that numerous times here and even in a previous discussion thread.

I don't see where the bug is in the exporter for this case though, as long as you don't try to export the mangled sphere pieces it looks like the export to other programs aside from Rhino is correct.

- Michael

Michael,

Yes I know you have said it many times but then you go off in some other direction which isn't what I'm talking about So I then try to bring it back.

Just to clarify,

I have no interest in the the test model other than to show what is happening.

I know the model is mangled and that you have stated it and I have stated it as well. the whole point is that the model is mangled. It is mangled because of the use deformer and the exporters. But I can't know that the model is mangled until I import it into some other software. if it is mangled the Moi should say that it is (as in saying it is a series of surface and not a solid)


I have no interest in Rhino per-say I was just using it as an example. I send out my models to people who are using solidworks. They complained about the models failing. So I have no interest in importing files into Rhino as 3DM files as that is not what I'm up to.

So it must also be Solidworks STP importer as well that has a problem
I also get problems with Freecad and importing the STP
I also get problems with 123D importing STP


I have in other files removed end caps and joined them I can go through and fix the files by hand. i know how to do that. but this is all beside the point.

I'm not asking for Moi to work the same as other software. I'm asking that when I export the file the file behaves correctly on export.

I originally asked a simple question "should I drop trying to use the deformer until it is fixed?" and it was answered by you in a round about way as "yes stop using it until it's fixed."

But then you have basically said there isn't anything wrong with it and it is all the other software packages importers that are wrong. which I am disagreeing with you about.

thanks

Val