Extrude & Maintain An Object's Set Class

[Bruce Kieffer]

Is there a preference setting somewhere that I have missed? When I create a 2D object and define it's class, I want to be able to extrude that object at a later time and have it maintain it's class, but VW changes the class to the active class. Maybe there's some logic to this that is lost on me.

[brudgers]

If they did it the other way, it wouldn't make sense to someone else.

Smells like a Vectorscript project to me.

[bcd]

Right click - Activate Class before extruding.

A step more than you want but faster than changing class after the extrude.

[brudgers]

If they did it the other way, it wouldn't make sense to someone else.

Smells like a Vectorscript project to me.

I just spent stupid time trying to use DoMenuTextByName('extrude',0);

But despite the documentation in the vectorscript appendix, I get:

Error: W DOMENUTEXTBYNAME - Menu cannot be found. Extrude.

All kinds of vectorscript functions for creating extrudes by passing arguments, but apparently you can't just call the menu item from vectorscript.

It's stupid.

[Kool Aid]

Well, here's some well-deserved Kool Aid for you:

Use one of the stupid VS functions.

[brudgers]

Well, here's some well-deserved Kool Aid for you:

Use one of the stupid VS functions.

I was trying to write a quick and dirty script to help Bruce.

Per the documentation, "extrude" should be callable by DoMenuTextByName.

But it isn't.

Yes, there are workarounds.

The goal was to modify the existing and familiar command to fit Bruce's workflow.

Not to reinvent it.

[Kool Aid]

How would the internal workings of a new menu command fit or not fit Bruce's workflow?

VS functions are not workarounds, but the VS representations of the actual C++ calls behind the standard menu commands, which one cannot modify.

[brudgers]

Modify as in wrapping it with additional functionality.

That's sort of the idea behind scripting.

Begin

[getclass of existing object to be extruded]

[run extrude command]

[change class of new extrude]

End

The VSextrude functions look lovely.

But implementing them with something like the familiar interface is more complex than just calling DoMenuTextByName.

At some point, I'll probably take another crack at it.

But I stand by my assertion that not being able to call extrude from the menu is stupid.

The fact that the documentation is just plain wrong, however, is pure Kool-Aid.

[michaelk]

Bruce

I'm glad you brought this up. Lately I've been thinking about it, too.

It's even more confusing than that (Let's assume you are always in the none class - or at least not in class 1 or class 2):

I can understand why an Extrude Along Path objects do it. If the profile is in class 1 and the path is in class 2, what's a poor cad program to do? Use the active class. Makes sense. If you turn off class 1 and class 2, the EAP is still visible in the active class. Because it now belongs to its new class.

HOWEVER...

If you draw a 2D shape in class 1 and extrude it, it belongs to the active class. I can see the argument both ways. But what confuses my poor little brain is the fact that making class 1 invisible makes the extrude vanish. Unlike the EAP. So is my new extrude really in the active class or class 1?

Even more confusing: Draw a 2D shape in class 1 and another 2D shape in class 2. Select both and extrude. The extrusion is in the active class. Set just class 1 to be invisible - nothing happens. Set just class 2 to be invisible - nothing happens. Set both class 1 and 2 to be invisible - extrude vanishes.

Sweeps and multiple extrudes behave like extrudes: the class of the original "generating" object controls the visibility of the 3D solid - which is in another class.

BUT...

Tapered extrudes don't behave this way. They really do belong to their new class. The class of the "generating" object doesn't control the visibility of the tapered extrude.

Lofts are a little different. But they've always been different. They seem to behave like tapered extrudes and EAPs.

So...

Is the best practice to create 3D geometry in the none class and then assign it to a class? (Because you'll probably never turn the none class off and using another class risks have the geometry disappear while you try to remember what class the "generating" object was in)

OR...

Is the best practice to use the same class for the 3D object and it's underlying 2D geometry?

And that brings us back to Bruce's question.

michaelk

Edited December 1, 2009 by michaelk

[Kool Aid]

Modify as in wrapping it with additional functionality.

That's sort of the idea behind scripting

Ahh: you are a Keyboard Sequence Programmer!

[Kool Aid]

But implementing them with something like the familiar interface is more complex than just calling DoMenuTextByName.

Indeed. You'll need 5 or 6 lines of additional code. Far more complex than your skills enable.

[brudgers]

Indeed. You'll need 5 or 6 lines of additional code. Far more complex than your skills enable.

Better it be beyond my current technical skills to help Bruce than beyond my character.

[Kool Aid]

So, did you help him? I've only noticed your whingeing and blame-shifting.

[Guest Frank Brault]

My understanding of the behavior is that the extrude is a container object that follows the behavior that all objects, when they are created, are placed in the active class. The special case about extrudes is that the parameters of the extrude are the object(s) that exist in their own class and the height, and location.

So the extrude is created in the active class and contains one or more objects that can be in their own class. When there are no objects inside the extrude container that are assigned to a visible class, then the extrude disappears.

[Kool Aid]

Indeed. Like this:

[brudgers]

My understanding of the behavior is that the extrude is a container object that follows the behavior that all objects, when they are created, are placed in the active class. The special case about extrudes is that the parameters of the extrude are the object(s) that exist in their own class and the height, and location.

So the extrude is created in the active class and contains one or more objects that can be in their own class. When there are no objects inside the extrude container that are assigned to a visible class, then the extrude disappears.

What's the story on DoMenuTextByName ('extrude',0); ??

[brudgers]

So, did you help him? I've only noticed your whingeing and blame-shifting.

At least as much as you have.

[Kool Aid]

Ohh, I tried to help you??Showed you The Way, my young friend? But you did not choose wisely.

[Bruce Kieffer]

Bruce

I'm glad you brought this up. Lately I've been thinking about it, too.

michaelk

Michael, all of you observations are great and lead me to thinking that there's far too much confusion and inconsistency in how classes are assigned. With the way I work, I could use a preference that says once I manually assign a class to an object, that object keeps that class until I change it to another class. I somewhat understand the "container" concept mentioned by Frank Brault, and I have no qualm with the container being set to a certain class, and it's contents being set to other classes. What I'm saying is; if at some point in my drawing process I manually change an object's class, then it should maintain that class until I change it again, no matter how I modify the object (like extrude it). I also see your point about an extrude along a path, but I think in that case I'd rather be presented with a dialog box that asks which of the two classes I prefer the resulting extrusion to reside in. With all of this said, I have to believe there is a logical explanation for why VW does what it does, but so far none of us have figured it out!

[Bruce Kieffer]

I have found the new (VW 2009) visibility tool is helpful to quickly identify classes of objects, and I find the select similar tool useful in this regard as well.

[Bruce Kieffer]

Right click - Activate Class before extruding.

A step more than you want but faster than changing class after the extrude.

bcd,

Thanks for reminding me of this tool. I will follow your advise.

[michaelk]

Bruce

Interesting idea for a preference... I like it. But it would necessitate a lot of dialog boxes.

What happens when you add or intersect a solid of one class w/ a solid of another class? Or add surfaces of different classes. Every time you do that a new object is created and needs a class assignment.

I get the idea that whenever an object is created (including an extrude "container") it springs to life in the active class.

Extrudes vanishing when the class of their 2D precedent's (components? parents? is there a term for this?) class is set to invisible makes sense - it behaves like a symbol.

Except when it doesn't. In the example of two polygons in different classes that are extruded together in a third class, half the extrude doesn't vanish when one of the "parent" classes are set to invisible. [That would be cool!] It only vanishes when BOTH "parent" classes are set to invisible.

So are tapered extrudes not really extrudes under the hood? Because they behave like EAPs and not extrudes when the "parent" class is set to invisible.

I agree, Bruce. It doesn't seem consistent.

Maybe we need a preference w/ three options:

1 Maintain "parent" classes whenever possible. Ask for class assignment if there is a conflict.

2 Always ask.

3 Use the active class. (current behavior)

I bet most people will be happy w/ #3.

michaelk

[Bruce Kieffer]

Bruce

Interesting idea for a preference... I like it. But it would necessitate a lot of dialog boxes.

What happens when you add or intersect a solid of one class w/ a solid of another class? Or add surfaces of different classes. Every time you do that a new object is created and needs a class assignment.

I get the idea that whenever an object is created (including an extrude "container") it springs to life in the active class.

Extrudes vanishing when the class of their 2D precedent's (components? parents? is there a term for this?) class is set to invisible makes sense - it behaves like a symbol.

Except when it doesn't. In the example of two polygons in different classes that are extruded together in a third class, half the extrude doesn't vanish when one of the "parent" classes are set to invisible. [That would be cool!] It only vanishes when BOTH "parent" classes are set to invisible.

So are tapered extrudes not really extrudes under the hood? Because they behave like EAPs and not extrudes when the "parent" class is set to invisible.

I agree, Bruce. It doesn't seem consistent.

Maybe we need a preference w/ three options:

1 Maintain "parent" classes whenever possible. Ask for class assignment if there is a conflict.

2 Always ask.

3 Use the active class. (current behavior)

I bet most people will be happy w/ #3.

michaelk

And maybe you've hit on why it works as it does... because there is so much inconsistency, that "use the active class" is the only option that makes sense. I would prefer your option one with how I use VW.

Edited December 2, 2009 by Bruce Kieffer

[michaelk]

Bruce

I think it would make more sense if the classes of the "parent" object either always or never controlled the visibility or attributes of the solid.

Now it depends on what kind of solid.

michaelk

[brudgers]

Is there a preference setting somewhere that I have missed? When I create a 2D object and define it's class, I want to be able to extrude that object at a later time and have it maintain it's class, but VW changes the class to the active class. Maybe there's some logic to this that is lost on me.

Here is a demo version of a menu command that does the job.

It will allow you to select multiple objects and create a separate extrude from each one.

The objects can be on different layers.

You can set different heights for each object.

Each extrude will be on whatever layer the source object was.

The non-demo version can be ordered from kludgecode.com as a menu command or a vectorscript.

It's $3.43 via paypal.