Kitchen cabinet tools...more parametric dead ends

[line-weight]

My continuing attempts to use VW in a model-centric workflow...

I hadn't previously tried the kitchen layout tools - base cabinets, counter tops etc. But thought I'd give them a try.

Initially, I was quite impressed...this seems to offer a way to lay out a kitchen quickly, in 2d and 3d simultaneously, and there are reasonable options for style of door and so on.

But what about having enough control to produce a floorplan as I want it?

If I draw a kitchen in plan I like to show the countertop with the units dotted underneath. So it is clear that there's a continuous countertop, but also giving an indication of how many and what size units there are underneath.

So, I use the base cabinet tool, and it's got an option to "draw counter". Fine, but if I put two units next to each other they have a solid line between them. What does this line mean? It has no place in my drawing unless I want some kind of joint in the counter, and I obviously don't want a joint between every unit.

So I see that there is also a "counter top" tool. I try unticking the "draw counter" box in the base cabinet settings and drawing a counter top this way instead. I wonder if VW is going to somehow be clever enough to draw the base cabinets below in dashed lines. But as far as I can see, no it's not.

So I seem to have two choices for how my kitchen is drawn in plan - base units indicated but with solid lines dividing them, or not indicated at all.

Well, there is a sort-of workaround: I can draw the counter top in lots of separate sections, each sized to the base unit below. Because then it will draw each section of counter top with a dotted line at each "end" as long as I choose "none" in the "end finish" options. But then, what's the point of having them as two separate objects? Now if I want to change anything about the counter top I have to go through each section individually.

There's a final problem though. Assuming I've managed to set up my drawing so that there are solid lines where I want them and dotted lines where I want those...how do I then control those lines themselves?

In the settings for the base unit tool it seems I can control the solid lines to some extent by changing the object's class. But that doesn't even work consistently - for example choosing a heavier line seems to affect the line defining the back of the splashback but not the line defining the front. As for the dashed linea, it doesn't seem I can control this at all - I just have to accept what VW gives me, which is not consistent with my preferred dashed line style used elsewhere in the drawing.

The same applies to the counter top tool. (This has a mysterious "Style" setting in the OIP but choosing "new" just takes me to a dialogue box to create a new class. I don't know what good this is supposed to be).

Anyway, the upshot of all this (unless I have missed various things in which case please correct me) is that these tools just don't give me enough control to make them useful in top/plan view. They are handy for quickly building a 3D model of a kitchen but then this all has to be redrawn for top/plan view which kind of defeats, if not the whole point of them, a large portion of it.

This seems to be a continuing theme.

I think it's another example of where the top/plan view concept just doesn't work, as discussed in this thread: https://techboard.vectorworks.net/ubbthreads.php?ubb=showflat&Number=229752

If tools which work in this way are to be any use, then we have to have full control over the 2d representation of them. And this should be consistent. Some tools, I can control lineweights in a fair amount of detail (door tool, stairs, say). Why not in these?

Edited August 22, 2016 by col37400

[rDesign]

Don't bother with using either the Countertop ('draw counter' checkbox) in the Base Cabinet or the Countertop tool: Just use a Floor object for the countertop - it works much better. You can clip your sink templates out of the floor and it works just fine.

As far as your other points, yes - the Cabinet tools do need improvement (certainly regarding texturing, which is not very good). But I have been able to use the standard Vw Base / Wall / Storage Cabinets for 'most' of my usual kitchen cabinets. Only occasionally have I had to ungroup and break the Cabinet PIO in order to get what I want.

I also have accepted that graphically it may not be 100% to my liking, but I've found it to be good enough to get the design point across.

You can also try michaelk's Cabinet and Countertop Scripts. He made a bunch of scripts that will quickly lay out a group of cabinet PIOs and a countertop (floor object). I haven't used them very much, but it might help you with the countertop at least.

HTH.

Edited August 22, 2016 by rDesign

[line-weight]

Don't bother with using either the Countertop ('draw counter' checkbox) in the Base Cabinet or the Countertop tool: Just use a Floor object for the countertop - it works much better. You can clip your sink templates out of the floor and it works just fine.

As far as your other points, yes - the Cabinet tools do need improvement (certainly regarding texturing, which is not very good). But I have been able to use the standard Vw Base / Wall / Storage Cabinets for 'most' of my usual kitchen cabinets. Only occasionally have I had to ungroup and break the Cabinet PIO in order to get what I want.

I also have accepted that graphically it may not be 100% to my liking, but I've found it to be good enough to get the design point across.

You can also try michaelk's Cabinet and Countertop Scripts. He made a bunch of scripts that will quickly lay out a group of cabinet PIOs and a countertop (floor object). I haven't used them very much, but it might help you with the countertop at least.

HTH.

But if I use a "floor" object for the countertop, the problem remains - the cabinet positions below are not going to be dotted in. I still have to do that manually, and changes to the model will not be updated in the top/plan view. It also removes the handy facility to automatically generate a splashback.

I'll have a look at those scripts, thanks.

[line-weight]

Also: placing "wall cabinets" - again I don't seem to have any control over 2D line type and they are drawn in solid outline in plan, whereas they should be dashed, because they are above the cutting plane.

Edited August 22, 2016 by col37400

[rDesign]

The standard cabinet tools do require 2d annotation lines to show dashed base cabinets below counters. [The issues with the cabinet tools are long-standing].

Here's a thread that might give you some ideas of other workarounds regarding countertops: How to cut a sink into a countertop

The link to the movie in the first post is broken, which is good - as it's the standard Vectorworks not-very-good solution. Scroll to the end for better solutions.

[michaelk]

You can control the graphic attributes of the cabinets with classes.

I'll attach an example of a kitchen that has dashed lines for the upper cabinets.

Look at the dishwasher and under cab refrigerator in the example. You could also do that with base cabinets.

Those scripts are still under development. But I find that they are a way to get cabinets in quickly without having to measure first.

I usually turn off the countertop part of the script and do that separately.

https://dl.dropboxusercontent.com/u/4410711/Example%20Cabinets.vwx

hth

mk

Edited August 22, 2016 by michaelk

[line-weight]

You can control the graphic attributes of the cabinets with classes.

I'll attach an example of a kitchen that has dashed lines for the upper cabinets.

Look at the dishwasher and under cab refrigerator in the example. You could also do that with base cabinets.

Those scripts are still under development. But I find that they are a way to get cabinets in quickly without having to measure first.

I usually turn off the countertop part of the script and do that separately.

https://dl.dropboxusercontent.com/u/4410711/Example%20Cabinets.vwx

hth

mk

Thanks for this, it is kind of you to provide the drawing file.

Ok, I can see you have the upper cabinets in their own class, and you have the linetype for that class set to a dashed line. So in top plan view they are rendered as a dashed line outline.

A couple of reasons I don't find this an ideal solution.

I have classes which are just about linetype. For example I have a heavy line for section cut lines, I have a couple of "elevation" line types, an "overhead" dashed line type, etc etc.

Then I have classes that are for object types. So... a class for external walls, a class for internal walls, a class for loose furniture, etc etc. Including perhaps a class for kitchen fitout generally. I like to try and keep the number of classes to a minimum because I don't like unwieldy systems. Object type classes I mainly use to allow me to switch certain things on and off in viewports or other editing-mode views. So I might turn off kitchen fit-out items for a plan that's just about setting out partition walls say.

So, ideally I want to have a "kitchen fitout" class into which I can classify various things - parametric kitchen cabinets along with one-off things I've created from scratch. And then I want to define, for each of these things, how they are drawn in top/plan view and I want this done using my set of standard linetype classes.

This approach works with the "door" tool for example - I place the overall door object into my "doors" class, and then I can go into the settings and define how the leaf, frame, swing line etc are drawn in top/plan view, just by assigning one of my linetype classes to each of those elements.

This means that I don't constantly have to remember exactly which linetype I've used for overhead elements elsewhere...it all refers back to what I've set as my "overhead" linetype class. It also means that if I want to make a document-wide change to these linetypes, I just have to change them once, in the relevant class settings.

In a similar vein I have "material" classes which are only relevant to 3d renderings. So I have a "blackened steel" class and a "plywood" class and so on. Again, going back to the door object example, I can set the leaf, frame, etc to various materials by assigning these classes to them in the OIP settings. And again, it means that if I want to make a document-wide change to the look of my "plywood" texture then I just edit the relevant class.

So, my system gets broken if I put the upper wall cabinets in an "upper cabinets" class:

1) It's another "object" class that I don't really want, another class to remember/forget to switch on/off in viewports etc. And extending the logic, anywhere else that I have to control linetype by making new object classes, the overall number of classes potentially mushrooms

2) The linetype used to draw those wall cabinets now escapes my linetype-class system, so if I make changes to my general "overhead" linetype, I have to remember to go and edit the upper wall cabinets class too.

3) This happens to work for the wall cabinets but it doesn't work for the base cabinets where I need two linetypes to draw them correctly in plan - an elevational solid line and a dotted line for hidden detail. For objects like that, it doesn't work to set the linetype according to the overall object class.

Sorry for this lengthy reply. It's not a criticism of your system just an explanation as to why it doesn't work for me.

Maybe the class system I am trying to stick to is impractical/over-ambitious. I'm thinking out loud here to some extent. Any thoughts are welcome.

[zoomer]

Interesting, I played with these yesterday for the first time.

Because I have seen the corresponding tools from the other App's Demo

and was quite impressed.

I +1 for every improvement that will be made to the whole furniture toolbox.

For example, in this other world's Demo,

you have always exactly the same input/settings window, for ALL parametric elements,

like Walls, Doors, Windows, .... and Cabinets (!) etc.

With nice hierarchical sorted input fields and always a high quality preview.

All their GDL Objects first looked like our resource files at first view.

But these are all parametric and highly customizable.

(like adding dish washer, refrigerators, ovens, ....)

So I vote to get this in my (VW) world too.

(I fear that's what they gave us Marionette for ...)

BTW,

the 3D geometry of our cabinets isn't that bad, directly usable for 3D exports.

I see a lot of potential here. OK, the chimney tool wasn't the hit.

[line-weight]

Because I have seen the corresponding tools from the other App's Demo

and was quite impressed.

What's this? Revit?

Edited August 22, 2016 by col37400

[zoomer]

No, one of the family members that starts with Archi.

(maybe both brothers are at a similar level with these kind of tools)

I have never seen Revit in real life.

(Windows only anyway I think)

I just see that some of my clients construct and build successfully large

and complex buildings with it. That's a lot.

But it's far from being a design tool.

That's where I see potential in all 3 Nemetschek Apps.

Although some of them seem to be more potent in BIM construction.

Back to topic,

if the furniture tools in VW had a bit more potential, were easy and fun to use,

I would use them a lot and prefer them over resource libraries.

Edited August 22, 2016 by zoomer

[line-weight]

Ah, ok.

I think I used that application some time around 2000. The limitations I found in its parametric approach at that time completely put me off trying to construct drawings that way until very recently. I expect it has moved on a quite bit in the meantime.

[zoomer]

It wasn't ever and is not my dream App too.

But I heard it is seen as kind of direct competitor.

So I looked at the demo to see what is state of the art in BIM.

Beside that I see some gap there it is annoying that my top 100 of

VW no go's aren't any issue over there.

I like classic modern and reduced furniture, and it was easier to

create them from scratch than searching through libraries.

Currently I model those with solids.

But I would prefer parametric tools if the 3D geometry is usable.

If it also produces nice 2D output in Viewports I welcome it.

[michaelk]

Thanks for this, it is kind of you to provide the drawing file.

Ok, I can see you have the upper cabinets in their own class, and you have the linetype for that class set to a dashed line. So in top plan view they are rendered as a dashed line outline.

A couple of reasons I don't find this an ideal solution.

I have classes which are just about linetype. For example I have a heavy line for section cut lines, I have a couple of "elevation" line types, an "overhead" dashed line type, etc etc.

Then I have classes that are for object types. So... a class for external walls, a class for internal walls, a class for loose furniture, etc etc. Including perhaps a class for kitchen fitout generally. I like to try and keep the number of classes to a minimum because I don't like unwieldy systems. Object type classes I mainly use to allow me to switch certain things on and off in viewports or other editing-mode views. So I might turn off kitchen fit-out items for a plan that's just about setting out partition walls say.

So, ideally I want to have a "kitchen fitout" class into which I can classify various things - parametric kitchen cabinets along with one-off things I've created from scratch. And then I want to define, for each of these things, how they are drawn in top/plan view and I want this done using my set of standard linetype classes.

This approach works with the "door" tool for example - I place the overall door object into my "doors" class, and then I can go into the settings and define how the leaf, frame, swing line etc are drawn in top/plan view, just by assigning one of my linetype classes to each of those elements.

This means that I don't constantly have to remember exactly which linetype I've used for overhead elements elsewhere...it all refers back to what I've set as my "overhead" linetype class. It also means that if I want to make a document-wide change to these linetypes, I just have to change them once, in the relevant class settings.

In a similar vein I have "material" classes which are only relevant to 3d renderings. So I have a "blackened steel" class and a "plywood" class and so on. Again, going back to the door object example, I can set the leaf, frame, etc to various materials by assigning these classes to them in the OIP settings. And again, it means that if I want to make a document-wide change to the look of my "plywood" texture then I just edit the relevant class.

So, my system gets broken if I put the upper wall cabinets in an "upper cabinets" class:

1) It's another "object" class that I don't really want, another class to remember/forget to switch on/off in viewports etc. And extending the logic, anywhere else that I have to control linetype by making new object classes, the overall number of classes potentially mushrooms

2) The linetype used to draw those wall cabinets now escapes my linetype-class system, so if I make changes to my general "overhead" linetype, I have to remember to go and edit the upper wall cabinets class too.

3) This happens to work for the wall cabinets but it doesn't work for the base cabinets where I need two linetypes to draw them correctly in plan - an elevational solid line and a dotted line for hidden detail. For objects like that, it doesn't work to set the linetype according to the overall object class.

Sorry for this lengthy reply. It's not a criticism of your system just an explanation as to why it doesn't work for me.

Maybe the class system I am trying to stick to is impractical/over-ambitious. I'm thinking out loud here to some extent. Any thoughts are welcome.

I understand your desire to keep the number of classes under control. :-)

Also thinking out loud: I never used a 2D workflow (actually I did, but it was called a pencil.) so I don't have to deal with that kind of line weight question.

I tend follow the old drafting philosophy: "User Layers for where it is. Use Classes for what it is." The little 2D drawing I do is usually in classes called VP-xxx for grace notes to beautify viewport annotations.

Lately I've been thinking about using using line types for this. So a line type for overhead. A line type for demo. Those line types (especially overhead) can be assigned to classes, which still leaves the ability to globally change the line across different classes. I rarely get to use the same print shop twice, so it's also critical to me to be able to globally adjust line weight after the first print. I also depend on having a more extensive class system to create worksheets and especially for using the magic wand to select all of one type of object by class.

You're right. It's a lot of classes. And then you need worksheets and strategies to control the "empty" classes that litter the navigation palette. And the Autocad classes that can get imported into the drawing when you're not looking… I probably use more classes than you would like, but it's worth it to me to keep the model organized.

I'm not advocating you do this, but both the base and wall cabinets DO have the ability to control graphic attributes separately for 2D and 3D. The 2D attributes are controlled by the class the object is on or the attribute settings of the object. In the OIP you can set the class for the 3D elements: Body, Doors, Kick. (The pulls can also be in a class controlled by the symbol.)

Doors work the same way. You can have classes for the 2D leaf, swing, etc, and classes for the 3D panels, glazing, jambs, hinge markers, IDs etc.

So cabinet objects may not be good for your workflow. And there's a lot of things about them that really bug me. (Try inserting both base and wall cabinets in the same wall. I don't like that there's no way to not show the lines between wall cabinets in 2D.) But overall I find that they are great for at least the first several rounds of drawings.

-----

About those scripts. That bunch of scripts is sort of a minimum viable script for placing cabinets. It started from a frustration with having to measure the remaining space and adjust at least one cabinet in every run. I've been playing around with putting a dimension object in it's own class (another class!!!) below the cabinet on the same plane as the door of the cabinet. The idea is that in kitchen elevations you could turn this class on and already have the cabinet dimension below each cabinet with perhaps a description in the note field. Maybe even a label with ordering information for design/build shops.

I'll probably keep working on them to make it a path object so it handles corner cabinets and corner countertops. If I get ambitious and a lot of time (not sure which one is less likely…) I may try to combine them into a grand unified script. (But, as anyone who follows the vector script forum know, I'm terrible at scripting.)

But for now they work well enough that anyone else who shares my frustration with cabinets and countertops can quickly lay down a wall of cabinets without having to measure.

mk

[line-weight]

I'm not advocating you do this, but both the base and wall cabinets DO have the ability to control graphic attributes separately for 2D and 3D. The 2D attributes are controlled by the class the object is on or the attribute settings of the object.

The 2D attributes aren't fully controllable though (unless I'm missing something). As I said in my OP:

In the settings for the base unit tool it seems I can control the solid lines to some extent by changing the object's class. But that doesn't even work consistently - for example choosing a heavier line seems to affect the line defining the back of the splashback but not the line defining the front. As for the dashed lines, it doesn't seem I can control this at all - I just have to accept what VW gives me, which is not consistent with my preferred dashed line style used elsewhere in the drawing.

[Jim Smith]

I think a lot of this discussion is the result of HOW VW has two parallel approaches to how objects are created. The path of many PIO's is to manage visibility with Classes, and it can take hours to set. Not ideal, and if there is only one set of cabinets & counters in a project for example, using the PIO's may be a waste of time.

The other approach is a graphic one where one directly edits the object's attributes. It would be a super-duper fantastic improvement if VW allowed users to simply DOUBLE CLICK on a PIO Object & one would then be presented with the components that one could then edit by selecting & changing either the Attributes and or the Class.

We do this in our Pharmacy work, as we have developed a set of 3D/2D hybrid Symbols for the dozens of cabinets, counters, millwork panels & store fixtures. If one needs to alter the graphics of one of these Symbols, this can be achieved on the fly by simply altering directly the Graphics of the Symbol being edited.

I think Graphic editing of PIO tools would address col37400's point, & would make all PIO's less of an headache to use.

[michaelk]

col37400

You're right about that. I never use the countertop or backsplash included in the base cabinet tool because they look so bad in 3D.

[zoomer]

col37400

You're right about that. I never use the countertop or backsplash included in the base cabinet tool because they look so bad in 3D.

That's why there are solutions with tools that create a whole parametric

kitchen or similar. With only one single large countertop - in all kind of forms.

The cabinet tool would be just a tool to set one of the modules.

The more talented people (the dutch ?) start to build those tools in Marionette.

[Guest Wes Gardner]

Hi All,

I'm still finding the best way to maintain graphic control is to class everything. SAVED VIEWS are your friends!

Maybe in conjunction with some templated viewport "styles" (viewports with preset classes/lineweights) where the eyedropper can pick up the "style" and place it on your "working" viewport.

And yes, the cabinets are CONCEPTUAL.

Wes

[zoomer]

Hi Wes,

what does conceptual exactly mean in this case ?

Conceptual in a sense that these Tools where released in a conceptual state

and there are already 40 developers full time working in improving these,

or more a ... ahm ...

conceptual in a way these Tools were designed as conceptual Tools and

you don't necessarily need to use them.

I also favorite an excessive All-Attributes+Separation-By-Class approach.

(or Building Material, to be precise)

[Guest Wes Gardner]

Hey Zoomer,

Conceptual in the sense that they are not "real" cabinets. We have a popular program here in the states called 20/20 where you specify the ACTUAL cabinet by manufacturer. Our cabinets are more conceptual or generic, sort of "massing models."

This is how I have used them anyway knowing that I can't specify things like box thickness, door styles much beyond the (here's that word again) conceptual stage, etc.

Hope that helps

Before going any further, I'd have to check on interiorCAD, I believe that program CAN create "the real thing."

Wes

Edited August 24, 2016 by Wes Gardner

[RickR]

If Spotlight can have libraries of manufacturer specific lights then Architect should have cabinets, furniture, doors, etc. And not just 3DS imports.

However before that can be fully realized auto-classing will have to get straightened out. Real control of all elements both 2D and 3D is needed.

VW strengths are in the things other software doesn't do! It's weaknesses are in things it doesn't do.

[zoomer]

Hey Zoomer,

We have a popular program here in the states called 20/20 where you specify the ACTUAL cabinet by manufacturer.

Wes

Thanks, didn't know that. Cool !

Windows only (?), but cool.

Yes there is interiorcad.

But I think the Arch version of VW should have these tools at a certain level,

conceptual and reduced - yes, but at a certain quality.

Same as many of the Landscape tools like plants etc. but mostly none of the

Spotlight features (beside their trusses)

[Jim Smith]

I just looked at the 2020 site, & it looks pretty slick. I know apples and oranges, & who knows how fast the renders are, but heck, it would be nice to have the same kind of on the go renders.

[Guest Wes Gardner]

Hi All,

My kitchen has some curved walls that 20/20 couldn't deal with. So yeah, it has its limitations. Its strength is cabinets, period. The rest of the model goes lacking. At least in the version I saw.

Wes

[AlanW]

Hi,

Option is to set up your own with Marionette.

I'm playing around with one as a test.

See;

https://techboard.vectorworks.net/ubbthreads.php?ubb=showflat&Number=232327#Post232327

Well expand on to do benchtops with different nosings and door fronts etc etc.

Open ended options but in this test I am using a standard manufacturers sizes.