Civil 3D 2018 | Surfaces + MMS Files

[BlackBox_]

I'm working on a pilot project in Civil 3D 2018.

My existing surface is quite large, and upon import of LandXML, I'm presented with the MMS file in same folder notification - so be it, it seems to help the drawing open slightly faster.

Problem:  I've setup an existing conditions plan sheet drawing, DREF-ed said existing Surface into my sheet drawing, and now it too is presenting me with the MMS file in same folder notification.

So now, I have an existing surface drawing & +65 MB MMS file in my model folder (data shortcut source), and a sheet drawing with DREF to same that also has a duplicate +65 MB MMS file in the sheet folder. 

Why are duplicate MMS files being created?

If an MMS file has to be created (I don't know how to prevent it), then why on God's green Earth isn't the source MMS file being used for drawings that DREF same Surface?!

Cheers

[AllenJessup]

The MMS file has to be in the same folder as the drawing. So any folder that has a drawing that references the Surface has to have the MMS file. Why? Because they wrote it that way. I have no idea why they couldn't path to the existing MMS file.

[BlackBox_]

Hi @AllenJessup - Thanks for confirming the issue.

This is absolutely ridiculous; I must have missed or perhaps overlooked something?

As example:

I've just started setting up a small ACOE plan set to for a new residential subdivision, which consists of seven (7) 8.5x11 sheets, and is currently +352 MB in size in the project folder, including DWG, BAK, PDF, and MMS files.  17.8 MB of that is everything but redundant MMS files; one for each sheet drawing that DREFs the source existing Surface that also has its own MMS file in my model folder.

As comparison, in Civil 3D 2016, I did a similar set of plans, which consists of six (6) 8.5x11 sheets, and only takes up +13 MB in size in the project folder, including DWG, BAK, PDF (no MMS) files.

*IF* I've somehow NOT missed or overlooked something (and I REALLY hope that I have, please, let me be wrong?)... Then everything Autodesk has done here, needs to be undone immediately... Because I've done the math, and you're wrong.

[wfberry]

If I can remember correctly, MMS files are only created when the surface points reach a maximum, perhaps 2 million points.

Bill

[BlackBox_]

Creating an MMS file for a large Surface from Lidar, especially if it speeds up the opening of my Surface drawings, is perfectly acceptable.

It's not acceptable that MMS files be created for each-and-every-single drawing that has that Surface DREFed into it. 

*IF* I've not overlooked something, then someone messed up, didn't map back to the source Surface's MMS file, and this is an unacceptable change to Civil 3D that must have a December 2017 Hotfix. 

[BlackBox_]

It is my understanding that this has been assigned case no. 13647910 by ^LYN, and has separately been tagged as urgent by ^JEF.

Any ETA on when someone, anyone - perhaps @peterfunkautodesk, @TimYarris, or another on their team - might be able to at least confirm the issue?

Cheers

[TimYarris]

Hi @BlackBox_, 

We've just started hearing about this issue from other users. We're doing some research on this and will keep everyone posted on when we have an explanation/solution.

Tim

[BlackBox_]

Please and thank you, @TimYarris!

[BlackBox_]

@TimYarris - 

Just wanted to also note that I'm seeing a lot of application crashes in 2018; not that this is directly a result of MMS issue per-se, but another byproduct is that when recovering a given drawing, I'm always hit up with the 'some MMS file with this name <DrawingName>_<SurfaceEntityHandle>.mms cannot be found, please move it back to this folder or rebuild the surface....' message dialog.

Problem is, the MMS file being reported DOES exist, in that folder, with that exact name, and just isn't being found by Civil 3D.  I know that the AutoCAD team finally corrected the SAVEAS folder location for recovered drawings to be the folder where the recovered (and source) drawings exist, in the project, on the network.  Methinks Civil 3D is searching the temp folder where recovery drawing originally resided, in lieu of the actual folder on the network (if that makes sense).

My reason for that speculation, is that immediately following a SAVEAS to the project folder on the network, it's suddenly found again (even though it, and the recovered drawing were both there the whole time).

Cheers

[Anonymous]

We ran into this same problem. 2017-2018 Civil 3d started caching DREF into the drawings that they were being referenced into. To me that completely ruins the point of a DREF. To fix the problem follow the steps on the site below except change it to NO:

http://cadpanacea.com

[BlackBox_]

---

@Anonymous wrote:

We ran into this same problem. 2017-2018 Civil 3d started caching DREF into the drawings that they were being referenced into. To me that completely ruins the point of a DREF. To fix the problem follow the steps on the site below except change it to NO:

http://cadpanacea.com

---

I appreciate the attempt to help, @Anonymous.  :beer:

I've already done that, but it only helps with new drawings, and doesn't seem to do anything for drawings that have already been setup to consume the DREF surface (i.e., Profiles, Volume Surfaces, etc.) as changing that setting does not 'un-cache' the surface(s).  Setting Store DREF==NO after referencing a surface should 'un-cache' any/all DREFs at next sync, IMO (and that is NOT happening, as I've tried it on several DWGs w/DREF surface).

The trade off is not having surfaces cached just slows down the opening of drawings again with one or more large surfaces referenced.  Neither is really a viable solution; one is slower but takes up less network space (Store DREF==No), the other is faster and takes up more network space (Store DREF=YES).

Even with the surface cached to .MMS file, setting the overall surface to 'no display' and having a handful of smaller surfaces with the overall surface pasted into it and a boundary for just the vicinity I need, with a handful of flood stage surfaces to compare against, then a volume surface for each respectively jumps my drawing up to 259 MB DWG + 65 MB MMS. 

I can keep the drawing size smaller - down from the 259 MB DWG to 53 MB DWG - by applying a Hide boundary and multiple Show boundaries to accomplish same (rather than one smaller surface for each wetland crossing), but at the end of the day, the same data is being used as I still need individual flood stage surfaces for each to create the Volume surfaces, and those volume surfaces still have the same Hide and Show concept applied that they already had. 

The fact that the drawing is smaller for the same smaller surface areas suggest a big problem under the hood, as I completed the exact same calcs for each (the larger 259 MB + 53 MB DWGs); the larger being an easier setup for DREFing individual areas to keep my sheet drawings smaller, and the latter bloating my sheet drawings (never mind the MMS file issue, were that to propagate as well with Store DREF==YES).

I'm glad the Autodesk team took my and others' recommendations to leverage external database to speed Civil 3D up where it makes sense to (i.e., best of both worlds for LDC + C3D + Modern workstations), but this whole MMS business is a train wreck. 

Cheers

[mathewkol · Accepted solution]

This issue is caused by a new feature in Civil 3D. The ability to store surface data in the drawing containing the DREF. It is easily remedied and is NOT a bug.

Refer to an article I wrote in our blog.
https://blog.solidcad.ca/2017/11/08/civil-3d-2018-large-surfaces/

[mathewkol]

Just turn off that feature and all is well.

[BlackBox_]

---

@mathewkol wrote:
This issue is caused by a new feature in Civil 3D. The ability to store surface data in the drawing containing the DREF. It is easily remedied and is NOT a bug.

Refer to an article I wrote in our blog.
https://blog.solidcad.ca/2017/11/08/civil-3d-2018-large-surfaces/

---

Thank you, @mathewkol!

The second to last line - changing the 'Data Reference Status' in Toolspace with Surfaces node selected (far right, out of view [for me], not available from Surface Properties dialog) - is exactly what I've been asking for to disable this for drawings already setup to employ MMS file(s). 

I respectfully disagree that the behavior I describe here is not a bug - only a single MMS file is needed for this 'feature' making the redundant MMS files a bug, oversight, accident, whatever term you'd like to assign, and shall be fixed. 

I want to use this new feature (MMS files for large surfaces), because it actually does have a measurable performance benefit (as I've suggested to Autodesk team multiple times), but having one MMS file created for each-and-every-single drawing using the <DrawingName>_<SurfaceHandle>.mms file naming convention under the host (DREFing) drawing's folder is simply unacceptable, and Autodesk is working to rectify.

I'm anxious for Autodesk to fix this issue in 2018.2 update, as disabling this 'feature' makes the same drawings take +2x as long to open. Further, disabling this feature leaves the MMS file 'residue' in the drawing's folder (it should be deleted when disabled, or on sync, or save after being disabled, etc). So manual cleanup is required in the project folder(s).

Nonetheless, many thanks for documenting this information - I've just perused the help under several different surface-related topics, and am unable to find it (perhaps I've failed to look in the correct topic? No judgement on Autodesk here) - we users/admins can't make informed decisions without complete and accurate information, and you've just documented something Autodesk Help, nor the Autodesk team here (or in private forums) offered as a solution... For that, I thank you! :beer:

Cheers

[BlackBox_]

---

@BlackBox_ wrote:

... I've just perused the help under several different surface-related topics, and am unable to find it (perhaps I've failed to look in the correct topic? No judgement on Autodesk here)....

---

Found it finally:

https://knowledge.autodesk.com/support/autocad-civil-3d/learn-explore/caas/CloudHelp/cloudhelp/2017/...

[mathewkol]

Agreed, the software should pick up the MMS from the source drawing and not create a new one. Let's call it an "undocumented feature".

Oh, and I'll happily accept that beer 🙂

Glad to help.

[BlackBox_]

That’s all I meant where I may have stated bug; I don’t believe it was Autodesk’s intention to create them for ALL drawings that host a given DREF, and hope it’s fixed with 2018.2 shortly.

If you’re ever down my way (SW Florida), a few steins of your favorite frosty brew are my treat; I’ll even grill something that used to have a face. :beer:

... Now it’s time for my four hours of sleep a night. ;o)

Cheers

[rkmcswain]

mathewk wrote:.... article I wrote in our blog.
https://blog.solidcad.ca/2017/11/08/civil-3d-2018-large-surfaces/

I did not see a comment facility on your blog, but is this the same feature that was introduced in Civil 3D 2017? Or are you referring to something new about it, in C3D 2018?

There is a bug associated with this feature too. It may not be what this thread is about, but just be aware of this.

[mathewkol]

Indeed RK, it is no different in 2018 compared to 2017 as far as I can tell. I just happened. It must have been late when I wrote that article. 🙂

I actually am surprised that it hasn't been more prevalent with more and more users creating large surfaces.

[BlackBox_]

@TimYarris - 

Can you please confirm that Civil 3D 2018.2 Update released today fixes the redundant MMS files issue, for sheet drawings that DREF a large surface?

Yes, in a bit of irony, an external MMS file is created for a given drawing with a large surface, when 'Geometry Stored In Drawing' is enabled; not that I care, so long as it speeds up working in Civil 3D. Haha

Just wanting to know if I should see my DREF host sheet drawing's MMS files go away, once opened + saved using 2018.2, as they're now correctly mapped back to the original MMS source + Surface source drawing?

Cheers