Append/Merge result in duplicates

[matthew_breeden]

I have 3 DWGs. Let's call them A, B and C. Any of the 3 may Xref the others, A is in C or C is in B, etc. 

I append these DWGs together, and when one is xrefed into another a duplicate is created. Now there is 2 B.dwg on top of each other. 

How do I build a .NWF without getting these duplicates?

I thought merge was to resolve this, but it doesn't work. I get the same results as append. 

[dgorsman]

Models brought in as XREFs are XREF dependent; this is most easily seen as the layers in the Selection Tree have the standard "|" dependency character.  Because of this, Navisworks doesn't see it as a duplicate.

I'd recommend one of two courses.  Either use XREFs to bring in all models (we create a series of reference models with nothing but XREFs for this), or turn off XREF loading under Options and load all model files individually.  Both have their advantages and disadvantages.

[matthew_breeden]

I have done the reference model with just Xrefs. Problem with that is it reloads all the xrefs when refreshed and not the models that changed. That is what I am trying to get away from. I can't wait 10 mins every time just to reload one DWG. Appending the DWGs fixes this, but causes the duplicates. 

Turning off convert xrefs is not an option. Other disciplines use a xref tree that would be a PITA to recreate in Navis. 

[dgorsman]

This is the result of a change that was requested some time back.  Users wanted the overrides on XREF models to be taken into account, rather than just the original model.  The end result is that when something changes in one model everything has to be reloaded now, as it has to consider where the XREF may be hosted to see if any settings have been overridden by a host.  The merge/append and Merge XREF layers from Options prevent duplicate models from the same model XREF'd in multiple hosts, but it cannot consider a "side by side" model the same as an XREF.

If you want fast, individual model reloading you have to disable XREF loading and add the models individually.  We have done the individual models thing on one or two projects; with an NWF being managed by a lead or BIM-coordinator type person its not too much of a burden.

I hope that figure of 10 minutes is an exaggeration, as it shouldn't take anywhere near that time to load a couple of files, XREFs or no - we have complex reference models that load a couple of dozen in a few of minutes.

[matthew_breeden]

I guess I don’t see why it can’t compare the parent models with the XREFs. It knows all the XREFs’ paths. If a parent model had the same path as an XREF, shouldn’t it recognize these as duplicate geometry? This is where the Merge should come into play, right? As of now, I haven’t see Merge do anything different than Append.

Maybe I am just not understanding how the program defines duplicate geometry. I can see it’s duplicated but the program doesn’t.

10 mins is not an exaggeration. It’s not common but it is possible. With over 100 xrefs, a point cloud or two, 15-20 main area models, then there is the duplicate part where it will load those 100 xrefs again based on whatever areas are xrefed together…

[dgorsman]

The problem isn't with the geometry, not directly anyways.  It has to do with layer overrides in models that host the XREF.  It may be GREEN in the original model, and YELLOW, or even frozen (and Options set to ignore frozen layers) when XREF'd into a host model.  So as far as the program is concerned something that is XREF dependent has to be something different than something that is not.  Not arguing with you - I certainly would prefer it the "old way", or at least an option to do so (I think there's a long-standing wish-list item for this), and I can see benefits to both methods.  But as the saying goes, it is what it is, and we need to work within how the program currently functions.

[matthew_breeden]

I see where you are coming from, as I’ve seen that layer battle first hand between depts. 

If a model was appended/merged, I would think this parent model would take precedence over any child model of the same path. After all, there is a reason the file is appended/merged. 

There is two products from the same company that doesn’t work well together. Both promote collaboration but those collaboration processes hinder the final product. That to me is WAY more important than some layer overrides.

So far it sounds like there is no way to build an efficient .NWF. Either I need to deal with duplicates or accept the fact it is going to refresh everything all the time and take forever. 

[matthew_breeden]

Just curious if anyone else is gonna throw in their two cents. Surely, we are not the only ones that run into this issue. Maybe the Autodesk team can elaborate on these processes? 

[Patrick_Aps_9121]

The solution is simple:
Options -> File Readers -> DWG /DXF -> de-select "Convert Xrefs"
Close and restart Navisworks
Now your navisworks does not load any reference at all any more.
Open A.DWG (the units of this first DWG will deterimine the units used in your Navisworks)
Append B and C.dwg
Save this as an NWF.
Edit any of the DWG's if you need to (or overwrite the file with a newer version but with the same filename)
Re-open the NWF and you will see the changes
or, if the NWF is still open, just select the DWG in the selection tree and press F5 to reload that single DWG.

[matthew_breeden]

Like I told dgorsman, turning off Convert Xrefs is not an option. Appending and positioning 100+ xrefs is not something anyone wants to do. There is many Xrefs that we want to come through. 

Its the duplication of models caused by xrefs and appended/merged models that is the issue. If I have A, B, and C in a .NWF, any time someone xrefs one of these 3 together results in duplication. It is very common and could be as simple as a civil as xrefing in a building steel model, which is already appended. Merge doesn't alleviate this issue as I believed it would do. 

[Patrick_Aps_9121]

I'm sorry to hear that "Turing off Convert Xrefs" is not an option, but to my knowledge, this is the only way to get out of the problem.
If you keep it on, and A is in C, then the contents of A is also in the cashe of C.NWC and a change in A will cause the need (for Navisworks) to recreate the NWC of any DWG where A is used.
Furthermore, in the past I found out that if a file is appended using non-UNC paths, but using Driveletters, and somebody opens the NWF an he does not have the same mapping, strange things can happen where the files may be found.
So indeed, it is a lot of work, but only once, to convert your NWF to one without Xrefs and all file individually appended once. When all drafters use the same WCS, you should not have to change "units and transfor" of each file.
If you do have to reposition the files, then the change applied is in Navisworks and you can read out it later or modify it later.

[matthew_breeden]

There is another way out of the problem. I think it involves fixing the program and not just a check box in the settings.

As dgorsman eluded to, this was a change made in the past versions. Sure the users got what they asked for but it also wrecked what was already available. Something as simple as observing the “Overlay/Attach” setting for Xrefs could fix the problem. Or as I mentioned already, files appended/merged should not be loaded as xref-dependent too. Or just fix Merge to be what they say it should is.

There is solutions, but they aren’t going to listen to just one guy. I am just trying to start a conversation. Kind of tough with very little contributions from the community or the other side (Autodesk) doesn’t even respond. 

[dgorsman]

The primary purpose of the forums is for user-based assistance, on the basis that day-to-day users have far more operational experience than the Autodesk project managers or developers.  AutoDesk have been pretty good about stepping in here, but for the most part we cannot have a guarantee there will be a response.

[matthew_breeden]

I understand the use of the forums. 

My original question still stands. How do you build an efficient .NWF when using Xrefs and Append/Merge? 

The discussion has gone beyond the common user, but it also needs the common user to show they too deal with this issue. 

Both of the responses I have received are valid responses yet I feel they are inadequate. They are more of a work-around (and a bad one at that) to deal with it. To actually fix it, requires input from the dev or product team. I think some insight into how they intended their program to work is just as valuable compared to what we as users have to do to get the program to function. 

[Patrick_Aps_9121]

I understand your problem completely. I have suggested to Autodesk 4 years ago that they should change the append and merge command in Navisworks into something similar as "Manage References" in AutoCad, so that you can change individually for each file attached
-> The path where the file is found

-> See which files attached are not found (instead of the message only when opening an NWF)
-> See the File properties (date, size) and be able to sort on those properties also
-> Have a Tree view to see why some files are attached twice
-> The reference depth (load references of the attached file or not) changeable PER file attached (instead of a setting for the whole program)
-> Perform a reload of a single file attached (with or without it's references)
-> Unload the data (but not loose the path and the overrides of the file. Unloaded files then should not be in published NWD's)

But still, there is no Navisworks IdeaStation to have this voted 😞

[matthew_breeden]

I agree with many of your ideas. The UI is not an easy nor intuitive thing to figure out. I’ve been using it for 10 yrs and still find new things. This is a barrier for many common users as it is too complicated when it comes to managing all the files.  

What is the normal route for software changes in Navisworks? Is there any discussion with users? Or is it just support-based input?

[Patrick_Aps_9121]

Ah, and some others:
-> being able to cut and paste the path's where the file is found
-> being able to select which direction is up for each file indiviudally: this could be a pull down with the options +Z / -Z / +Y / -Y / +X /- X
-> being able to see the file units and transform in the same dialog
-> being able to copy and paste the file units and transform from one attached file to another in one go (not copy -paste value per value)

The normal route for Autodesk products includes an IdeaStation. I have no Idea why Navisworks does not have one. The programmers seem to decide themselves what features are needed and in what direction they develop Navisworks. Making the basic features better is apparently not in their scope.
Another BIG to do is having a better Recap File reader, providing the same features that Autocad, Revit and Inventor already have when they append the same file.

[dgorsman]

The IdeaStations require active curation by Autodesk people (review, categorization, investigation, etc.).  There may not be enough people on the Navisworks dev team to handle the extra work load, or there may not be enough interest in doing so.

I don't have as many "wishes":

• XREF loading options (as discussed)
• slight improvement in material mapping e.g. cylindrical mapping only works for "up", not "horizontal" or "random angle"
• means to map Extension Dictionary/XRecord data attached to DWG objects into properties