How DiffTool Extension Works in Forge Viewer? - autodesk-forge

I have loaded DiffTool extension to compare two versions of a model. I just removed some elements from version 1 and upload it as a 2nd version. Here are the Model Browsers for those versions -
Now, when I compare these two versions I am getting many differences between the model versions which is much higher than what I expected. The comparison panel shows many items as Added, Removed and Modified. I have seen that though exact same item is present in both models(after the removed item in the model tree), DiffTool showing it as Added and Modified in version 2. Like this -
From a user point of view, I don't want to see this as an Added or Modified item. From the documentation, I am not clear how DiffTool compares items. Can you please help me to understand the way DiffTool compares models? And If I want to customize the comparison logic, is there any way for this? TIA

Related

IFC conversion method changes position of resulting SVF

When converting IFC files to SVF with the Autodesk Model Derivative API, I would like to start using the "modern" converter instead of the "legacy" one. However, when using Forge Viewer, the models that were created with the modern conversion method end up with a different position and/or orientation than the legacy ones.
I have tried to get to the bottom of what the difference consists of, and it seems to at least have something to do with the TrueNorth property of the IfcRepresentationContext in the IfcProject. Also, the ObjectPlacement of the IfcSite is probably part of it. But I haven't found a combination of properties to reliably compensate for the difference for all my IFC files. The IFCs typically come from Revit, but may have various origins.
Many of our customers have projects with several existing models, so ideally, any new models should align with the existing ones even if the conversion method has changed.
I submitted an issue item NWLMV-164 on your behalf to ask our engineering team to allocate time to investigate it. Now it can be traced back to NWLMV-88. As result, it needs some time to explore and find the solution to fix this issue. Please take a note of either NWLMV prefix ids. You're welcome to track updates in the future by sending an email to forge[DOT]help[AT]autodesk[DOT]com quoting the NWLMV prefix ids. We appreciate your understanding and patience.

Two different Autodesk Forge apps are running same code

Please, it looks to me that I am asking a very basic question; however I could not find an explanation yet. I used .NET and both exercises for view models and modify models work great individually. I mean that I found no problems testing view models when this one was the only example available or modifying models when this one was the only example available. However, when both examples are available, doesn't matter which was the example selected and executed from inside Visual Studio that always goes to modifying models. Please notice that I created two different apps (obviously with different ClientId and secret key). Maybe not quite a good understanding of Autodesk Forge apps? Any help to understand what is going on?
Thank you very much!
If the two projects are in one solution you can specify which one to run as the default project as well as several projects at once and their order - see here and here...
Looks like this is rather a question on VS than Forge so I'd suggest to remove the autodesk-forge tag...

Coordinates model changed (Autodesk Viewer)

I dont know this is the right place to ask, but since Autodesk redirects here on their 'get help' page, im trying anyway....
We have a couple of autodesk models that we display using their viewer. Also, we had a couple of 'presets' configured: camera positions based on XYZ of the camera and XYZ of the target the camera is looking at. So, when you push the preset, the camera position changes towards the XYZ and the target is set as well.
This worked fine - untill this weekend (23-04-2018): The positions are completely off... E.G. one of the presets did center the viewable area on a specific part of the model and now it seems the model is zoomed out 50 times and in another angle (we are using the perspective camera). I'm not sure what's the cause of this, but if i had to guess, it would be that the parsing of the source DWG is done again automatically and the center of the model as SVG shifted, and thus the stored XYZ coordinates are useless.
Obviously we can reinitialise the presets, but since i dont know what caused this, im unsure if thats just wasted time. Now the question: Does anyone know what is the cause of this and can we avoid it?
Ahh - ok, seems to be related to the version of the viewer - although im still unsure why it switched (there was no new version released afaik) manually specifying
<script src="https://developer.api.autodesk.com/modelderivative/v2/viewers/viewer3D.min.js?v=v4.1.0"></script>
fixed it.
There were indeed some changes that might have affected the scenes that "manipulates" with positioning (be it camera or component).
The scene I usually use to illustrate the component transformations: http://giro-watch.tk/ was "broke" when I updated to the latest Viewer version.
In case you refer to the Forge Viewer lib without specifying the version:
... src="https://.../v2/viewers/viewer3D.min.js?v=v4.1"></script>
as in this case, omitting ?v=v4.1,
you will get the latest version of it and since recently the Forge Viewer changed from v3 to v4, some breaking changes were expected.
However, between you and Autodesk server, might be a couple of services that caches this file and this is why you project might work fine even after the Forge Viewer was updated and just now the caches were cleaned/renewed.
This is why we recommend to always use versioning in production code.

Autodesk Forge randomly loses object and room information

I'm using Autodesk Forge to integrate with our remodeling tool. In particular, I need to count objects of different families and types and determine to what room they actually belong. I use Model Derivative API for this purpose. To keep the room/area information I convert .rvt files to .nwc files as suggested here. However, when I retrieve data with GET /modelderivative/v2/designdata/{urn}/metadata/{guid}/properties I face the following problems from time to time:
Room information sometimes disappears from Objects for some reason
Objects disappear from result data for some reason (but they seem to exist when I browse them in A360)
I have no idea, what can be the reason for this.
I have no explanation for the disappearance of room data or objects for you.
If you can provide a reproducible case demonstrating that, I will gladly pass it on to the development team for analysis.
If you are interested in an immediate reliable solution and full control, which I assume is the case, I would suggest following the second bullet item in the advice provided by Eason in the previous answer that you refer to above:
Extract all the room information and object relationships you are interested in via the Revit API, store that data somewhere yourself, and use it later on wherever you like to your heart's content.
Then you will be completely safe and independent of all other components and their unpredictable behaviour.
If the only information that you need is the room containing each family instance, I can even implement a suitable Revit add-in for you.
Another suggestion that might help, if that is indeed the data you require: determine that information in a Revit add-in and attach it to each family instance in your own personal shared parameter. That will ensure that it remains intact through the translation process. Afaik, all shared parameter data is retained, independent of other behaviour.

How to define the version number of a software?

What is the best method to determine the version number I should use for a software or component? Is there a general rule to set version numbers?
I'm pretty sure it is a basic question but I didn't find anything useful after searching a while.
Microsoft have a convention of:
[major].[minor].[revision].[build]
Or follow Jeff's versioning system.
I've been doing this as an interim until I find a better solution. I don't build many large applications, mostly reports and smaller macros, but it's still important for me to keep track of changes and versions.
[Current year].[Current month].[Current day]
FileName 9.7.17.rpt for example.
It works for me and my boss, and it gives a value which you can compare to today's date to see how old the file is. I also keep a changelog.txt file in the same folder as the most current version and it keeps track of all the changes from the previous versions. I also keep track of all versions in a version control page on each projects tab in OneNote.
Thanks for the answer. I'll also throw in how I store the projects for giggles.
Every project gets its own folder. Inside that folder I'll have 4 main items that help me keep track of what's going on in the project.
An old versions folder
A folder for any reference material I might need for the project
The actual project file
And the changelog
That tree will look something like this.
Project X
Old versions
X Report 9.4.12.rpt
X Report 9.5.3.rpt
X Report 9.7.20.rpt
Reference
SQL calls.txt
Client list.txt
Procedures.doc
X Report 9.7.29.rpt
X Report changelog.txt
This way of keeping track of my work really cuts down on the amount of time that I need to spend documenting anything and organizes it in a standard way so if my boss needs to grab something I've worked on, even he knows exactly what everything means and where it is.
For storing multiple projects in my network folder I have these folders.
Inbox
Projects
#Archived Projects
Current Project 1
Current Project 2
Current Project 3
Reference
Inbox is where I toss random things to process later, or a folder where my boss can throw something I'm going to need for a later project. The Projects folder contains all the projects I'm currently working on, and then when I'm done or they no longer become a current priority, they get tossed in #Archived Projects. Reference is a folder for general job reference material, like policies and procedures, phone lists, org charts, fire escape plans. I may never use them, but it's comforting to have a place to put that kind of stuff as opposed to digging through old email.
This is a very common question. Are you sure you searched around? Wikipedia has a good article on software versioning.
Or, you can follow Ubuntu's convention of using year and month.
For example, release on April 2009 would be:
v9.04
Do it like Donald Knuth does with TeX---its version converges to π with each release and will in fact become π when he dies.
Since version 3, TeX has used an
idiosyncratic version numbering
system, where updates have been
indicated by adding an extra digit at
the end of the decimal, so that the
version number asymptotically
approaches π. This is a reflection of
the fact that TeX is now very stable,
and only minor updates are
anticipated. The current version of
TeX is 3.1415926; it was last updated
in March 2008.
from Wikipedia
A common scheme seems to be to use [major].[minor].[revision]. Where the major version number increments on large/major feature changes or rewrites (or stays 0 as long as you didn't reach a stable version, although many open source projects never get past 0 here), minor version number increases on minor changes, such as a collection of bugfixes, an added small feature and the like. revision increments with each build and reflects the smallest granularity of tracking your exact version. Things like small fixes, etc. get rolled into this, usually.
Usually the first number are major changes/major releases, the second number are used when minor features and bug fixes are added, and the third number is used for minor bug fixes and revision numbers.
Ex. 1.0.0
Depends on a lot of things.
If you are doing .Net work, you can have the system keep track of version numbers for your .dlls and .exe files automatically.
We frequently use the subversion revision as part of our version number. We use a system like:
major.minor.svn-version
We increment the major/minor manually based on internal decisions, and have the svn-version propagate to distinguish builds.
The most important thing is that version numbers make sense to your users.