TheSwamp
Code Red => AutoLISP (Vanilla / Visual) => Topic started by: Joe Burke on October 16, 2006, 01:00:52 PM
-
Recently a client sent a drawing which needed flattening. I'm aware of the ET
flatten command and Mark Middlebrook's lisp routine named the same.
Niether one did the trick given the example drawing attached.
Mark's routine is limited in scope the sense it only deals with a limited set
of object types. And it does not deal with objects drawn outside of the WCS XY plane.
IOW, it simply resets certain Z coordinate values to zero. That's OK if that's
all that's needed.
Moving on to ET flatten. It attemps to flatten objects which are not parallel to
the WCS XY plane. Good idea I suppose, but the methods used seem questionable in
some cases. For instance, WMF out and back in are used. Look at the ET
flattensup.lsp file.
Futhermore, when I ran ET flatten on the example file it blew away the xrefs which
were not available. This was not evident until the file was saved, closed and reopened.
Obviously there's no reason it should do this.
I've also seen numerous errors like this:
Remove hidden lines? <No>:
bad argument type: lselsetp nil
Obviously an indication of poor programming.
So given all this I've been working on an alternative. But I'm very undecided about
what to do with objects drawn out of plane with WCS. Should they be projected to
the WCS plane? Or should they be translated intact to the WCS plane?
All comments welcome.
-
all the more reason NOT to flatten.
-
There's a lot of perfectly valid reasons to flatten a drawing including a client that is willing to pay for it.
:)
It's a challenging problem Joe -- I've written more flatteners than I can count, using everything from reverse engineering dxb plots to stratified wmf exporting / importing w/hidden line removal. I don't have AC2007 on this machine, is it possible it's ET Flattener has been updated (and fixed)? Do you need hidden lines removed?
-
In order to keep the flattener in vanilla AC2006 <which may have pooched custom objects> from bombing I dumped the unresolved xrefs, did some errant block cleanup. Anyway, see if the the attached will be of any use.
-
In order to keep the flattener in vanilla AC2006 <which may have pooched custom objects> from bombing I dumped the unresolved xrefs, did some errant block cleanup. Anyway, see if the the attached will be of any use.
Thanks, Michael. I'll look at it soon, but iI need some sleep now.
It's comforting to hear someone with your level of expertise has condidered the issues beyond what's readily available.
BTW, I'm using vanilla 2006.
I'll post a clearer example of the dillema I talking about soon.
-
It's comforting to hear someone with your level of expertise has condidered the issues beyond what's readily available.
BTW, I'm using vanilla 2006.
I'll post a clearer example of the dillema I talking about soon.
Sorry, I glossed over all the issues. IMO ... <colored by the deliverables I've had to produce over the years> The flattened product should be 100% WCS, regardless the various coordinate systems the geometry may sport. Layer retention and hidden line removal should be optional. Custom objects should be accurately rendered (may require proper object enablers etc). The flattened product should be free of any external dependencies. Obviously the flattener shouldn't bomb. Have you looked at any Autodesk LISP coding? The bulk of it can hardly be considered "professionally written"; but I digress.
The last flattener I wrote, which was many years ago used the wmf import / export technique (something I shared with Autodesk <in person> long before they came out with the ET Flattener). The accuracy is terrible unless you employ a tiling system to establish minimum areas to process (accuracy of wmf being a function of view resolution settings, screen resolution and zoom level). Bentley <more precisley the formely Rebis divisions> were working on a flattener that utilized the ObjectARX HLR algorithm (i.e. way better accuracy) . I don't know what state it's in or it's availability.
OT: I thought, needs sleep? Where does he live? Answer: Hawaii. I just heard on the news about the earthquake, hope you, your family and your island mates are all ok!!
Edit: Fixed spelling, re-organized thoughts.
-
OT: I thought, needs sleep? Where does he live? Answer: Hawaii. I just heard on the news about the earthquake, hope you and your island mates are ok!!
Second! Hope all is good for you and your family Joe.
-
Joe !
I've seen your dwg and use the official macro :
_move;_all;;0,0,0;0,0,1e99;_move;_p;;0,0,0;0,0,-1e99;
The problem is that I used it on all objects and it spreat some of the red 3poly on the top to incredible points (at huge X and Y).
So, if we exept the problem withe those few elements that I finally removed before the macro, the macro seems to be convenient and fast. Don't know if you know it.
-
Here's the example drawing I mentioned. It uses a text object to demonstrate my question regarding flatten.
TIA to all who have an opinion.
-
IMO the exercise of flattening is primarilly one of appearance, so while one might be tempted to retain objects in their native format as much as possible, you can't always have both, as evidenced by text / attributes etc. with a normal other than 0, 0, 1.
The upshot is you will have to choose between leaving some objects in their native format with a ucs or force wcs by replicating said objects with primitives (lines, arcs ad infinitum) so forshortening etc. is replicated faithfully. Simply from a consistency perspective I have to vote for the latter, as inconvenient as it may be and the data loss it may represent. If I want data / intelligence I go to the source documents, not flattened ones => they're dumb by definition.
/2˘.
:)
-
I tend to agree with Michel. It may depend on your purpose for flattening the drawing.
My goal when flattening is to have the geometry at one z & the text would also be at that
z, usually zero, and usually USC World. But I live in a simple environment. :-)
-
Michael,
The idea there may not be a simple answer to the question confirms my dillema. Thank you. I can live with that.
I guess it means you might want two programs. One aimed at maintaining visual integrity, and another more inclined toward data integrity. I think trying to make one program do both, with some user supplied option, would be messy at best.
-
A tangent question regarding the example file I posted.
How to transform the text object at the top of the drawing to WCS as shown at the bottom of the drawing using a 4x4 matrix derived from the the odd normal. IOW, use the tansformby method to rotate the object twice. Once along the X axis and once along the Y axis in one operation.
This rather than a brute force method which forces a new normal of (0.0 0.0 1.0) on the object, and then deals with the fallout regarding the willl move in space once that's done.
-
Hi Joe, why not just do something like the following?
(defun foo ( textEntity / data x y newInsertPoint newAlignPoint newNormal )
;; <idea code more than anything>
(setq
data (entget textEntity)
newInsertPoint (trans (cdr (assoc 10 data)) textEntity 0)
newInsertPoint (append (mapcar 'set '(x y) newInsertPoint) '(0))
newAlignPoint (trans (cdr (assoc 11 data)) textEntity 0)
newAlignPoint (append (mapcar 'set '(x y) newAlignPoint) '(0))
newNormal '(0.0 0.0 1.0)
)
(entmod
(subst
(cons 210 newNormal)
(assoc 210
(setq data
(subst
(cons 11 newAlignPoint)
(assoc 11
(setq data
(subst
(cons 10 newInsertPoint)
(assoc 10 data)
data
)
)
)
data
)
)
)
data
)
)
)
Or did I misinterpret your intent?
Edit: Forced Z ordinate of 0.0, something I missed in the first version.
-
Thanks, Michael. That seems to solve a separate issue which I won't bother getting into here.
The academic question was is there a way to sort of reverse engineer an object's Normal property? IOW, convert it to a 4x4 matrix which could then be passed to (vla-transformby <obj> (vlax-tmatrix <matrix>)). The desired result is the object's Normal property is (0.0 0.0 1.0) after it is transformed. Without forcing the property on the object.
"Academic" is the keyword. I'm just curious because it seems like it should be possible.
Regards
-
Joe !
I've seen your dwg and use the official macro :
_move;_all;;0,0,0;0,0,1e99;_move;_p;;0,0,0;0,0,-1e99;
The problem is that I used it on all objects and it spreat some of the red 3poly on the top to incredible points (at huge X and Y).
So, if we exept the problem withe those few elements that I finally removed before the macro, the macro seems to be convenient and fast. Don't know if you know it.
Thanks for your reply.
-
Thanks, Michael. That seems to solve a separate issue which I won't bother getting into here.
Ummm, glad to help?
The academic question was is there a way to ... <snip> ... convert it to a 4x4 matrix which could then be passed to (vla-transformby <obj> (vlax-tmatrix <matrix>)). The desired result is the object's Normal property is (0.0 0.0 1.0) after it is transformed. Without forcing the property on the object.
I'd say most likely achievable (doubtful via a single call) but my brain hurts too much right now to really think about it with an honest effort. Fortunately there is a lot of talent / expertise swimming about so I'd be surprised if you weren't provided a couple ways to skin this cat in relatively short order.
:)
-
I've also seen numerous errors like this:
Remove hidden lines? <No>:
bad argument type: lselsetp nil
Obviously an indication of poor programming.
More than just bad programming, bad data structure design! For 12 years I worked on another CAD system totally unrelated to any current system. We could easily "flatten" (your term) 3D data in any direction. We could flatten the z-coord to zero or any arbitrary number. We could also flatten about x and y. The reason was that all entities were defined as connected points. A polygon was n-connected dots. Every point had an x,y,z value. One form of the scale command functioned as a point editor. The x,y,z value of a point could be changed with a single command. Moving a point moved everything connected to it. So a command like:
move nodes scale z 0 about 0 0 0
would make all z node values equal to zero, taking all entities with them. Substitute scale z 5 in the above command and the z coordinate becomes 5 instead of zero. Say your building was on a 45 degree angle and you wanted a projected ("squashed") elevation. You could take the accurate elevation and squeeze it with:
move nodes scale x .5 about 0 0 0 (or what ever percentage factor needed).
This command changes the x coordinate to be x/2, and leaves the y and z alone. Hence, a projected elevation.You could also take a 3D hiddenline elevation and flatten it on x or y to achieve the same goal.
Imagine a jagged line, like a Wall Street stock chart graph. A command like:
move nodes scale y 0 about 0 1 0 would turn it into a horizontal flatliner at y=1. Scale x 12 would turn it into a vertical line at x=12. A circle would become an ellipse.
I bring this up because way too many people never think critically about their CAD system and what it's features are, and what it might be missing. Imagine a snap to 0 0 0? Or a snap to a polygon centroid? How about polygon shadows that have area?
Needless to say, when we were finally forced to use the 800 pound gorilla CAD system (you know which one). we were shocked at how little power it had.
My favorite bit of bad programming: why is dimensioning a subprogram?
-
Was that CAD system AES? That was my first cad system out of school in '93. Everything was command line driven - Add line . (grapically) or add line color 2 .
Led to massive amounts of shortcuts, the above were AL or AL2 col 2
What was amazing was to be able to change all lines color x on layers y to layer z in one step.
People who came over from AutoCAD hated it, I mean really hated it.
Dan
-
Yes it was AES. It was enormously powerful, and frankly beyond the ability of most users. But here we are, years later, and I am amazed to see features popping up in current software that AES had 20 years ago.
You may have seen talk about point clouds. We had a computer graphics PHD come to us a while back, proudly demonstrating the software he wrote do create point clouds. Everything in AES was based upon a point. You could draw the points only without any of the other data, hence: a point cloud. We did a project with BirdAir. all they needed were the points, because they had their own software. We sent them an excel file of every point.
The people who hated AES then were used to barely functional PC software. If I demonstrated the capabilities of AES to today's users, I am sure they would respond differently. After all, they've mastered 3D studio, Viz, Maya, Rhino, Microstation. Lisp, even Catia (what did I leave out?). AES wouldn't look so difficult anymore. It was way ahead of it's time. Most of the programmers who developed it went on to other positions in the CAD industry. An ACAD insider told me that the polar tracking in ACAD was created by a former AES programmer. AES had tracking too.
When will ACAD discover polygon transparency? AES had it. Not in the plot driver, but in the data. So you could have solid AND transparent polygons in the same drawing. You could cast a transparent shadow across a solid background in color. The color would merge with the underlying data. And the shadow had area. Twenty years ago! The list is endless.
I say this to encourage CAD users to think about the capabilities of their software. I'm tired of hearing people lament how ACAD can't flatten effectively. You bought a Cessna. Don't expect a Boeing. And don't knock Boeing because it makes your Cessna look bad. Of course, if you're only interested in short hops, the Cessna's for you.
To correct a misunderstanding, AES had a command line. But it had drop down menus and forms too. And the commands had user definable aliases that are way more powerful the the Acad PGP stuff. add line color could become alc. then you could type alc 2. But you could also type alc 5 or alc 55. The alias did not need to be complete. You could finish it on the command line. This is a common UNIX capability that monolingual PC users don't know about!
Rant over
-
I've also seen numerous errors like this:
Remove hidden lines? <No>:
bad argument type: lselsetp nil
Obviously an indication of poor programming.
More than just bad programming, bad data structure design!
Considering that one is taking a perfectly good 3D model and attempting to break it (for some unknown reason), one would expect some error in the broken result. Not necessarily bad programming, but maybe bad premise.
For 12 years I worked on another CAD system totally unrelated to any current system. We could easily "flatten" (your term) 3D data in any direction. We could flatten the z-coord to zero or any arbitrary number. We could also flatten about x and y.
I'm still looking for an intelligent reason for doing so? (other than antiquated CNC tools, but even that has an easier solution)
The reason was that all entities were defined as connected points. A polygon was n-connected dots. Every point had an x,y,z value. One form of the scale command functioned as a point editor. The x,y,z value of a point could be changed with a single command. Moving a point moved everything connected to it. So a command like:
move nodes scale z 0 about 0 0 0
and this is intuitive? Sounds like a hard version of the properties box.
Say your building was on a 45 degree angle and you wanted a projected ("squashed") elevation.
ummm... what the heck for?
move nodes scale y 0 about 0 1 0 would turn it into a horizontal flatliner at y=1. Scale x 12 would turn it into a vertical line at x=12. A circle would become an ellipse.
Changing the X or Y or Z scale factor of the XREF is a load easier.
Imagine a snap to 0 0 0? Or a snap to a polygon centroid?
No need to imagine, both have been available in AutoCAD for quite some time.
How about polygon shadows that have area?
again, what for? A feature may be very nice, but if it has little application, what good is "nice"?
Needless to say, when we were finally forced to use the 800 pound gorilla CAD system (you know which one). we were shocked at how little power it had.
Was that a "real" problem with the software, or the preconceived notions of the user??
My favorite bit of bad programming: why is dimensioning a subprogram?
I guess I need that one explained.
-
Yes it was AES. It was enormously powerful, and frankly beyond the ability of most users. But here we are, years later, and I am amazed to see features popping up in current software that AES had 20 years ago.
hmmm... such as??
You may have seen talk about point clouds. We had a computer graphics PHD come to us a while back, proudly demonstrating the software he wrote do create point clouds. Everything in AES was based upon a point. You could draw the points only without any of the other data, hence: a point cloud. We did a project with BirdAir. all they needed were the points, because they had their own software. We sent them an excel file of every point.
I think you'e missed the point (NPI) about point clouds, especially in the Survey/Surface approximation fields.
I say this to encourage CAD users to think about the capabilities of their software. I'm tired of hearing people lament how ACAD can't flatten effectively. You bought a Cessna. Don't expect a Boeing. And don't knock Boeing because it makes your Cessna look bad. Of course, if you're only interested in short hops, the Cessna's for you.
yada yada yada. AES was a heavy-handed bit of programming, as was GE-CALMA and a few other "big-boy" toys of early CAD development. And yes they had a few features that programmers thought would be handy for designers, but because they were programmers and not designers most of the features were just so much flash looking for application. As for AutoCAD not "flatten[ing] effectively, why in the heck should it? Instead of backing up to the way old programs did it and touting that as some good thing, look at the better way.
It like complaining about nail guns because you no longer have a use for your old hammer. All the rants about how good your specific hammer was for certain tasks aside, the obvious solution is stop using the old hammer to drive nails.
-
It like complaining about nail guns because you no longer have a use for your old hammer. All the rants about how good your specific hammer was for certain tasks aside, the obvious solution is stop using the old hammer to drive nails.
That is funny ... I find it quite amusing that when on construction sites I frequently see carpenters using their $400 nail gun as a hammer beating and pounding away at boards. Then they wonder how come it has to be worked on all the time. Go figure ...
-
It like complaining about nail guns because you no longer have a use for your old hammer. All the rants about how good your specific hammer was for certain tasks aside, the obvious solution is stop using the old hammer to drive nails.
That is funny ... I find it quite amusing that when on construction sites I frequently see carpenters using their $400 nail gun as a hammer beating and pounding away at boards. Then they wonder how come it has to be worked on all the time. Go figure ...
I saw a guy recently peeling the nails out of the wire strips and driving them with a hammer... I didn't ask, I was afraid of the answer.
-
dee-da-dee
-
I've also seen numerous errors like this:
Remove hidden lines? <No>:
bad argument type: lselsetp nil
Obviously an indication of poor programming.
More than just bad programming, bad data structure design!
Considering that one is taking a perfectly good 3D model and attempting to break it (for some unknown reason), one would expect some error in the broken result. Not necessarily bad programming, but maybe bad premise.
As usual, you presume too much.
I did not say a 3D model was involded when ET flatten returned that error.
-
As usual, you presume too much.
I did not say a 3D model was involded when ET flatten returned that error.
You're absolutely correct, I had assumed that we were talking about flattening a 3D model. Of course I have no clue why one would need to flatten anything other than 3D, but then there you are.
-
As usual, you presume too much.
I did not say a 3D model was involded when ET flatten returned that error.
You're absolutely correct, I had assumed that we were talking about flattening a 3D model. Of course I have no clue why one would need to flatten anything other than 3D, but then there you are.
Randy, I can completely understand his dilemna. I have received plans (2d) where some ignoramus had set the elevation var to something other than 0 for one line, then 0 for another and then another elevation for the third line. What you get is a hodge podge of varying z elevarions where hatching is impossible, regioning is impossible,and all sorts of other meaninful data gathering becomes quite the task. Mind you we are not talking about a 3d model her, but rather a 2d plan view that looks as if someone arbitrarily changed the z elevations on endpoints of lines for no good purpose ... or as I have seen prior. Rather than use an ellipse to approximate an angled view (in a 2d drawing) the user rotated a circle in 3d to make it look about right.
Anyway, there is a valid reason for using it, if for no other reason than to fix the mess caused by employees who are no longer with us.
-
As usual, you presume too much.
I did not say a 3D model was involded when ET flatten returned that error.
You're absolutely correct, I had assumed that we were talking about flattening a 3D model. Of course I have no clue why one would need to flatten anything other than 3D, but then there you are.
Randy, I can completely understand his dilemna. I have received plans (2d) where some ignoramus had set the elevation var to something other than 0 for one line, then 0 for another and then another elevation for the third line. What you get is a hodge podge of varying z elevarions where hatching is impossible, regioning is impossible,and all sorts of other meaninful data gathering becomes quite the task. Mind you we are not talking about a 3d model her, but rather a 2d plan view that looks as if someone arbitrarily changed the z elevations on endpoints of lines for no good purpose ... or as I have seen prior. Rather than use an ellipse to approximate an angled view (in a 2d drawing) the user rotated a circle in 3d to make it look about right.
Anyway, there is a valid reason for using it, if for no other reason than to fix the mess caused by employees who are no longer with us.
Except for the lunatic rotated circle for ellipse, wouldn't the properties box be a lot easier for 2d elements than flatten??
-
It would ... and I use that method whenever it is the most appropriate. Occasionally I find those where flatten is invaluable, but as you point out .. a "select all" and "Z = 0.0" works wonders on most of them except the occasional drawing where the lines are not parallel to the ucs, then changing the Z yields unpredictable results.
-
.. a "select all" and "Z = 0.0" works wonders
hmmm - in 2005 when I select all I don't have an option for Z
just color, layer, linetype, linetype scale, plot style, lineweight, and hyperlink
Dan
-
Look in your Properties Pallatte, you may need to look at specific entities, but you can flatten anything from there.
-
Comment as noted :
Look in your Properties Pallatte, you may need to look at specific entities, but you can flatten < almost > anything from there.
-
True, Mr. Brown. Thanks.
-
As usual, you presume too much.
I did not say a 3D model was involded when ET flatten returned that error.
You're absolutely correct, I had assumed that we were talking about flattening a 3D model. Of course I have no clue why one would need to flatten anything other than 3D, but then there you are.
Randy, I can completely understand his dilemna. I have received plans (2d) where some ignoramus had set the elevation var to something other than 0 for one line, then 0 for another and then another elevation for the third line. What you get is a hodge podge of varying z elevarions where hatching is impossible, regioning is impossible,and all sorts of other meaninful data gathering becomes quite the task. Mind you we are not talking about a 3d model her, but rather a 2d plan view that looks as if someone arbitrarily changed the z elevations on endpoints of lines for no good purpose ... or as I have seen prior. Rather than use an ellipse to approximate an angled view (in a 2d drawing) the user rotated a circle in 3d to make it look about right.
Anyway, there is a valid reason for using it, if for no other reason than to fix the mess caused by employees who are no longer with us.
Keith and Randy,
There are some situations which may cause the user to inadvertantly place objects or points at a Z elevation other than zero. For instance, xref a 3D site plan into an architectural 2D floor plan. The user draws over the xref, snapping to points in the xref along the way. The user is not aware of what's happening until he/she realizes the new drawing is all over the place in terms of Z coordinates.
In that case, the new drawing could probably be fixed by simply setting the appropriate Z values to zero with code.
On top of that and relatively new is the OSNAPZ variable. Which I doubt many users are aware of.
Regards
-
I seem to be getting more and more drawings as bad or worse than the one Joe posted. I can't quite figure out why this is happening, I find a clean 2d plan nice and fast, a 3d plan drawing just slows everything down for little benefit.
Lately we have been getting the odd mix of a 2d plan with a splattering of 3d objects thrown in here and there.
These 3d objects are sometimes imported from vector works or some such design programme, quite crash worthy, and they are the intention rather than a build to size. It's faster for us too draw in 2d, so I'll often spend 2 days cleaning up one of these plans. Randy I see where you are coming from but badly drawn 3d models are way harder to fix than badly drawn 2d models and we draw too many details to make 3d our staple.
It doesn't seem unreasonable to expect a program like cad to come up with decent flatten command or to be able to ask an architect for a 2d drawing. But like others I've written my own version of flatten (mine's only for 2d) while it is a good start vba sure sucks for changing the elevation of Dimensions.
-
I seem to be getting more and more drawings as bad or worse than the one Joe posted. I can't quite figure out why this is happening, I find a clean 2d plan nice and fast, a 3d plan drawing just slows everything down for little benefit.
Lately we have been getting the odd mix of a 2d plan with a splattering of 3d objects thrown in here and there.
These 3d objects are sometimes imported from vector works or some such design programme, quite crash worthy, and they are the intention rather than a build to size. It's faster for us too draw in 2d, so I'll often spend 2 days cleaning up one of these plans. Randy I see where you are coming from but badly drawn 3d models are way harder to fix than badly drawn 2d models and we draw too many details to make 3d our staple.
It doesn't seem unreasonable to expect a program like cad to come up with decent flatten command or to be able to ask an architect for a 2d drawing. But like others I've written my own version of flatten (mine's only for 2d) while it is a good start vba sure sucks for changing the elevation of Dimensions.
Post an example file.
I've written a bunch of code which tries to deal with objects which are either simply at some odd Z value, and those which are out-of-plane with WCS coordinates. What's hold me back is I simply can't see how some of the objects should be dealt with.
My original question. Should a flatten routine destroy a piece of text (explode to lines) which is out of plane with WCS simply to flatten it? And that assumes the operation is possible and reliable. Which in my experience, it isn't with WMF out and WMF in.
I temporarily shelved the project.
-
There are some situations which may cause the user to inadvertantly place objects or points at a Z elevation other than zero. For instance, xref a 3D site plan into an architectural 2D floor plan. The user draws over the xref, snapping to points in the xref along the way. The user is not aware of what's happening until he/she realizes the new drawing is all over the place in terms of Z coordinates.
I'm familiar with the results of untrained or incompetent users, but the better solution to that is not coding, but rather training. At least it is IMMHO.
In that case, the new drawing could probably be fixed by simply setting the appropriate Z values to zero with code.
the properties box does a fine job of that, unless the originating users is truly lame and has modified the extrusion direction of elements in some manner. There again though, the better solution is training, IMMHO.
On top of that and relatively new is the OSNAPZ variable. Which I doubt many users are aware of.
excellent point, and now more are aware thanks to your post.
-
Comment as noted :
Look in your Properties Pallatte, you may need to look at specific entities, but you can flatten < almost > anything from there.
Which means the Properties window is severely limited in terms of flatten with multiple object types selected. One line and one text object selected offers no option to change a Z value without what amounts to separate manual operations.
-
But you can isolate each object type in the selection box and alter the collective "z's" for each group en mass.
-
That's what I meant. It's basically a manual operation that way.
Code can do it easier and faster... if you can decide what the code should do.
-
That's what I meant. It's basically a manual operation that way.
I think you're missing the operation of the function. Once you've selected the entire drawing, its a maximum of 5 or 6 picks to change them all. That's hardly manual.
Code can do it easier and faster... if you can decide what the code should do.
Code could do it faster, thats why there have been several hundred attempts.
-
Joe, I've thought about putting all the non 0,0,1 normal entities on a separate layer, then giving the choice to change the normals.
I am sticking with the code way.
Randy I can't figure out how to fix dims with the 6 step process (Look at the nodes)
-
Comment as noted :
Look in your Properties Pallatte, you may need to look at specific entities, but you can flatten < almost > anything from there.
Which means the Properties window is severely limited in terms of flatten with multiple object types selected. One line and one text object selected offers no option to change a Z value without what amounts to separate manual operations.
Joe, you'll get no argument from me ...
If I thought AutoDesk took the Wish list system seriously flatten would be on my list
... so would programmatic exploding for NUS blocks
, so would ...
-
Randy I can't figure out how to fix dims with the 6 step process (Look at the nodes)
yet another reason to place dims in PS.