Hi Michael G. I am getting crashes when trying to open or import .sat file with this beta. Sept. works fine. Attached is the error report.

Thanks,

Michael T.

Cool... Thanks..

Will announce this on my site as well..


Peace,
Rich_Art. ;-)

"""""""""I am getting crashes when trying to open or import .sat file with this beta."""""""""""

Confirmed here too. I wont send the report unless asked for it....

Hi Michael T, and Burr yeah it looks like all of STEP, SAT and IGES is busted, as an unintended side effect from the periodic surface update. It should not be difficult to fix and I'll roll out a new release today.

Thanks for the report.

- Michael

Thanks Michael G. The DXF export works well!

Michael T.

Hi Michael T and Burr, I've rolled out a new Nov-6 version which should now fix up the SAT/IGES/STEP format crashes, you can get it from here: http://moi3d.com/beta.htm.

- Michael

Hi Martin, thanks for posting the DXF file.

> It looks like MoI isn't recognising the units setting in some imported dxf's from other programs,
> and so is switching to the No unit system - could that be adjusted at some time? Sample
> attached.

This is unfortunately a problem with DXF format in general - Autodesk in their wisdom did not see fit to make an official mechanism in DXF to label what units all the coordinates in the file are using.

There is a "kind of" way to label them, which is a particular AutoCAD variable called "$INSUNITS", which controls what unit system to convert into when inserting blocks from other files. That's the closest thing to any unit system setting in the file, and MoI will look for that variable if it's declared in the header section of the DXF file and use it as the unit system if it's present.

But that's somewhat obscure and many programs just don't write any header section at all in the DXF file, the file you posted is one of those with no header section and so no $INSUNITS variable set, and so nothing in it marking any kind of units at all.

I tested your same file with both Rhino and ViaCAD and ran into the same problem in each of those as well - in each of those other programs if I say set units to inches and then import the file you posted, each of those programs just interprets the coordinates in the file as in inches.

What program are you using to generate this DXF file in the first place, is there possibly any option to enable setting $INSUNITS to be output into the file? If so then that would help make units come across into MoI and also Rhino too.

What happens in the same program that you're using if you set units to inches and then try to import or merge the contents of your file back in again, does it know the units of its own generated DXF file in that case? I would think that you'd see the same problem there.

As far as I know the only real option that I would have for a file with no $INSUNITS set like the one you posted is to pop up a dialog box that asks you what units the file are in, right now it just uses "No unit system" when there are no $INSUNITS present.

- Michael

Thanks Michael G. So far so good. SAT and STEP look okay. Will try IGES next.

Thanks again Michael G for such an incredible tool!

Michael T.

"""""""I've rolled out a new Nov-6 version which should now fix up the SAT/IGES/STEP format crashes"""""""""""

Fixed......

Hi Michael T,

> Thanks Michael G. The DXF export works well!

Great! I hope that will be useful, this should totally replace needing to use that other separate 3DM to DXF converter. Also this new version does a better job, doing things like converting lines, circles, and arcs into those kinds of simple object types in the generated DXF file.

There are also a couple of additional settings available in moi.ini for controlling the DXF output, under the [DXF Export] section:

[DXF Export]
UseSimpleEntities=y
NumDecimalPlaces=12


If you set UseSimpleEntities=n it will turn off exporting lines, arcs, and circles as those simple object types and instead export them all as spline object types (or polylines if you have set to export curves as polylines in the export dialog).

NumDecimalPlaces= sets the number of decimal places to use for storing numbers as text in the DXF file. The default of 12 is already quite a lot of precision, but you could bump that up to something like 16 places if you want, it will also make a larger file size as well though.

- Michael

Michael.

I fear I might have had you on a wild goose chase there.

I'm 100% sure that file originated in ViaCAD. However, I do (now) remember taking it into Ucancam (a CAM program) and working with it there. I must have re-exported and lost the Unit information from within Ucancam because dxf exports from ViaCAD seem to come into MoI with their Unit details intact - so this is definitely my mistake and not an error made by MoI.

Sorry for putting you to unnecessary extra work, I'll try to pay more attention to what I'm doing in the future.

Thanks for your reply - enjoying the latest features :-)

Martin (2).

Hi Martin, no problem - I'm still not entirely sure what I should do for this kind of case where there is no $INSUNITS value set inside the DXF file, I guess the choices are that I could take it as "No unit system" which is what happens currently or the other choice is that I could pop up an additional dialog box that asks you what the units are and relies on you to happen to know the answer.

It sounds like this might be a nice improvement to ask for from Ucancam though, to write this particular $INSUNITS header value with the units setting out when they generate a DXF file, so that their DXF output would go into other programs with a units setting intact.

- Michael

Michael.

I'll certainly ask them at Ucancam, but interestingly, they use a pop up on import.

My view is that a Choose Unit pop up might be best, where they aren't embedded in the import file. The user then has to make the decision and wouldn't be put in the position of being puzzled by the lack of displayed units in MoI.

Even if the wrong units are picked, the user still knows which system he's chosen and can then scale the drawing accordingly - well at least that would work for me :)


Cheers.

Martin (2).

I ran into a little problem here with the latest beta from November 6th:
I have a rectangular flat box with many circles booleaned out (think metal sheet with ventilation holes).
Now I want to fillet the edges of the holes on one side only, but seem to be unable to select the edges.

Went back to the last Beta and had no problem whatsoever selecting those edges.

I'll test some more later but for now I'm back to the September Beta.

Cheers,

Tom

New v3 beta Nov-6-2012 IGES appears to be okay now as well.

Thanks again Michael G!

Hi Tom,

> I have a rectangular flat box with many circles booleaned out (think metal sheet
> with ventilation holes).
> Now I want to fillet the edges of the holes on one side only, but seem to be
> unable to select the edges.

Can you please e-mail (moi@moi3d.com) me the 3DM file with these problem edges in it so I can take a look at what's going wrong there?

I tried to reproduce the problem with my own box and circles booleaned out but I couldn't get it to misbehave, so it may have something to do with the particular model file.

Thanks, - Michael

Hi Michael,

Thanks for the new beta.

Do you think it's possible to disable antialiasing completely ? or does it introduce some problems in the moi selection mechanism ?
The mean reason is to have better viewport perf ;)

Hi PaQ,

> Do you think it's possible to disable antialiasing completely ? or does it introduce some problems
> in the moi selection mechanism ?
> The mean reason is to have better viewport perf ;)

Just disabling anti-aliasing without actually changing how the drawing is done would not have any effect at all on performance because it doesn't really make much difference whether the video card is drawing textured polygons or untextured polygons, the fill rate on video cards these days is not a bottleneck at all.

It could possibly have some probably small impact to switch to draw line entities rather than sending polygon entities to the video card, but that's not exactly a minor change and still even then it's unlikely to have much effect because the process of breaking down curves into line segments would still be the same as before.

The main thing that could have a more significant effect would not be disabling anti-aliasing but by using fewer line segments to do the drawing, that would make the display not non-anti-aliased but instead more angular-polyline looking. I've experimented with that some with some of your own models, but just tweaking the current code to produce fewer line segments for each display bezier does not have much impact on many heavy models, instead it would need to work by dividing more of the entire curve into lines instead of going from the full curve to beziers first and then breaking down the beziers as the current mechanism works. So again that's a fair amount of change in order to have that option, and trying to work on full NURBS curves is not as fast as working with beziers, so it would probably have to try to divide it in 3D space only instead of doing it in screen space dynamically, and also that would probably mean caching the 3D polyline data, increasing memory consumption... (although I guess it could then not store beziers in that mode so that might be about the same for memory consumption as long as the polylines were somewhat coarse).

So there are some possible things to experiment with in the future but I've already done the "low hanging fruit" experiments and found little impact in things that are relatively easy to tweak without significant changes to the overall approach.

But I did make some major progress with display performance (not in all situations but in a lot of them) a couple of betas ago with the use of multiple cpu cores being used for the display engine now. Quite a bit of work went into that already, and currently I don't expect to do much more work on display performance through the rest of v3, the only things that I really know that could be possible now would involve degrading the display quality quite a bit. Like for example having all curves and edges display as jagged polylines that are fixed as 3D line segments will look really bad especially as you zoom in anywhere. But that's probably the main thing left to experiment with.

- Michael

Michael.

Because we're beta testing at the mo', it's easy (for me) to confuse v2 and v3, so would it be a good idea to change the logo in the upper right corner of the screen from plain old 'MoI', to 'Moi v3', or something, so as to differentiate between the old and the new? Adds a bit of bling, too ;)

Now I'm looking up there, I'm wondering if you could use that logo box as some kind of icon for, say more tools, or accessing scripts etc - nothing particular in mind, but it looks conveniently placed, whilst being far enough out of the way that it shouldn't be dangerous.



Martin (2)

Hi Martin, personally I like the minimalism of just plain "MoI" up there instead of any additional labels. But if you wish you can change your installation to have whatever label you want by editing the file SidePaneTitleBar.htm inside the \ui folder, on line 9 change the text that says MoI to MoI v3 or whatever.

That area is actually used currently for a debug menu that will be triggered if you hold down the Ctrl key and click on it, and also if you double click on it that's another way to un-minimize the main window, making it act similar to the title bar on a regular window (it's an old Windows shortcut that double clicking on a title bar does maximize/restore).

It's probably a bit too non-discoverable to use for very much stuff though, because it's more of a title looking thing and doesn't really look like a clickable control. I definitely want to have some way to organize scripts better in the UI, but I would want to have that as a more discoverable button actually labeled "Plugins" or "Scripts" or something like that which would pop up a menu, not quite so hidden.

Hopefully under normal circumstances you should be able to just run everything in the v3 beta rather than v2, but yeah I can see how you haven't been able to do that so well with the inset problems that I'm still working on tuning up. Those stem from updating the geometry library which can be one of the more disruptive types of processes that I have to go through. Once I've tracked down that remaining Inset bug is there any other reason why you'd be working in v2 rather than v3 all the time?

I mean it is good to be able to have v2 around also just in case there is something messed up in v3, but the main goal is to actually get v3 fixed and suitable for regular full time use all the time through the entire beta process. When I update the geometry library, that's one of the things that can tend to throw things a bit out of whack for a little bit though until the kinks are worked out.

- Michael