Rendering and Hatching at State Plane Coordinates

Willy Campbell** hit me with a question a few weeks ago that I could not answer. He was rendering a scene… It might work once or maybe even twice, but then the render preview box would just keep coming up blank. This is the -render command or the “green teapot”. Real-time visual style application was working just fine.

image

Mike Appolo over at Autodesk was kind enough to help us figure out what the problem was, and was also nice enough to allow me to share the solution. Thanks, Mike!

The problem is actually similar to the old hatching issue. Have you ever had a hatch appear strange, maybe “broken up”, shattered fragments or irregular? Was that drawing at a high coordinate value, such as for state plane coordinates?

Read how to fix both the rendering and the hatching issue after the jump.

The problem is that some AutoCAD functions break down when you get very far from the origin. Most architects, mechanical designers and other CAD folks don’t really care much about coordinates, so they work down close to 0,0. Civil Engineers, GIS professionals and those of us that work with “real world” coordinates such as State Plane and UTM, are often waaaay up high in X and Y.

To fix the hatch problem, you could either physically move your drawing objects down to 0,0 (yuck) or change your SNAPBASE variable to a coordinate value that is closer to your objects.

Rendering is also a function of the AutoCAD platform, and therefore suffers from the same high coordinate breakdown. Unfortunately, there is no rendering origin or similar that can be reset. You must make yourself a second drawing for rendering purposes and move all of the renderable objects down to lower coordinates.

While this adds an extra step to the process, it most firms I’ve worked with, the folks doing the rendering make a copy of the drawing for their own use so that they can add extra bits and work their magic.

**Willy is a Civil 3D guru at PSOMAS. He is a rendering genius, a quick-draw Cannon Gunslinger and the “man who saved my AU class” by doing me the huge favor of picking up my handouts from the Venetian package center. If you attended the Civil 3D social on Monday night at AU, some of the renderings up in the slideshow were Willy’s. Willy, I salute you. You’re my BFF.

4 comments

  1. Jason Hickey says:

    I gotta say, Willy rocks. He’s not only a guru in something I know little to nothing about, but he’s one cool dude. I enjoyed hanging out with him in the exhibition hall.

  2. Brian Strandberg says:

    Here is a link to the best article I’ve seen describing this problem : http://aec.cadalyst.com/aec/article/articleDetail.jsp?id=369994

    My understanding is that the Autodesk civil group is trying to get a solution to this problem in an upcoming AutoCAD release. This doesn’t come up very often in other CAD disciplines but comes up in civil work often, so I don’t know how big a hurry they are to fix it.

  3. Jonathan Stewart says:

    Just an addition to these “high coordinates” issue.
    I’ve recently discovered that the “high coordinates” is also the culprit to the FILLET command and CIRCLE (ttr).
    These commands don’t seem to handle the “high coordinates” that are typically used in the civil arena.

    If you fillet an arc with a line in State Plane Coordinates, and if you change your precision to 8 decimal places, you’ll notice that the two arcs don’t really connect if you do a distance.

    Ever have the problem using CIRCLE (ttr) then you go and try to trim the objects????? Yep, you guessed it. The “high coordinates”. If you move the same objects close to 0,0; everything is just peachey, but than again, I’m pretty sure the world outside of the computer isn’t that close to 0,0,0… 🙁

  4. Jonathan Stewart says:

    Now I feel really small. I now just read the article http://aec.cadalyst.com/aec/article/articleDetail.jsp?id=369994 .

    Oh well…, the information is out there and shared, that was my intent. I just need to search other postings more closely.