Jump to content

class of extruded object vs. extrude


Recommended Posts

Is there any value in having the class of an extrude be different than that of the extruded object? If I need to change the class of several extrudes, I have to edit each one individually to also change the class of the underlying polygon, which can take some time. And if you miss doing this, you can get some brain-teasing visibility issues.

Am I missing a way to have a class change on an extrude propagate to the underlying objects?

Link to comment

If you assign the same class to the extruded object then you can make changes to them globally. So rather than changing the class name I would change the attributes of the current class or rename the class if desired.

Why different class? It gives you the flexibility to assign the extrude to a master class (structural) and the profile object to a sub-class (stud, column, steel beam, etc.).

Link to comment

Nicholas,

You might check out this thread about the same issue - https://techboard.vectorworks.net/ubbthreads.php?ubb=showflat&Number=198505#Post198505

Consensus is the current behaviour is a bug. The "brain-teasing visibility issues" can be very hard to track down and fix because of this.

Miguel, I'm not sure that you're entirely understanding the issue being described. It occurs when VW allows the source polygon for an extrude to be classed differently than the extrude it is used to create.

Cheers,

Kevin

Link to comment
  • Vectorworks, Inc Employee

I can not see a good reason for the classing to behave as it does now. At the very least it should be user-specified, similar to how you can auto class contained objects when creating and re-classing groups.

If the contained objects within the extrude responded to class attributes and visibilities as contained objects within symbols did, it might make some sense, but altering the class attributes of extrusion components mostly results in anomalous and unuseful behavior at the moment.

It has been submitted as an issue to be corrected (as well as a wishlist item just in case.)

Link to comment

Ditto to user defined auto-classing.

AND... the ability to move objects to other classes AFTER they've been initially placed WITHOUT their reverting back to their designated classes. (For example, it would be good to be able to place a dimension, then move it to the redlines class and have it stay there. Or, to be able to move a window to an existing class rather than its default (presumably "new") class. Because of this inability, I rarely use auto-classing.

Link to comment

Miguel, I'm not sure that you're entirely understanding the issue being described. It occurs when VW allows the source polygon for an extrude to be classed differently than the extrude it is used to create.

I fully understand what the perceived problem is since I do script programming and use extrudes extensively on my plug-in objects. I am aware that I should apply a class to the profile objects and not the extrude itself which is typically assigned to the default "None".

I understand that you want the profile object(s) to automatically get the class assigned to the extrude but what if the profile consist of two polygons and you want one to be yellow and the other red? In your scheme, you will need to create two extrudes with different classes. In the current behavior, you assign the different classes to each polygon and then extrude both at once.

I do not see a problem with the current behavior because as long as I am aware which part needs to be classed, I will get the expected visual attributes.

Link to comment
  • 5 years later...

I'm bumping this thread as it's something that causes me constant irritation. I note that it was "considered a bug" six years ago but nothing's changed. I'm forever going back into extrudes to change the class of the generating polygon, or changing the class of the extrude itself, because objects that I expect to be visible based on their class aren't.

Edited by line-weight
Link to comment
On 6/16/2014 at 10:54 PM, Miguel Barrera said:

I do not see a problem with the current behavior because as long as I am aware which part needs to be classed, I will get the expected visual attributes.

 

Here is one of the ways things end up in the wrong class - I create the profile polygon in the "right" class. I know if I'm drawing it in the wrong class because it'll be the wrong colour. (I use colour as my visual cue to how things are classed, at least at a "materials" level. I know that not everyone uses classes in the same way.)

 

Then I extrude it - and I extrude it in the "wrong" class, because I happen to have some other class active at that point, but there's no visual cue, because it continues to be displayed in the polygon's class. So it stays like that until I notice it's not showing up in views where it should be. And then I have to go and sort it out.

 

Confusingly, if I draw the polygon in the "wrong class", then generate the extrude in the "right class", the polygon stays in the "wrong class" and the extrude displays in the wrong class colours. But if I then change the class of the extrude, the polygon inside it changes too. This does not seem intuitive. Are the polygon and extrude classes independent of each other or aren't they?

 

I'm not sure your use case of two polygons inside an extrude, each of them a different class, is something that's commonly needed. If it is, then it'll be messed up whenever the class of the extrude is changed, for the reason I describe above.

 

 

Link to comment

So the confusing thing you mention happening with classing of extrudes and their polygons should be fixed. But I guess the other wider issue is that it is too easy to place things in the “wrong” class. My workaround is to always have none as the active class and yours is to use colour.

 

container objects like groups, solids and symbols are esp easy to place on the wrong class because they may not give a visual graphic clue that that has happened plus they can be troublesome when you notice objects aren’t appearing in vps when they should be. Is there a way vw could help the user avoid placing these objects on the wrong class?

  • Like 1
Link to comment
4 hours ago, Boh said:

container objects like groups, solids and symbols are esp easy to place on the wrong class because they may not give a visual graphic clue that that has happened plus they can be troublesome when you notice objects aren’t appearing in vps when they should be. Is there a way vw could help the user avoid placing these objects on the wrong class?

 

Maybe some more consistency would help...

 

> If you change the class of a group, then it doesn't change the class of the objects inside it (unless you ask it to).

 

> If you change the class of an extrude, it does change the class of the profile inside it.

 

> If you change the class of a solid addition, it does change the class of both solids inside it.

 

In these cases extrudes & solids behave similarly, and groups do something else.

 

 

> If you group an object, the group takes the "active class"

 

> If you extrude a profile, the extrude takes the "active class"

 

> If you perform a solid addition, it takes on the class of one (which one?) of the solids you've added.

 

In these cases groups and extrudes behave similarly, and solids do something else.

 

(I had to go and try doing each of these things to remember what happens. Because there's no easily discernible consistency, it's very hard for the user to remember what's going to happen in each case. Hence mis-classed objects galore)

  • Like 2
Link to comment
Quote

However I don't think that's everyone's workflow, and it's clearly not intended in the design of VW that the software should/must be used that way.

 

Of course it is not everyone's workflow since you already mentioned that you pre-class the objects and that is your preference. However, VW gives you the choice to do it either way. If the intention of the programmer was to corner you to do it only one way, then he would not allow you to change it in the OIP.

Link to comment
6 hours ago, Miguel Barrera said:

 

Of course it is not everyone's workflow since you already mentioned that you pre-class the objects and that is your preference. However, VW gives you the choice to do it either way. If the intention of the programmer was to corner you to do it only one way, then he would not allow you to change it in the OIP.

 

Sure, you can do it either way, but there are certain situations where using the "active class" method seems the most obvious, for example when I want to draw ten objects in the same class. It would be rather tedious to draw them all in "none" and then change them each individually. Much quicker to set the "active class" to what you want and then just draw them all. You might say it's user error to then forget to switch the "active class" back to none, but my experience is that this happens a lot. It seems I'm not the only one.

 

Sometimes there might not be anything wrong with the programmer's intention but it turns out that when it comes to real life use, the system created tends to make errors likely. For me, direct visual feedback is a reliable way of keeping track of what class I'm drawing in. If that's also how others work, then I think it's legitimate to criticise the way the extrude classing works.

Link to comment
9 minutes ago, line-weight said:

when I want to draw ten objects in the same class. It would be rather tedious to draw them all in "none" and then change them each individually.

The eye dropper tool is super handy in this scenario. I’ve even made an ‘E’ shortcut key for this tool so reassigning classes is super quick.

In addition I have a few scripts I use to help assign objects to commonly used classes. So whilst reclassing can be tedious with a few tricks it doesn’t need to be (and it’s nice to know things aren’t easily going to be placed on an incorrect class).
 

Admittedly, on the rare occasion when I will be creating multiple objects all in the same class then I might change the active class but I almost invariably forget to change it back.

 

In a team environment I strongly recommend sticking to none as the active class so if people are working on each files there is much less chance of error. 

Link to comment

I quite often work with a "guidelines" class active (especially in 3d). This is a class I use for setting-out geometry that I can switch off when I don't want it visible. It means I can quite quickly do a load of generating geometry, then draw the "real" objects and class them into whatever I want them. Because I can switch this guideline class on and off, I don't need to worry too much about cleaning up behind me. Sometimes I want that geometry left for future reference anyway. This wouldn't work for me if I stuck with "none" as the active class. Just my workflow of course.

Link to comment
Quote

when I want to draw ten objects in the same class. It would be rather tedious to draw them all in "none" and then change them each individually

 

why individually? you can change all the selected objects at once.

 

let me also say that most objects I create are custom made so the scripts assign their classes automatically and I do not have to do the post-classing for every object created.

Link to comment
7 hours ago, DBruhnke said:

Not if you have all the objects selected first.

I've become a big fan of the right click on a class in the Navigation Palette and "Assign to Selection". No picking up attributes required.

#JusSayin

#TooManyOptions?

You draw the ten objects... then you have to select them all. If you're lucky you can draw a window around them all - but if they are scattered around the place it's some scrolling around and shift-clicking to get them all selected. And if some of them are in groups... or on different layers....

Link to comment

Switching the active class regularly also takes clicks but rather than debating which way is better I think we can agree that neither method is ideal atm.

 

I think it would be a significant improvement in the program if changing the active class from anything other than none could somehow be less prone to incorrect classing of objects. E.g. For classing of container objects maybe a pop up warning that the container class is different to that of the objects inside it. (Actually for symbols what would actually be cool is the much wished for option to set an objects class "by Symbol" so the objects inside a symbol instance can take on the class of whatever class the symbol is placed in (sim to the autocad "by block" setting). 

 

Also perhaps a preference setting to set the active class to none on opening a file. Just some suggestions I'm sure there are better ideas...

 

Edit: Some of you following this thread might also be interested in this:

 

 

Edited by Boh
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...