Hi igor,

> and indeed Autocad sats work flawlessly

But if that is the case, then you should actually have a workable method currently - just import your model into AutoCAD first. The SAT importer in AutoCAD seems to work fine, at least when I tested with AutoCAD 2008, it did not seem to have any problems importing those SAT files you posted.

Then once your data has been imported into AutoCAD, export from AutoCAD to a new SAT file, and use this new file for importing into Revit.

If that still does not work, then you have a good example that you can send to Autodesk where saving from AutoCAD into Revit does not work. Just once you have the data inside of AutoCAD, save it as a DWG file and send that DWG file to them for testing.


> But what I also thought about is we might overcome this problem
> if MoI had 3D dwg exporter (in solids mode)
> (which in itself all the same write acis solids but then wrap it up
> into dwg..)

Unfortunately this is a quite difficult task - Autodesk does not actually publish any information on how the DWG format is structured. They have kept that private and actually done things to discourage other programs from trying to read and write to that format directly.

They do publish information on how DXF files are structured, but unfortunately only for basic entities like lines and circles, the ACIS 3D solid data is just labeled as a bug chunk of numbers that are labeled "proprietary data".

There is a library that may be possible for me to license in the future to help with reading and writing to DWG, but it is fairly expensive. And even with the library I expect for it to be quite a lot of work to tackle the problem, so I'm not sure when that may happen even with the library to assist.


Then also I'm not sure if I understand how this would help with transfer into Revit. Does Revit also allow for bringing in solids from DWG format as well as SAT? If so then you may try importing your MoI models into AutoCAD, then save as DWG and see if that DWG file goes into Revit better than the SAT data saved directly from MoI.


... I've just finished installing Revit which was pretty painful - 1.5GB download, and now I must reboot my machine... But it may help me to take a look.


- Michael

How sad for AutoCad! Lets see....EVERY other cad program imports the geometrey correctly EXCEPT REVIT and their response is "We handle it ok so there is no problem"?????

A great picture of how being too big can actually deminish your product. The response you got was obviously from a paid employee and not someone that actually cares about their product.

I suppose MG may have to let go of some stuff in the future! Hmmm, Contemplating a future MoI forum response in 40 years:

"Listen sonny, You young people..........." :O

Hi Michael,

Sorry you had to download that big.. Revit 2010 is a very sad example of how a good program is being screwed up entirely by Adsk. before 2010 we had beautiful interface and you only would download 350 mb.. now its 1.4gb. Whats there? who knows))

There's no workable method, unfortunately.. if you import sat into Autocad from MoI - Autocad is NOT ABLE to export MoI file to SAT at all..

To put things simple - Revit accepts all SAT files exported out of all known by me apps EXCEPT those exported out of MoI

This is kind of opposite of what burr saying)) and is also true..

And one more finding (as I stated above) - Why cannot I export MoI Sat file from AutoCAD(2008)? - there must be something wrong with the autocad exporter this time..

Regards
Igor

Hi igor,

> There's no workable method, unfortunately.. if you import sat
> into Autocad from MoI - Autocad is NOT ABLE to export MoI
> file to SAT at all..

Well, once you have imported it into AutoCAD, it is should now be AutoCAD compatible data in memory, it is longer really a "MOI SAT" file at that point.


But what do you mean exactly - do you mean that AutoCAD does not generate an SAT file at all when trying to do an export of that data? Or that the generated SAT does not transfer into Revit?

If it is the latter (SAT file does not go into Revit), then that would be a good example to send to Autodesk for them to reproduce the bug.

Save the data from AutoCAD as a DWG file, so that they will be able to easily reproduce the problem by loading the DWG into AutoCAD, generating an SAT from AutoCAD and then trying to import that SAT into Revit.

- Michael

Michael,

Thanks to Autocad I found a solution!!!

Sat File is not generated at all by Autocad, and if you save MoI sat as dwg - and then import it into Revit - you get the same result as if you would try to import SAT directly generated by MoI - shreres corrupted

Now why it happens and the solution:

Here's an extract from Autodesk white paper:

You can export trimmed NURBS surfaces, regions, and 3D solids to an ACIS file in ASCII (SAT) format. Other objects, such as lines and arcs, are ignored.

ARCS ARE Ignored!!! - (I suppose your .3dm have them!) so if sat exporter will somehow convert surface definition and use (maybe circles or whatever autocad uses for definition - see any sat by acad)? as a definition for spheres - or you change it within you 3dm then everything will work!!!

ps can we arrange something like that?

Thanks
Igor

yep that's autotake for you, they just make it difficult for everyone.

Rhino Import Translator Add-in for Inventor Coming Soon http://labs.autodesk.com/utilities/rhino_import/ I guess same will happen with Revit etc.

So hopefully MoI will benefit too (?)

also that may help.

http://hokcadsolutions.blogspot.com/search/label/Rhino

http://designreform.net/2008/07/17/rhino-autocad-revit-linking-complex-form-to-drive-massing/


>>>There is a library that may be possible for me to license in the future to help with reading and writing to DWG, but it is fairly expensive. And even with the library I expect for it to be quite a lot of work to tackle the problem, so I'm not sure when that may happen even with the library to assist.

Hi Michael Is the library you talk about the RealDWG ? http://usa.autodesk.com/adsk/servlet/item?siteID=123112&id=9078672
I have bad experience with apps like SolidWorks that uses the OpenDWG, it is not a solution IMO.
Also there may be a good work around.the .DGN file format and The Bentley/Autodesk Agreement
http://www.bentley.com/en-US/Corporate/News/Interoperability+Agreement/Autodesk+Bentley+Agreement.htm
http://pressreleases.autodesk.com/index.php?s=press_releases&item=436%3C%2Ftd%3E
So what I am thinking is since Autocad, Revit etc. reads and writes .DGN It may be a solution if MoI was to support just the DGN file format.
Bentley's OpenDGN Initiative http://www.bentley.com/en-US/Products/MicroStation/OpenDGN/

Hi igor,

> Sat File is not generated at all by Autocad, and if you save MoI
> sat as dwg - and then import it into Revit - you get the same
> result as if you would try to import SAT directly generated by
> MoI - shreres corrupted

Ah, well that is a good thing to send to over to Autodesk then that can help to show them the problem.

Send them a DWG file that contains that sphere in it as a 3D Solid entity, and tell them that when importing that DWG file into Revit it is missing in Revit.

That should help them to decide to take a look at it. They will be able to see that the DWG was written by AutoCAD so there should be no question that the file data itself is structured correctly.


> ARCS ARE Ignored!!! - (I suppose your .3dm have them!)

No, not in the files that you sent previously anyway - note that when it says: "Other objects, such as lines and arcs, are ignored." it is basically trying to say that "wireframe curve entities" like lines, circles, arcs, - meaning objects that are curve data and not solid or surface data are ignored.


> so if sat exporter will somehow convert surface definition and
> use (maybe circles or whatever autocad uses for definition -
> see any sat by acad)?

Yeah, the method that is used to store a sphere that was drawn in AutoCAD and saved to SAT is as a special "sphere-surface" entity in the SAT file.

Revit seems to handle those special sphere entities better than spheres that are saved as a general "NURBS surface" type entity.

I've asked the author of the SAT export library that I used if it will be possible to add a feature to export spheres using those special sphere entities, which may help to get this stuff working (I mentioned that in the previous message here).

- Michael

Hi neo,

That's great news that there is a Rhino importer coming for Inventor. Yes that should benefit MoI as well since MoI uses the same 3DM file format.

I hope they do implement that for Revit as well, that would certainly be a big help.


> Hi Michael Is the library you talk about the RealDWG ?

Well, actually I was talking about OpenDWG. I took a look at RealDWG and the licensing terms were not going to work out for me, too many restrictions and things like approval of the product was needed. So that only really leaves OpenDWG for what I can use.

But the whole thing is such a messy area to work with, that I may just not really be able to support it at all, I'm not really sure yet.


> It may be a solution if MoI was to support just the DGN file format.
> Bentley's OpenDGN Initiative

I'm not sure if that would work or not - does OpenDGN support general trimmed NURBS surfaces and solids?

I would like to check if it did, but the file format specification does not seem to be openly downloadable with a public download link. It says "To access the V8 DGN specification document, certain conditions must be met:", and there is some mention of faxing a request form to get the specification which seems really quite odd to me for an "open" format.

That's already making things more complicated than necessary, not really a good sign!


Maybe in the future when I have opened things up so that third parties can extend MoI more easily with import/export plugins, someone with more patience than me will be able to develop a plugin for some of these things.


- Michael

Hi Igor, after jumping through a couple more hoops (I had to switch to retail DirectX runtime, Revit makes an invalid Direct3D API call that triggers a breakpoint with the debug DirectX runtime!) I finally got Revit running over here.

I ran several tests and for the general cases, it seems that sphere transfer goes through pretty well. None of my quick tests had any problems, here are some screenshots in MoI and in Revit:










I also attached the 3DM and SAT files here as spheretest.zip, if you want to try the SAT exports yourself.

It kind of looks like Revit may try to split the spheres into 2 half pieces on import, so probably there is some bug for the very particular arrangement of your sphere in your previous example - you happened to create the sphere in such as way that the closing "seam" edge of the sphere was running right along the same area as the edge of the box.

That particular arrangement of edges seems to have run across a bug in Revit - it looks like if you try to avoid positioning your sphere in that one particular way you should be fine....

If you see a sphere getting positioned with its seam directly along the other solid's edge, try drawing the final point for the sphere in the "Top" view instead, or possibly you may need to select the sphere and rotate it 90 degrees (in v2 there is a quick way to do that in the Top view as well by using the new edit frame rotation grip), to avoid having the edge in the position that Revit does not like.

At any rate, since my initial quick tests (as attached) did not run into any difficulties, it does not look like there is a problem with every single sphere going over (which is what I thought previously the bug you were reporting was about), it is something to do with the edge structure in your particular model.

- Michael

Hi Igor - also note that it appears that the reason why your previous example from Rhino worked was that you happened to have the "seam edge" of the sphere in that file located in a different place than the one that causes a problem with Revit.

Your previous file RhinoCreated.3dm looks like this:



While your previously posted file MoICreated.3dm looks like this:




Note the different placement of the sphere's "seam edge" (indicated in red) between those 2 examples - for whatever reason Revit does not like the placement that you used in the second example.

It is this difference that explains why you were getting different results between exporting from MoI or from Rhino - it did not really have much to do with SAT options, it had to do with the seam placement.

If I take your file "RhinoCreated.3dm", and open it with MoI and write an SAT file out from MoI, that SAT file then goes into Revit fine:



So try to be aware of where that seam of your sphere is placed at, and try to avoid placing it right along the edge of the object it is being booleaned to and that should hopefully avoid the problems in Revit that do not handle that arrangement of edges well.

- Michael

>>>But the whole thing is such a messy area to work with, that I may just not really be able to support it at all, I'm not really sure yet.

although will have been great to have in MoI, you are right to say is such a messy area, Perhaps is wise to forget about it, at list until autodesk sorts it out, if they ever do.

>>>I hope they do implement that for Revit as well, that would certainly be a big help.

I think they Should, Rhino+Revit is a common combo in AEC...

>>>I'm not sure if that would work or not - does OpenDGN support general trimmed NURBS surfaces and solids?

All I can tell Microstation is a robust modeler which runs on Parasolid Modeling Kernel...I'm not sure if that is any help.

>>>Maybe in the future when I have opened things up so that third parties can extend MoI more easily with import/export plugins, someone with more patience than me will be able to develop a plugin for some of these things.

By saying opened things up, do you mean SDK?
In which Version of MoI you think you may releasing a SDK?
(off topic) I'm dreaming of a T-Splines connection or something similar.

Hi neo,

> All I can tell Microstation is a robust modeler which
> runs on Parasolid Modeling Kernel...I'm not sure if
> that is any help.

It's hard to say - if OpenDGN is focused primarily on standard AEC type stuff, it may not possibly expose 100% of the functionality of Microstation.

It's hard to tell without reviewing the spec, which does not seem to be just freely available to download.


> By saying opened things up, do you mean SDK?

Yup.


> In which Version of MoI you think you may releasing a SDK?

Hard to say exactly. It will take quite a bit of work to document and support an SDK.

I probably won't be able to do it until a somewhat larger portion of "basic end user" type functions are filled in a bit more first.

I had been hoping to be able to start it in v3, but I'm not even sure about that right now.

- Michael

Hi Michael!

Thank you very much for your help!

My last report..)

All those test sat files you provided except for one didn't get into my Revit correctly..

But I experimented with seams as you advised and out of 20 variants - 2 work fine for me now - and I found some rules to follow which seem producing predictable results

Also if I split the sphere into two parts rotate seems and boolean union those part back into sphere - it works fine as well!

Dgn sounds like a good alternative for sat in aec, although it is not yet understood if this format is superior to sat or inferior (in terms of ability to correctly transfer nurbs)
Hopefully 3dm finds its way into aec very soon, cause sat is so conditional (at times))

ps thanks to neo for help also!

Igor

Hi Igor,

> All those test sat files you provided except for one
> didn't get into my Revit correctly..

Hmmm, that's strange - those same exact files do not all work for you?

I took those screenshots directly from the file imported for Revit (all the ones that were white in that previous message), so that is strange that all those examples worked for me but not for you...

Are we possibly using different ways to bring the data over?

What I did for those tests was to save as SAT from MoI (those SAT files in that spheretest.zip file were all generated that way), then to bring it into Revit I used Insert / Import CAD, which pulls up a dialog that lets me pick ACIS SAT Files as one of the file types to insert:



I just gave them a try again and once again did not have any problem reading in any of the files: test1.sat, test2.sat, test3.sat, or test4.sat .

But one note - the initial display after loading seems to be quite sparse, I did not get the enhanced wireframe view until I moved the mouse over the object and clicked on it to select it. That seems to draw the object in a somewhat better quality enhanced wireframe display. Those screenshots that I took were with the object selected so you could more easily see the additional edges that it displays when selected.


What are the results that you are seeing with those 4 test files - I mean what happens on the ones that don't work, do you get a dialog saying that SAT data cannot be read in, or do you get the temporary sparse wireframe that then becomes more detailed after you select the object?

Also which version of Revit are you using again? These tests that I was doing were with version 2010.


Thanks,
- Michael

Hi Igor - also I'm attaching here the saved .rvt file from Revit after inserting each of those SAT files (the ones that I previously posted in the spheretest.zip attachment).

After loading the file into Revit, you should see this type of display initially:



Then if you select the objects, you will get the enhanced display that seems to go with selection, with some more edges displayed:



Also if you switch the View properties to turn shading + edges on, it looks like this:




Do you get different results than this?


- Michael

Hi Michael!

I see you like revit))

Revit 2010 has indeed seen some improvement in sat importing (all the test files import correctly)
In 2009 as I wrote earlier - just one file imported correctly

The only point is 2010 was released a month ago and taking into account its other problems, no one is in particualr hurry to migrate to 2010.. So we here in 2009 (just like you I downloaded 2010 to check though)

But even in 2010 not everything is perfect (if you remember my first test files (fromMoi.sat) - still not imported correctly

So I think we may leave this topic for a while since I found a few workarounds (like 3 axis specific rotating) which make files importable into revit..

Ideally It would be good to have an exporter versatile enough to deal with such problems until autosesk introduces 3dm direct import..
(sort of what rhino has - with options for specific program sat output ie inventor, solidworks and so on - to counter possible problems)

All the same thanks for taking care of us - users!

Regards
Igor

Hi Igor, yeah I guess that explains it - it seems that Autodesk has made a lot of fixes in the Revit SAT importer in version 2010.

If you need to work with imported data a lot, then I guess it would be a good idea to try to update to Revit version 2010 as soon as you can.


> But even in 2010 not everything is perfect (if you remember my
> first test files (fromMoi.sat) - still not imported correctly

Yes, even though it seems to be quite a bit better it looks like they need to continue to work on improving it...

Hopefully they will be able to make progress on the next version similar to the improvements they seem to have done between version 2009 and 2010.


> (sort of what rhino has - with options for specific program sat
> output ie inventor, solidworks and so on - to counter possible
> problems)

That SAT export option that you are referring to in Rhino doesn't really seem to actually do very much. It looks like they are meant to be kind of a "preset" that is a group of individual settings. But almost all of them have the same options set. From the Rhino help file (in the index look at "SAT file export"):



So note that all options have "Closed surfaces are split" (which MoI does not do) and "Curve knots and surface knots are clamped" being set (which MoI will do also).

The only major difference between the application-specific options seems to be whether writing curves is enabled or not, that's it...


- Michael