At https://forge.autodesk.com/en/docs/model-derivative/v2/developers_guide/supported-translations/ I can check the formats currently supported by Autodesk Forge. Are you working towards enabling expression of the datasets in Geopackage (see https://www.ogc.org/standards/geopackage) and RDF/Turtle (https://www.w3.org/TR/rdf-schema/ and https://www.w3.org/TR/turtle/)?
While there are a few exceptions (like the OBJ or FBX files that are very common for 3D data exchange), Forge is typically used with design formats used in architecture, engineering, construction, manufacturing, or media & entertainment. I don't know if the formats you mention fall into any of these categories, but if they do, I'd be happy to bring them up with the Forge team as a suggestion.
If the Geopackage or RDF files are meant to provide some additional context to other types of designs (like DWG drawings, for example), please note that you can load them yourself, and add their information into the DWG loaded in the viewer using the viewer's JavaScript API.
Related
I cannot find any resource similar to the Model Derivative API that has a list of supported file translations.
can the autocad Design Automation API take in .dxf, pdfs, etc., or is there a list somewhere?
Design Automation for AutoCAD can process DWG,DXF,DWT and DWS, unlike Model Derivative which has translation capabilities, Design Automation is a service to run automated jobs.
At the moment, importing PDF in Design Automation for AutoCAD is not possible.
We want to embed a 3D CAD viewer into our web-based collaboration platform. It would work similar to the one offered by Opencascade. You can see it here.
We do not charge for the use of our platform and we would prefer an open source option if it is available (Opencascade viewer is not open source).
Does Autodesk Forge have a similar offering?
Thanks!
CAD viewer solution for a WEB can be split into several pieces:
On-server converter of CAD model.
Conversion of CAD file into intermediate format. You might need a lot of Data Connectors in case if you need supporting wide range of CAD formats, or restrict functionality to import vendor-neutral formats like STEP.
Generation of Web-friendly triangulation-based 3D model. This step might include model simplification in case if you have to deal with large models.
Server backend implementing business logic and backend for 3D viewer. The complexity of 3D Viewer backend depends on functionality provided with it and ability of viewer to handle extra-large models. In simplest case, this might be just a file server providing 3D model in format like glTF.
Client part, e.g. HTML+JavaScript code for displaying 3D model using WebGL, as well as GUI and application-specific logic. The viewer might just display 3D model (in which case it is barely distinguishable from non-CAD viewers), or give many features like Shaded and Wireframe (not just mesh edges) modes, picking sub-parts, Clipping Boxes, clipping with capping, annotations, dimensions, explode view, HLR view, a bunch of them!
Although it is technically possible loading some small CAD models directly in the Browser, in general this task is expected to reside on server to improve user experience and give some protection to intellectual properties (of CAD models). The converter may be based on Open CASCADE Technology, which is an open source framework, in case if STEP/IGES input file formats are enough (output could be your custom file format or glTF 2.0, for instance). But in case of native CAD formats support (like CATIA and others) you will unlikely find any free open-source libraries.
The Web viewer itself relies on WebGL and normally can be based on any traditional JavaScript-based library like Three.js (or existing 3D Viewer on top), or may rely on C++-based engine (again, Open CASCADE Technology can be build as WebAssembly module). WebAssembly-based viewer may give some performance benefits and it is more friendly to C++ developers (but apparently - less friendly to JavaScript developers). There is a hidden issue, though, as many open-source C++ libraries commonly have LGPL license - pretty good for desktop, but might have legality issues in case of a Web application. In contrast, WEB-based libraries are normally more proprietary-friendly with permissible licenses ignoring open-source software ideas put into licenses like (L)GPL.
In general, 3D CAD Viewer definition is very wide, and requirements list in your question are very basic and unclear - just to embed 3D Viewer in your WEB application. You may write your own Web Viewer based on open source components, or consider commercial options already implementing features you are looking for, and aware of / providing some solutions for handling tricky problems.
Looks like Forge Viewer fits the bill perfectly and covers most of the features available with the demo ;)
You may experience/preview Viewer following this link using a model of your own here and follow here to build up a MVP here...
For the features that are not readily/built-in out of the box Viewer is highly extensible and offers API making it pretty straight forward to develop extensions following here and also the blogs/tutorials available here.
I'm building a cross platform 3D viewing application in C#/C++ and would like to add support for Autodesk SVF files.
I looked at Autodesk Forge but it has limited support for exporting to open formats such as OBJ, and Autodesk SVF does not appear to be the same format as the similarly named Simple Vector Format (http://www.svf.org/) as was stated here: https://forge.autodesk.com/blog/updated-little-more-detail-behind-autodesk-forge-apis-0
Is there a schema or specification available somewhere that details the structure of Autodesk's SVF format?
The short answer: no there isn't as it's a proprietary format (that has been breached in some country already and legal actions were needed to resolve the issue...)
The long answer and please view this as my personal rambling w/o any real authority or credibility:
I'd recommend to stay tuned to the official Forge website and see if they'd choke up more info on SVF(aka the Streaming Viewing Format) for public knowledge.
We are working on an integration of an external software with Autodesk Forge. Following openBIM, we want to focus on model data in IFC format. Question is (and I was not able to find this answer online) which IFC versions are supported in the Forge ecosystem? Would one have to be careful with using e.g. only IFC 2x3 or is IFC 4 Add4 also supported? The documentation at https://forge.autodesk.com/en/docs/model-derivative/v2/developers_guide/supported-translations/ only generally mentions the IFC support, but no versions ... which would be a necessary information IMHO, as the format is still in active development.
(Just happened to see this thread)
As I know, there is no IFC 4 Add4, but IFC 4 Add2. See https://technical.buildingsmart.org/standards/ifc/ifc-schema-specifications/
Forge Model Derivative API currently has three IFC conversion methods: legacy, modern, and v3, which are the same as Navisworks IFC readers.
The legacy conversion method is under maintenance mode and doesn't fully support IFC4. So, it won't get updates anymore. For better IFC4 support, please use modern or v3 instead.
The modern conversion method is based on Revit technics. Currently, Revit supports IFC4 and IFC2x3. Its main features of exporting/importing IFC are provided by our open-source project Autodesk/revit-ifc. Model Derivative API uses Revit to export IFC from RVT files so that the supported IFC version will be the same as Autodesk/revit-ifc provided.
The v3 conversion method is based on the modern one but has some improvements (e.g. using file native distance units, not always feet)
Note. IFC4.x is not yet supported. For more details, please check out:
https://blogs.autodesk.com/revit/2022/02/09/now-available-revit-ifc-manual-version-2-0/ (Point Releases (4.x) already in the pipeline, including enhancements and new classes for infrastructure including bridges, railways, roads, ports, and waterways.)
https://technical.buildingsmart.org/standards/ifc/ifc-schema-specifications/ (BuildingSmart withdrew IFC4x1 and IFC4x2, and they are developing IFC4x3)
https://github.com/Autodesk/revit-ifc/releases/tag/IFC_v22.3.0.0 (Added additional generic support for IFC4.x files for 2022.1)
ref: https://forge.autodesk.com/blog/export-ifc-rvt-using-model-derivative-api
I am an App developer with no experience with AutoCAD at all, and for my current project I need to convert DWG files into Spatial Data - ESRI Shapefile / GeoJSON, etc.
Given that DWG is a proprietary format owned by Autodesk, the Autodesk Forge API becomes my only option to interpret such file. I have been evaluating the Model Derivative API for a week now, and what I found is that it won't work for my purposes. It has only 3 output formats (f2d, f3d, rvt) for DWG files and none of them fits my purpose.
For this reason, I started to look at others API's in the platform and ended up finding the Design Automation API which might be helpful, however it lacks documentation.
One of the examples in the API is the PlotToPdf activity that exports a DWG into a PDF. I wonder if there is a way to export other formats other than PDF.
I tried to find the possible "commands" in the interface by listing all the activities, workItems and AppPackages but none of these end-points returned me any useful information.
So here are my questions?
How can I can convert a DWG into a non Autodesk format? Being more specifically, the output must be an open format that I can interpret without using proprietary tools.
If the answer for the first question is Autodesk Forge API, which one should I use?
In case I should be using Design Automation API for that, where can I find complementary documentation once the one provided is lacking details?
I would say that Design Automation API is the best option if you don't have (or don't want) AutoCAD running (or any other DWG compatible desktop app).
To be complete: Design Automation includes an instance of AutoCAD running on the cloud, where you can upload a .DWG with a sequence of commands (script) and a .NET custom app to execute more advanced routines. Then download the results. By default, neither AutoCAD nor Design Automation can export to GIS formats (like those you mentioned), only some verticals, like Civil 3D or Map 3D, but these are not available on Design Automation. As you mentioned, Model Derivative API (via REST calls) don't have what you need, it's focused on metadata, not the specifications of the geometry.
Design Automation API supports the same commands AutoCAD Console does. For DXF creation, you can use DXFOUT command, your script would be something like (not tested):
FILEDIA
0
DXFOUT
outputfilename.dxf
QUIT
As per comment, it's a huge effort to just convert to .DXF. I'm not familiar with other libraries do perform the same task.
Now I'm not an expert on GIS data formats, but you may consider move from .DWG to .DXF then an approach like described here.
I don't quite understand this point that you are making in the comments:
I would only use the API to convert DWG to DXF, which means a huge waste of resources considering the monthly cost of the API and the time to develop and maintain the interface.
Can you clarify? Are you saying that transaction cost for Design Automation is too high? Or are you saying that development cost associated with deploying the script that Augusto gave you is too high?
Thanks
Right now the derivativeApi is the way to go for this: You can convert any input format from this list (https://developer.autodesk.com/en/docs/model-derivative/v2/overview/supported-translations/) to the "intermediate format" svf and the convert the svf file to obj for example. This will also create a material file which can be downloaded seperately. I am evaluation the forge api right now and can produce obj from dwg files right now.