I am trying to use forge-Viewer with dashboards to analyze the data within the model. For that, I am using the getAllLeafComponent() method expressed in the Forge Tutorials: https://learnforge.autodesk.io/#/viewer/extensions/panel?id=enumerate-leaf-nodes.
Nevertheless, I am having some trouble with this method, because it will not recognize objects that have children (i.e. Revit Families with nested items).
Element with nested item (space of operation)
In the attached image, the green tetrahedron represents the transformer space of operation, and it is a nested item inside the transformer, so with the getAllLeafComponent() method I am unable to retrieve the transformer data, which is the important one; as this method does not recognize the transformer as a leaf, but rather as a parent element, which indeed it is, but it is also a model object, not a category or a family symbol.
Has anyone comes up with the same problem and/or with a way to solve it?
It is of uttermost importance for my Forge application, otherwise, I would not have reliable model information to analyze it.
Best Regards,
The Model Derivative service uses a specific, "reasonable" logic for each individual input file format to decide how granular it should go when building the logical hierarchy for the viewer. In case of Revit designs, the processing stops at the instance level, in other words, family instances are always output as leaf nodes, even if their families have some nested elements. For example, doors are always output as the smallest selectable elements, and you cannot select just the door knob. I'm afraid the same applies to your space of operation nested within the transformer family.
If you need to extract information that the Model Derivative service does not provide, you could consider using the Design Automation service instead. This service lets you execute your custom Revit (or AutoCAD, or Inventor, or 3ds Max) plugin on our servers, creating, modifying, or analyzing designs in any way you need, remotely.
Related
I have translated SolidWorks files on AutoDesk Forge, however, the Forge metatadata / objects / properties call of these files only provides the objectid and name. I know I've got several fields in the files, just wondering if I have to wire up some strange way to pull them out before sending them, figuring it may not be supported through the Forge API. Thanks!
The Model Derivative service is usually doing a pretty good job with extracting the metadata of your designs. Note however that the metadata might be available on a different level in the logical hierarchy.
Here's the metadata I see in one of my sample SolidWorks files when I simply click on one of the parts:
And this is the metadata I see when I select its parent element:
I have a dxf file that I have uploaded to oss and translated it to svf.
How can I fetch the layer states in my 2D model using forgeviewer?
In autocad, I have these layer states Screenshot for autocad layer states.
Namely:
F1 Component Plan
F2 Electrical Plan
F3 Bracket Plan
But when in the forgeviewer, I cant find those lawyer states (Grouping).
I'm afraid this type of information may not be available. Generally, the Forge Model Derivative service always tries to extract a "balanced" amount of information from design files (enough for previewing purposes, but not too much, to make sure the output keeps a reasonable size).
When you load your DXF file into the viewer, you can try querying its metadata using viewer.model.getData(), and see if you find the layer state there. I did try that with one of my testing DXFs, and didn't see this information there.
Finally, if you really do need the layer state data, there's another option - you could use Design Automation for AutoCAD, with a custom AutoCAD plugin that would extract all the information you need directly from the source file.
We are now in process of evaluating integration solutions and comparing Mule and Boomi.
Use case is to read an Excel file, map the columns to a pre-defined set of JSON attributes and then use the JSON to insert records into a database. The mapping may vary from one Excel template to another wherein the column names in an Excel may be different from others.
How do I inject mapping information (source vs target) from outside integration flow?
Note: In Mule, I'm able to do that using a mapping variable (value is JSON) that I inject using Mule DataWeave language.
Boomi's mapping component is static in terms of structure but more versatile solutions are certainly possible.
The data processor component opens up Groovy, JavaScript, and XSLT 3.0 as options. These are Turing-complete languages that can be used to bend Boomi to almost any outcome.
You could make the Boomi UI available to those who need to write the maps in JSON. It's a pretty simple interface to learn. By using a route component, there could be one "parent" process that governs the a process for each template/process and then a map for each template. Such a solution would be pretty easy to build and run; allowing the template-specific processes to be deployed independently of the "parent".
You could map to a generic columnar structure and then dynamically alter the target
columns by writing a SQL procedure that would alter the target columns.
I've come across attempts to do what you're describing (not using either Boomi or Mulesoft) which were tragic failures: https://www.zdnet.com/article/uk-rural-payments-agency-rpa-it-failure-and-gross-incompetence-screws-farmers/ I draw your attention to the NAO's points:
ensure the system specifications retain a realistic level of flexibility
and
bespoke software is costly to develop, needs to be thoroughly tested, and takes more time to implement
The general goal for such a requirement like yours is usually to make transformation/ETL available to "non-programmers" which denies the reality that there are many more skills to delivering an outcome than "programming".
We are running some processing on the contents of the InstanceTree, were the goal is to only collect the nodes which have a direct (geometric element) counterpart in the model -> meaning they are directly selectable by clicking on a model element in the viewer.
At first, it seemed like this was solved by focusing on the leaf nodes in the tree, traversing it recursively via enumNodeChildren(node, callback, recursive) and storing the node only if getChildCount(dbId) was 0, thus indicating we reached a leaf.
However, there seem to be constellations where there is geometry connected to non-leaf nodes as well as to their children. This seems to be the case where these nodes represent certain Revit Family Types with independent geometry.
We then tried to find a way to distinguish nodes with directly attached geometry vs. nodes which only act as "grouping" for real geometry nodes. But none of the API methods under https://forge.autodesk.com/en/docs/viewer/v7/reference/Private/InstanceTree/ seem to help in this case (not even the promising getNodeType(dbId) as just returns 0 for all nodes involved).
A rather dirty fix for now is that we check for a id suffix in the node's name, which only seems to be present if there is directly related geometry. But I guess this also only just works if the viewable originates from a Revit file. See this image for clarification. It shows a parent node with no geometry, an intermediate node with geometry and several leaf nodes with geometry.
Is there a better way to solve this problem?
Context: I've been extracting geometry data from the Forge SVF structures into an OBJ format using the Forge Extract code by Petr. These data are then transparently sent to a different rendering system for the project upon which I'm working. However, I'm noticing that there are incorrect rotations in groups of extracted objects. Not all objects, just groupings.
As an example, here is the Forge Viewer rendering of a group of objects (the long poles), with correct rotation. You can see all the poles evenly placed along the base-plate's edge and equally placed with regards to each other.
Whereas in the rendered extracted geometry, the grouping of objects are correctly placed with relation to each other (equally, 3x3), but the group as a whole is rotated slightly along the Z-axis in relation to the bottom plate.
This is the type of behaviour I would expect if the individual poles were all child objects of some parent object (perhaps an invisible grouping object), and the rotation of the parent would pivot all the poles in the SVF but that rotation wasn't applied during geometry extraction.
This happens with all groupings with regards to individual objects in a scene.
While looking at this question, I get the strong impression that there is a 2nd rotational aspect but I cannot see how that applies when reading the SVF directly.
Question:
Obviously I'm not looking for a direct code solution, but to confirm the structure of the SVF pack files. Looking at the extraction, I don't see anything which would imply a parent-child grouping but haven't managed to think of an alternative cause.
So, are there such parent-child transform relationships in the SVF pack files, or a global rotational component which only applies to certain objects? If so, where is that placed within the pack file. And if not, what else could cause this type of systematic rotation of groups?
The SVF file format doesn't use parent-child transforms - all fragment transforms are basically world transforms. It's possible that my code for parsing the fragment transforms handles one of the transform types incorrectly. I'd try debugging the getTransform method for the dbId of the base or one of the poles, and compare the transform with the one parsed by Forge Viewer.
Also, I'm wondering if it's the base that's slightly off, and not the 3x3 poles?