2013 C3D Surface issue never seen in other versions

[sfore]

See pic.  I'm using C3D 2013.  I received Aerial Contour Mapping.  I added contours, spot elev blocks and added a boundary. 

Surface is fine and definitions are present. 

Then, I perform an audit and surface definitions are gone and a snap shot appears in definitions that says 'created in recover command'...see pic.

Any idea why?

Could it be where I ran the contours through Drawing Cleanup to weed vertices first?  I usually run contours (polylines) through Drawing Cleanup to simplify objects and weed vertices before I add to a surface to keep file size down.  Today, I didn't do simplify objects because it caused a few contours in steep areas to cross other contours, so I only weeded out vertices.

[sfore]

Update: Drawing cleanup had nothing to do with this issue.  I just ruled that out.

I added contours and spots to my EG surface and definitions are present until I perform an Audit and as stated in prior post and shown in pic, definitions go away and a snapshot is created.  Makes no sense.

Can Autodesk answer this, please?

[Jeff_M]

If you need a response from Autodesk then you should log a Support Request through your Subscription Center portal. 

What does Audit report when you run it? Can you provide a copy of the drawing prior to the Audit?

[sfore]

audit...see pic.  yes, i have a copy of the drawing before an audit with definition shown.  i'll also try to go thru mu subscription center to get an answer.  if you want a copy of the drawing, let me know.  its about 22mb.

[sfore · Accepted solution]

Update:  Fixed issue. 

The problem was how I added the boundary.  Initially, I used the mapping limit polyline as my boundary with Non-Destructive toggled 'ON'.  Then I went back to original, deleted boundary and re-aded with Non-Destructive toggled 'OFF' and definitions remained.

I guess where surface was built from contours and they stopped at the mapping limit polyline which was used as a boundary with Non-Destructive toggled 'ON', that caused the surface to get corrupt.  Lesson learned about Non-Destructive boundaries.

[Jeff_M]

Make sure to mark your post as the solution. And thanks for posting it! That should help others in the future.

[fcernst]

"Make sure to mark your post as the solution"

No absolutely not. This should be sent in immediately as a Product Defect in order to let the Civil 3D team know.

Non-Destructive boundaries preserve the integerity of the surface. They should be the first choice for boundary. 

This is another miss by the Beta Testing program.

"I guess where surface was built from contours and they stopped at the mapping limit polyline which was used as a boundary with Non-Destructive toggled 'ON', that caused the surface to get corrupt.  Lesson learned about Non-Destructive boundaries."

OP: Please remove the Solution marking... Marking this as a Solution only serves to help inhibit the problem being appropriately addressed, and to lead other astray.

[sfore]

I never had contours outside of the mapping limit, so there was nothing to triangulate outside of the boundary.  The contours I added to EG stopped at the mapping limit which came from the mappers, and that is what I used as my boundary line inside my surface definition.

Not so sure it's a product defect as much as a UE (user error) on my part.  I could've left Non-Destructive toggled 'ON' IF, I would've offset the boundary in just enough to where the contours extended past.  That would've worked also because then there would've been possible triangulation past boundaries....correct??

[Jeff_M]

I strongly disagree, Fred, regarding the "mark as solution". This solved the problem the OP was having with the corrupted surface so he no longer got that corruption. If another user runs across the same problem and finds this thread to help them with the workaround, then it IS a solution to their immediate problem.

However, yes, it SHOULD work as he was doing and should be logged as a support request. Please remember that this forum is mainly for peer to peer support. It is NOT a place to be posting bugs and expecting a fix, that is what the Support Portal is for. Whether this thread is marked as solved or not, will not affect any actual support case opened with Autodesk.

[Jeff_M]

sfore, that is what I thought may have been going on. If the boundary ends up being coincident with the polylines defining the contours then I can see how this may confuse/corrupt the surface. There are likely many TIN lines affected by this.

[fcernst]

Jeff, this is a systemic problem I see regarding the quality of the software.

Civil 3D management prioritizes repairs to the software as a function of Customer feedback and perceived amount of use implicating the Defect.

So therefore how do we expect to have robust software suitable for rigorous civil engineerring application, if we have  "Expert Elite" instructing new Customers to bury the Defect with a "Solution" tag?

[fcernst]

"Not so sure it's a product defect as much as a UE (user error) on my part."

No, this is not your fault. The drawing should not corrupt itself. You should be able to select and use a non-destructive boundary at any time without corruption.

[fcernst]

"Whether this thread is marked as solved or not, will not affect any actual support case opened with Autodesk."

Again, this is more poor information going out to the new users wondering how the feedback cycle works for the  prioritzation by Civil 3D management of resource allocation for repairs to Defects.

[Jeff_M]

---

@fcernst wrote:

So therefore how do we expect to have robust software suitable for rigorous civil engineerring application, if we have  "Expert Elite" instructing new Customers to bury the Defect with a "Solution" tag?

---

I am not instructing anyone to bury anything. First, I don't believe this to be a major Defect. It came about due to specific conditions, that has not been an issue for anyone else to his point (at least I couldn't find any in my searches). Second, as I stated previously, a Solution, in my opinion, on these forums should be marked if it provides a method for the user to get past the the issue they were having...be it an actual solution, workaround, or a completely different way of performing the task. Third, again as I stated before, if further resolution is desired/needed then a support case should be opened.

[sfore]

Not to sound negative, but I'm hesitant to open up a help ticket with something like this that actually is resolved, just to be told Development Team is working on it.  I opened up one and also posted a real defect a few months ago and it never got resolved and it was something that worked fine in 2011, but suddenly became broke in 2013....point cloud classifications with .las (lidar) files and surface creation.  See post.   http://forums.autodesk.com/t5/AutoCAD-Civil-3D/2011-vs-2013-point-cloud-colors/m-p/3682862/highlight...

To my knowledge it never has been resolved.  I tried it again after I installed SP1 and the surface was still whacked.

[fcernst]

"Third, again as I stated before, if further resolution is desired/needed then a support case should be opened."

You are not following me. Instabilites, corrutption concerning boundaries should be encouraged to be immediately reported. Not only if "further resolution is needed.."

Think this through a little further, if you will.

Example:

There is a problem with crashing during Corridor modeling in 2013 and 2014. It occurs at different times, different operations going, sometimes just sitting there looking at the Corridor. They say to re-trace your steps, and it's practically differtent every time.

Could it be due to a systemic instabilty problem with the ubiquitous non-destructive surface boundary(ies)  in the background?

Follow?

[Cadguru42]

---

@Jeff_M wrote:

---

@fcernst wrote:

So therefore how do we expect to have robust software suitable for rigorous civil engineerring application, if we have  "Expert Elite" instructing new Customers to bury the Defect with a "Solution" tag?

---

I am not instructing anyone to bury anything. First, I don't believe this to be a major Defect. It came about due to specific conditions, that has not been an issue for anyone else to his point (at least I couldn't find any in my searches). Second, as I stated previously, a Solution, in my opinion, on these forums should be marked if it provides a method for the user to get past the the issue they were having...be it an actual solution, workaround, or a completely different way of performing the task. Third, again as I stated before, if further resolution is desired/needed then a support case should be opened.

---

I don't agree with that statement. Autodesk has a major issue where all of their programs starting with 2013 ignore the UNITS header for a GeoTIFF. The workaround is to turn off any coordinate system in the drawing/project then turn it back on after insert. That is a workaround, but doesn't solve the problem.

Would you consider the fact that the QTO system doesn't read subassemblies correctly as corrected? One workaround is to just not use QTO. Would you consider that as being solved?

Not trying to fight or sound bitter. It just doesn't make since to mark something as solved if it actually hasn't been.

[troma]

There have been requests in the past for "Accept as Workaround" & "Accept as Known Issue" buttons. In their absence, the consensus appears to be to use "Accept as Solution" for all of them.

[fcernst]

"the consensus appears to be to use "Accept as Solution" for all of them."

This forcing upon of "Accept as Solution" is not good for Customers. 

Accepting defects and "dumbing down" of the software and procedures is never good...slippery slope...

[Jeff_M]

---

@engrtech wrote:

---

I don't agree with that statement. Autodesk has a major issue where all of their programs starting with 2013 ignore the UNITS header for a GeoTIFF. The workaround is to turn off any coordinate system in the drawing/project then turn it back on after insert. That is a workaround, but doesn't solve the problem. Yes, it's a workaround and allows the user to keep working with the GeoTIFF. It may not be a permanent solution, but until there is one it is currently the best solution avavilable.

Would you consider the fact that the QTO system doesn't read subassemblies correctly as corrected? One workaround is to just not use QTO. Would you consider that as being solved?

No, I would not since this does NOT allow the user to use the tool in a manner to continue with their project.

Not trying to fight or sound bitter. It just doesn't make since to mark something as solved if it actually hasn't been.

---