Hi Igor, I've heard back from the author of the SAT export library that I'm using but we don't quite have enough information yet to know what is happening.

It may take a few tests back and forth to narrow it down some more.

Could you please try importing each of the 2 attached SAT test files into Revit and let me know what the results are?

That would help narrow things down a bit more.

- Michael

Hi Michael,

Thank you for reply on sat export! I think that the whole point of MoI is to be the best interoperable app, and your are getting closer to it with SKP exporter (best exporter found!) - Now its time for SAT!))

Revit is a free download from autodesk.com (30 days - trial - after that - save disabled - but fully functional!) If at some stage you'll decide to install it for tests - I'll provide you with the direct link.

There's a huge demand in revit world for software like MoI which can bring analytical surfaces into Revit, the part in which SketchUp fails explicitly..

My latest findings: Rhino is not always successfull with spheres also - just about 85% of sat files containing booleaned spheres were imported sucessfully into Revit (partly maybe becase I used same 3dm files in both apps)
(What we see in rhino (10 options for sat) is an attempt in the right direction, but not full.)

Autocad 3d sat export into revit - 100% successful!! I use it now for modelling - but its so damn user unfriendly! and not everything can be modelled in autocad - would love to use MoI more instead..!

What I would first look at as a 3dm-sat exporter owner - (but only assuming that surface definition is somehow relevant to how wireframe for an object is build for view) Why same sphere (after boolean union) look different in wireframe mode in MoI depending on where the operation (boulean union) was performed - if in MoI - MoI is showing one type of Wireframe, if in Rhino - another type, if in AutoCad - yet another AND other wirefames of adjasent shapes are always consistent!

Pls see attached the results for your test files (tested on WinXP and Vista, in revit 2009 and revit 2010)

Regards,
Igor

Hi Igor,

Thanks for running those tests... That rules out a couple of possibilities.

I didn't know that Revit had a free demo, I found where it is at so I guess I will give that a try.


> My latest findings: Rhino is not always successfull with
> spheres also - just about 85% of sat files containing booleaned
> spheres were imported sucessfully into Revit

Well, with there being problems with some spheres saved from Rhino as well, it is looking more and more like a bug in Revit's SAT importer...

Remember - it takes 2 pieces of software to do a data transfer - the exporter of course, but also the importer on the other side.

If there are any bugs in the importer code, that can also prevent data transfer from being successful.

When more than one program's output runs into the same kind of problem with a particular importer, it can tend to mean that the importer code has a problem that needs to be fixed, especially if importers in other programs handle the same data fine.

This problem seems to be fitting mostly into that category.


> Why same sphere (after boolean union) look different in wireframe
> mode in MoI depending on where the operation (boulean union) was
> performed - if in MoI - MoI is showing one type of Wireframe, if in
> Rhino - another type, <...>

I'm not sure yet - MoI does not really control the wireframe appearance in other applications.

But one difference that I did notice is that Rhino's SAT exporter will modify your object to split a single sphere surface into 2 half spheres that are joined together. That's the reason for at least one of the differences in wireframe appearance that you mentioned before (with the "arc" from MoI versus the "all the way around" edge from a Rhino export - the "all the way around" edge was due to the sphere being split into half pieces).

In that previous "test2" file, I tried splitting the sphere in MoI up into 2 pieces as well to see if that would have any effect, and it kind of did since one piece of the sphere looks like it went through now but not the other half.


One thing that would have helped somewhat with these tests is if you had a consistent model in each one - in some of your previous ones the sphere that you placed in MoI and Rhino was different because its "seam edge" was located in different areas. That resulted in some differences in topology between those models instead of them being identical tests. I'll see if I can run some test with the demo version of Revit with more identical models to try and gather some additional information.

- Michael

Hi Igor - some more notes on wireframe appearance differences.

The wireframe of a sphere looks different when you create a sphere directly inside of AutoCAD because it creates it as special "sphere primitive" object, and it draws those special kinds of objects with a special wireframe density.

When you import SAT data into AutoCAD from MoI, it comes over as a "generic NURBS surface" type, which gets a slightly different kind of a display in AutoCAD (it is categorized as a different class of object even though it is exactly the same shape as a sphere).

You can adjust the "ISOLINES" system variable to change how the wireframe in AutoCAD is drawn - for example if you type in ISOLINES 8 <enter> and then do a regen, you will see a denser wireframe over your model.


The SAT files created from spheres drawn in AutoCAD also get created as special "sphere-surface" entities inside of the SAT file saved from AutoCAD. This special kind of surface definition seems to work better with Revit, it seems to avoid some kind of bug in Revit that may involve processing general NURBS surfaces that are surfaces of revolution.

Ideally you would be able to export sphere-surface entities to SAT from MoI as well if the WriteAnalyticSurfaces=y is set in the moi.ini file, but that appears to not be working currently. I'll try to find out from the export library's author if this part can be fixed up, that would probably give the best chance for making it work.

Otherwise, you may want to submit some of these SAT files to Autodesk as a bug report for Revit, so that they have some examples to test with to see if they need to fix a problem in Revit's importer, which seems likely.

- Michael

Hi Michael!

Thank you for taking a closer look at this problem and explanations on Isolines.

There is definately a bug in sat importer in revit, and it was filed to autodesk.

Autodesk said that there's no bug as all their software exports and imports SAT correctly, and they are not responsible for possible problems with other than Autodesk SAT exporters and indeed Autocad sats work flawlessly

Nevertheless, its always good to adjust sat export for possible known bugs of autodesk software (if we finally get to know how) as it will give MoI very good export abilitites not only to Revit but to Inventor and so on - I think a valuable marketing point for MoI for the future (more people will migrate from Autodek to MoI)))

If you download revit I'd recomend that you stop(cancel) contentdownloader in the end of the installation process as it takes a lot of time to download content specific to arch which I think you won't need. The installation will finish sucessfully anyway..

And the last - as we saw from your test sat files you are already able to make modifications and the sphere almost went though the second test

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..)

Regads,
Igor

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