Jump to content
  • 2
P Retondo

The problem with parametric objects

Question

Don't get me wrong, I love parametric objects.  But as the name implies - "parametric object" is a term straight out of coding - it is a software design concept, not an architectural (or engineering or theater design, etc,) design concept.  The danger is that as designers we can be steered and nudged by the assumptions of the code engineer.  At what point do the design professions become captives of categories and limitations imposed by engineers with a different set of experiences?  CAD should expand our creative capability, not limit it!  CAD saves enormous amounts of time and creates great efficiency, but it should not limit those economic incentives to a standardized design palette.

 

Speaking for myself - I know others might differ - I find the mind-body connection in design works best when I have a pencil or pen in hand, and I have complete freedom to engage with abstract form without the intervention of more mechanical concept containers.  On the other hand, I want to go to 3d CAD as soon as possible to lock in precision and to look at things as they truly appear in 3d, as opposed to my hand-mind guesstimates.  My ideal parametric object, to get to the point, would be one with a graphical interface.  Take a stairs, for example.  I really don't want to design from a window with pre-selected options and a tabular, sequential arrangement requiring the input of numbers & checkboxes.  What I want is to draw the stairs in plan, then have the parametric take over to generate a 3d object that can then be edited with precision, allowing revision & further input as to tread thickness, tread overhang, construction type, etc.  I can do that manually, so I reckon there is no reason a parametric object couldn't be designed which would do the same thing but way faster and with greater power with respect to revisions.

 

Another example: door and window sills.  We shouldn't be limited to the sill assumptions of the VW window object, which are based on windows from the 19th century.  The sill could be an extrude, defined graphically by the user and saved as a type, instead of by a sill input window with 7 or 8 confusing parameters.  Same with window jambs, which almost never are rectangular prisms these days.  I'm sure I could go on, including the limitations of door types, the fact that "overhead" doors are incorrectly modeled not to overlap with the jambs, etc., etc.

Edited by P Retondo
  • Like 4

Share this post


Link to post

Recommended Posts

  • 0

This is a very interesting perspective and I have often felt when using CAD packages for lighting design that users are constrained by what the developer considers to be the best practice. This is the key reason why VW appeals to me so much. It is easily customised to suit ones own drafting practice. It has limitations too and a very good case in point appeared recently regarding the Spotlight Lighting device parametric object which it seemed was altered unilaterally by VW but due to users objections has been restored and improved as a consequence. So VW is stuck between those that are looking for a generic "quick fix" which a parametric option will give and those of us who look for bespoke solutions and are prepared to put in the hours to achieve those results. I think VW largely gets this right because through this forum and other forms of interaction with their user base, they respond to what the industry asks for (in my case lighting design). 

 

You are right though, if ways to create parametric objects could be found that are more fluid - perhaps taking a cue from the newer tools such as push/pull, deform, subdivision) and less dry (dialogue boxes and check boxes) then that would be a really interesting direction to take and feels like the way CAD is steering these days anyway. I am sure that Sketchup has been an influence on some of the newer tools that VW have introduced in the last few years.

 

It would be interesting to hear what others have to say.

Edited by markdd

Share this post


Link to post
  • 0

Pete, I agree 100%. But this is mostly about flawed - and lazy-  UI Design, not any one or group of parametric objects. I absolutely detest deep (multi layered) dialogs with lists. It's insulting and a total time suck (especially when one does not find what one is searching for within!). I have always said so. I love the general concept of "sketch it in plan" then "evolve it" in 3d (the same could be true from Elevation or Section to 3d).

 

What is interesting is that I often do just that, with window sills being the perfect example. I can draw the sectional profile and extrude so much faster than the &^%$ dialog (one of the worst in VW's). So that is often what I do. The huge bummer is that the sill is not attached to the window!! 

 

I always hope the engineers are paying attention to these sorts of postings!!

Share this post


Link to post
  • 0

Yes, Peter, that is exactly what I do as well!  I guess we could try our hand at Marionette, but unless I have a lot more time on my hands that I expect, that isn't likely.

 

26 minutes ago, CipesDesign said:

I can draw the sectional profile and extrude so much faster than the &^%$ dialog (one of the worst in VW's). So that is often what I do. The huge bummer is that the sill is not attached to the window!! 

 

Share this post


Link to post
  • 0

Gentlemen, what you wish for is attainable, but not without structure. There is no program that will fill in the blanks (i.e., go from 2D sketch to 3D detail) without clear decision making process outlined in advance. You can wish for purple cows, but until you show someone how to breed them, that wish will remain a wish. It will take someone, presumably one of you wishing for this new interface, to layout steps in great detail of how to proceed from a 2D sketch to a 3D object. Though you may not physically write the code, you can define the outline, the algorithm.

 

The hard part comes in at the extremes of good design, as when the aspect ratio (rise over run) of a sketch is too short to fit an acceptable number of steps on the staircase. How should the object respond at these limits. The design process is a recipe. If you have a recipe you believe in and want to see it realized, then you need to get with a programmer, or learn how to program. I recommend the former approach.

 

It all boils down to this (as Pete wrote in the initial post), if you can do it manually, it can be automated. Define the necessary steps and submit them, and don't forget to outline ways to interact with the object along the way of defining it.

 

Raymond

  • Like 1

Share this post


Link to post
  • 0
4 hours ago, MullinRJ said:

Gentlemen, what you wish for is attainable, but not without structure. There is no program that will fill in the blanks (i.e., go from 2D sketch to 3D detail) without clear decision making process outlined in advance. You can wish for purple cows, but until you show someone how to breed them, that wish will remain a wish. It will take someone, presumably one of you wishing for this new interface, to layout steps in great detail of how to proceed from a 2D sketch to a 3D object. Though you may not physically write the code, you can define the outline, the algorithm.

 

The hard part comes in at the extremes of good design, as when the aspect ratio (rise over run) of a sketch is too short to fit an acceptable number of steps on the staircase. How should the object respond at these limits. The design process is a recipe. If you have a recipe you believe in and want to see it realized, then you need to get with a programmer, or learn how to program. I recommend the former approach.

 

It all boils down to this (as Pete wrote in the initial post), if you can do it manually, it can be automated. Define the necessary steps and submit them, and don't forget to outline ways to interact with the object along the way of defining it.

 

Raymond

 

Have to say in this regards Marionette showed a lot of promise but seems scant on delivery.

 

I mean yes it's a visual scripting system so it is what it says it is on the box but... it is inside a cad program and yet the cross-over between drawn geometry and geometry the script can act on is as "hooptastic" as every scripting system before it.

 

If there was a scripting system that let me draw the prototype with primatives then use dimensions and constrains to link the meaningful points and finally use math and settings nodes control those points. I think it would have gone along way to addressing the reasons I agree with the original poster.

 

Share this post


Link to post
  • 0

For the most part I like the parametric objects that VW provides but they do need a good overhaul; stairs, doors and windows being the biggies.   When Marionette came out I was pretty excited but that excitement over time has been reduced due to time.  Revit I find does the parametric tool very well as it has a plethora of base tools from which to create your own parametric tools.  Still time is involved to put something together.  I wish there were more of others outside of VW that would be able to put together the tools we would like without having to wait the the next release of VW.

I have to agree with @MullinRJon how ultimately we need a set of "parameters" to begin to create any object.  In the mean time we are stuck with what we've got and we work with what we've got.

Share this post


Link to post
  • 0

OK, RJ, here is my algorithm for a graphical interface for stairs parametric object.  Once the object is created, the parameters are stored and available for editing in a dialog box.  

  • User creates a series of 2d closed shapes that represent the treads and landings
  • Click on each tread in sequence starting with the lowest tread to create an ordered list - we can't expect VW to know the sequence of the treads for every conceivable stairs configuration.  Option for whether top tread is at upper floor level or no.
  • Define the floor-to-floor height.  After this step, everything else is automated except for dialog box user interventions.
  • Extrude each shape an initial amount, then based on the ordered list define their Z values to create an evenly spaced set of treads.  Label each shape internally as a "tread"
  • If the user edits the tread thickness parameter, adjust
  • Prompt to create a profile for the tread nosing, which creates the tread overhang & nosing shape.  Extrude and add to each tread based on the known front face.  If the tread face is non-linear, extract a curve from the edge and extrude along path.  Note that once the sequence of treads is formed into a list, the location of the appropriate edge is also known.
  • From the same extracted curve or line, offset and close to form a plan-view riser shape, and extrude each.  Parameter for riser/no riser, and riser thickness is created.  Label each shape internally as a "riser" for application of class and/or texture.
  • Automatically create 2 or 3 stringers that fit to the underside of treads and backs of risers.  Option to edit thickness, depth, number, and whether the stringers are outside the treads.  Based on geometry of tread and riser edges.
  • Based on geometry of tread nose corners, create a NURBS curve and offset to code railing height.  Prompt for user to supply a shape for the handrail, and extrude along path.  Label shape as "handrail" and create parameters for number, height, and relationship to edge of stair.
  • Dialog box has option to create another tread or treads and add to the sequence, or to delete a tread or treads.

This will not cover every conceivable stairs, but it will be a start for more options than we now have, and note that once ungrouped it is a set of extrudes that can be edited.

 

It would be nifty if the sequence of treads could be created just by dragging the mouse over the shapes and allowing snapping to order the list.

Edited by P Retondo

Share this post


Link to post
  • 0

I like it. It's a little bit like Contours from Polys (in Site Modeling). It makes logical sense.

 

Share this post


Link to post
  • 0

What you have posted would probably be great as a description of how this should work in the manual, but is barely an outline for a programmer who does not have your innate knowledge of what you are trying to do. A proper description of every little step is needed along with what happens when the entered data does not make sense. 

 

For an experience VW programmer, the overall description probably needs to be 10-20 PAGES long. Go through what you are describing and do it manually and write down every mouse click and menu selection required to generate the stair. Include in that every mistake you made and how you corrected that error. Now you have the beginning of a description that could be programmed from.

 

I am not trying to be negative, but just trying to explain the level of detail that programmers need in order to have a truly working definition to work from. If someone was to start from your outline, they could probably come up with a one-off solution. As soon as you see it and say "Oh, it would be good if it could do THIS also", then all of the original design decisions have to be reconsidered. In many cases that requires throwing out some or most of the code and starting over.

 

The current Custom Stair object is compiled to about 700KB. My guess is that this is approximately 10,000 lines of code. After 20 years of doing this part time, my average speed of programming (including commenting, debugging, documenting) is about 20 lines per hour. Others might be 2-3 times faster, so let's say 60 lines per hour.  So for a 10,000 line script you are looking at between 150 and 500 hours of programmer time. Not something that anyone wants to take on without some kind of guarantee that there will be a payoff.

 

Again, I am not trying to be negative, but just to share the realities of programming with those not familiar with them.

  • Like 2

Share this post


Link to post
  • 0

That sounds like great fun :)

 

Similar like the (former ?) Bricscad Stair Light that starts by drawing a Rectangle.

 

Like,

Draw Rectangle in Top view or draw a line in a side view,

Stair Tool uses Story height for Stair and decides best ratio between steps and risers,

Oh, looks too steep - pull out the rectangle length to make the Stair longer,

time to set an Origin Point, where all later more detailed numeric input changes will grow from,

(Not necessarily the middle of the bottom start, maybe better the Wall's side from the top)

play with rectangle (= Stair) width,

Click the #steps/risers/tread text info to activate, use up/down arrows on your keyboard to play with ratios,

or activate the tread length number to jump in 0,5 cm increments by arrows,

RMB on Rectangles side opens Railing Option(s), pull in side views to adjust heights of panels and stuff,

activate a step to open tread components,

...

 

 

Same for Windows,

draw a line in a Wall from start to end in Top or any Side View,

Heights taken from Window Default Levels

(which will not disturb when searching for Levels for Walls or other plugins),

Click on Window to get a Menu for Sash #,

size changes by pulling the handles and snapping to lines or selecting other Window Level Presets,

...

 

So all Plugins controlled graphically by "Action Points" that will open Menus for specific edits inputs

that will appear in more and more detail as more as you zoom in your view.

 

So for a column, the plugin just needs an origin point, height automatically by

bottom of structure above Level. All graphical or input by menu changes from that point.

 

And finally moving one ore more selected things around by pressing ALT+SHIFT,

will automatically create a Symbol of it while copying these.

(With an intelligent default name like Symbol_Column_123)

And after half an hour VW apologize and ask if you are now willing to organize and rename the

20 new Symbols you created meanwhile, as long as you can still remember what you did so far.

 

 

Edited by zoomer

Share this post


Link to post
  • 0

One thing I keep asking for that I do feel would help us all love the parametrics of Vw better were if it were more real time instead of "enter data and hope."  I use these plugins for C4D work and find them to be much more user friendly than VW's. 

http://www.caleidos4d.it/plugin_win4doors.htm

 

Based on this system, one could have "presets" to load up, that would have the manufacturers' data already set up, or one could make their own and save the presets (like a symbol). 

  • Like 1

Share this post


Link to post
  • 0

Same for Modo.

That MArch plugin from a one man company does windows far easier and they look much more like Windows

than those VW from a 3D standpoint (Profiles extruded by Path, rubber seals, and those things)

Given what the Plugin Window Tool produces at the end, the settings are far too complicated, too much, not hierarchic, ...

 

Given that some other Software packages, more limited to Architecture only, seem to be a step ahead concerning

BIM and drawing generation, I think such a graphical and more intuitive approach could help VW to contrast from

more technical oriented competitors, to a more design oriented BIM solution.

 

Imagine all plugins creating first some automatic reduced standard versions that do not need any more input.

You examine your 3D model and do all e.g. Window changes in sizes and proportions graphically, until you are satisfied

with the design. Before you finally add more detail decisions step by step or throw some Styles on it.

Share this post


Link to post
  • 0
8 hours ago, Pat Stanford said:

What you have posted would probably be great as a description of how this should work in the manual, but is barely an outline for a programmer who does not have your innate knowledge of what you are trying to do. A proper description of every little step is needed along with what happens when the entered data does not make sense. 

 

For an experience VW programmer, the overall description probably needs to be 10-20 PAGES long. Go through what you are describing and do it manually and write down every mouse click and menu selection required to generate the stair. Include in that every mistake you made and how you corrected that error. Now you have the beginning of a description that could be programmed from.

 

I am not trying to be negative, but just trying to explain the level of detail that programmers need in order to have a truly working definition to work from. If someone was to start from your outline, they could probably come up with a one-off solution. As soon as you see it and say "Oh, it would be good if it could do THIS also", then all of the original design decisions have to be reconsidered. In many cases that requires throwing out some or most of the code and starting over.

 

The current Custom Stair object is compiled to about 700KB. My guess is that this is approximately 10,000 lines of code. After 20 years of doing this part time, my average speed of programming (including commenting, debugging, documenting) is about 20 lines per hour. Others might be 2-3 times faster, so let's say 60 lines per hour.  So for a 10,000 line script you are looking at between 150 and 500 hours of programmer time. Not something that anyone wants to take on without some kind of guarantee that there will be a payoff.

 

Again, I am not trying to be negative, but just to share the realities of programming with those not familiar with them.

 

Maybe this requires so many lines as it is because VW isn't as Object-Oriented as the sales pitch for version 8 made it out to be.

 

Not to mention most of the scripting we are talking about happens in miniPascal, Vectorscript and now Python in scripting environments that have poor UI support.

Rough stab in the dark I'd say at least half those lines are UI, made half again boiler plate code structure doing very little but routing information a round the code and doing math for things that should obvious. So I can write tools for myself it a couple hours that would take a month to make them good enough to deploy in the office and a year for general public release.

 

I mean the Easiest way to start a script was always draw the generic line work convert it vectorscript then go in to the generated code line by line tuning numbers in to parameters then writing lines of math to stitch that back in working code.  Then wrapping that in lines and line of boiler plate.

 

As you say this adds up to 10,000 lines of code and years of work to translate a dozen lines of pseudo code in to a working plug-in. What is worse is that there are no divisions in the code so everytime the script runs it has to transverse everyone of those 10,000 lines to find the 10 affected by the user change. So we end up with tools like curtain wall that are so complex that the runloop extends out and make all 3d editing tools useless as fire off countless runloops as you edit in some vain attempt to keep the preview updated.

 

Again, I am not trying to be negative, but the reality is Vectorworks Scripting tools are not well suited to the style of automation the programme generates demand for.

 

Edited by Matt Overton

Share this post


Link to post
  • 0

Pat, not to be argumentative, but I've written a great deal of C++ code for machine control.  Only a portion is done from scratch, objects and great chunks of code (modules) are already written and invoked in a single line.  I don't belittle the complexities of the task, just saying that for a CAD program that has been around for 25 years or so, it would not seem too high a bar to take a fresh and possibly innovative stab at how basic parametric objects work.  We have no idea, or at least I don't, how VW sourcecode is put together.  The handles we have through the scripting utilities are probably just toys compared to the resources the core programmers have access to.  But it would be a big job, no doubt.  Debugging and testing probably 75% of it!

 

I like zoomer's idea of working into an object bit by bit.  That's kind of what I'm driving at, a process more aligned with how creative design is done.

Edited by P Retondo

Share this post


Link to post
  • 0

Unfortunately, we have exactly the same toys as the professionals in Columbia. The primary difference is that when they get stuck, they can walk down the hall and talk to the guys who control the underlying code.

 

Originally all (most) of the PIOs were written in VectorScript/MiniPascal. When that proved to be to slow, some (most) were converted to C++ in the SDK (Software Developers Kit). This is freely downloadable by anyone who is interested. If you are interested, you should take a look.

 

As for prewritten modules, that is only true if you have already written them. When you are starting from scratch, the only modules available are the basic commands of the SDK which are very similar to the VectorScript calls. There are some things you can do in the SDK that you can't do in VS or Python, but not a lot.

 

So you are somewhat right. If someone was to start now and properly write a "framework" or some such and use that do write a DOOR tool, much of that code could be reused to write a WINDOW tool. Probably not much would be reused to write a STAIR tool. very different types of objects.

 

Per Matt's comment, yes the User Interface does take up a large part of the code, but not as much as he is suggesting. VectorScript actually does a pretty good job of isolating the user interface code from the VectorScript/Python Programmer. While it takes a lot of code to set up a dialog box, the actual code to operate the dialog box and get the user input is pretty low.

 

It would be great to stop time for about 4 or 5 years and stop the competition from moving forward so VW would have time to rip out all of the 30 years of history and start over with a completely different model. It would also be great is someone would donate enough money to support the all of the 200+ people currently working on VW as sales dry up because there is nothing new, only under the hood changes. Zoomer's idea is great. I just don't see an EASY way of grafting that onto VW.  I hope I am wrong.

 

On a side note, I have heard from a couple of programmers who have written large, commercial projects for VW.  They are telling me my estimates of number of lines of code programming time are off by a factor of 3 to 10. On the low side.

 

I love these types of ideas and types of discussions. I am just trying to make sure that the people who really don't have any idea of what it really takes to write computer code get at least a small dose of reality when they start talking about how easy it would be for someone to write a better tool to do X.

 

All done with a love of VW.

  • Like 1

Share this post


Link to post
  • 0
6 hours ago, Pat Stanford said:

It would be great to stop time for about 4 or 5 years and stop the competition from moving forward so VW would have time to rip out all of the 30 years of history and start over with a completely different model. It would also be great is someone would donate enough money to support the all of the 200+ people currently working on VW as sales dry up because there is nothing new, only under the hood changes.

 

That would be great.

Wished for this right from the beginning since I started with VW 2014.

I value this kind of featureless features much more than I miss missing new functionality.

Not sure if I am a minority and a software company would financially die.

I think a user can feel kind of a fragility of a software and at a certain point of complexity I tend

to need things being cleaned up before I am willing to accept any additional functionality.

 

I am a bit skeptical. If I look what is there today after such a long time.

And I see things I find very disturbing which stay there for years. So there may be other ambitions

or priorities than I would like.

Would a rewrite from scratch then bring the results I expect ?

 

 

But it would be nice to see if such core changes would be possible while keep running VW feature

driven life, beginning from the bottom by replacing relevant parts of its foundation.

Or would that need a complete external parallel development.

Share this post


Link to post
  • 0

Revit's family editor goes a long way to solving many of these problems.  You model the object the way you want it - no data entry confines.  Completely free modeling - then you put constraints and variables on it to teach the object its parametrics.  For doors and windows it is great - you can create exactly the door you want.   Eventually, as expectations increase, VW is going to need something like that.  

Share this post


Link to post
  • 0

Tom, it sounds like you're a Revit person stuck in a VW world!  That parametric utility in Revit sounds great.  I've never used Revit, got out of AutoCAD before they bought the company, and I've always wondered.  Before Revit AutoCAD 3d was a bad dream.

 

PS:  Pat, surely the SDK contains modules for things like dialog boxes, no?

Edited by P Retondo

Share this post


Link to post
  • 0
6 minutes ago, P Retondo said:

Tom, it sounds like you're a Revit person stuck in a VW world!  That parametric utility in Revit sounds great.  I've never used Revit, got out of AutoCAD before they bought the company, and I've always wondered.  Before Revit AutoCAD 3d was a bad dream.

 

PS:  Pat, surely the SDK contains modules for things like dialog boxes, no?

1

 

Ha - no. I am a Vectorworks person.  Used it exclusively for my whole career.  I have gone through several training courses on Revit over the years.  We are doing more and more collaboration with Revit firms and I thought it prudent to keep up with what our competition is using.  It does some things really well - so of course you start to dream of the super program that takes the strengths of both.  Their idea of Families and their custom parametric editor I still think is one of the strongest aspects of the program.

 

About 6 years ago when I did my first 2 week Revit training, VW was clearly superior.  Last year I did another once a week thing for a month - and I found that VW is starting to fall behind, at least when it comes to information modeling.  

Share this post


Link to post
  • 0

I think pursuing a custom parametric object creation system like Revit Family Editor is the right way to go. As Pat said, it is incredibly difficult to flesh out a new tool like Door or Curtain Wall and tic all the boxes needed by our entire user base. Instead focusing our efforts on a tool that allows users to specify constraints, materials, dimensions etc and letting them then save those sets as a reusable tool that they could then also share with their office or globally seems a wise direction to go.

 

There have been discussions here of such a tool, but I have not seen any hard implementations of it so far, I suspect mainly because of the aforementioned complexity in creating a system like this properly. (I would not want us to base it on any related to the current Constraint toolset, for instance, for various reasons.)

Share this post


Link to post
  • 0

The way Revit has it set up with their separate family editor mode or program makes me think it is pretty complicated.  It was a little tricky to learn at first, but once you got it down it was pretty fun.  I know I would probably spend way too much time making sure my doors and windows were exactly right.  

 

In a certain way - once you get it working right - an editor like that take a lot of pressure off of VW.  Many built-in tools could be replaced by families.  VW would not need to spend as much dev time on building up a stable of tools for tables, columns, and cabinets, and shelves, and doors, and windows - all that currently fall a little short of being fully customizable. All of that could be replaced by user created and shareable families - all built exactly to the project design.  

  • Like 1

Share this post


Link to post
  • 0

Yes, the SDK certainly does contain lots of code the things like dialog boxes and makes it relatively easy to handle.

 

Let's talk about the New Stair that was described above. Although the idea is to do most of the editing visually, it is often far easier to enter a numerical value if you know it that to fuss with trying to draw to the nearest mm.  Do you really want to have to zoom in to change the floor to floor height from 9 feet to 9 feet 1/2 inch? or would it be easier to just be able to type that in?

 

So at the minimum, the dialog box would need to have parameters for:

  Floor to Floor Height

  Tread Extrusion (stair width, possibly different for every tread)

  Riser/No Riser

  # Stringers

  Stringer Thickness

  Stringer Depth

  Code Railing Height

  Add Tread/Delete Tread buttons

  Class and texture information for Treads, Risers, Stringers, Hand rail.

 

So this gives us at least 16 different parameters to put in the dialog box.

 

Each of these needs at least one line of code to:

  Define the type of input (input field, check box, radio button, control button etc.)

  Define where the control should be located on the dialog box

  Define how to connect the information returned to the correct variable in the code so it will effect how the object is drawn.

  Define what the allowable or impermissible ranges of values are so the code doesn't crash

 

Add lines of code to:

  Define the Title of the dialog box

  Define the OK/Cancel/other control buttons

  Add descriptive text, preferably localizable

 

Even if every one of these things only takes a single line of code (and they don't many take more, especially since VW is multiplatform, you don't want to hard code the dialog layout, you need to allow VW to take your basic layout and make it look right on any platform). The amount of work to get more than a couple of items from a dialog box is very high.

 

If you can put everything into the OIP, then a lot of this is hidden and reduces the amount of work. But more than about 20-30 items in the OIP becomes difficult to handle and dialog boxes become necessary. If you want the user to be able to set the defaults for an object before it is entered (and visible in the OIP) a dialog box is required.

 

I just checked.  The Simple Stair object has 25 different parameters. The Stair object has well over 100 which is probably the minimum to allow a "flexible" tool like has been described. 

  • Like 1

Share this post


Link to post
  • 0
45 minutes ago, Pat Stanford said:

Let's talk about the New Stair that was described above. Although the idea is to do most of the editing visually, it is often far easier to enter a numerical value if you know it that to fuss with trying to draw to the nearest mm.  Do you really want to have to zoom in to change the floor to floor height from 9 feet to 9 feet 1/2 inch? or would it be easier to just be able to type that in?

 

 

I meant that there is also always displayed the numeric numbers too, that you can edit directly,

or just drag on handles if you prefer.

(If you activated that editing mode and zoomed in far enough into your drawing, setting details shown

dependent of zoom level)

 

This is an example how you could edit your plugins in a visual way or numerical way :

 

Screenshot-36.jpg

 

That is just a UI Layer above that feeds the Plugin Tool with data and more details.

At the end it is finally the existing "Stair Tool" that creates the geometry.

Like you would "rig" an Assembly in Modo. For example a character designer adds constraints and

options to a character that the animator will use all these preset sliders or input fields given directly

via the object, and just concentrate on the animation.

 

Like Richard Yot was kind enough to rig all kinds of photo studio lighting devices and give it to the community

download section (like Marionette assemblyies in VW), for example such a softbox with some controls

for the users that you reach by pressing the yellow dot :

 

Screenshot-38.jpg

 

 

Of course there can be access to the full feature Stair Tool or OIP if you prefer to access all numbers at once.

But currently it kind of forces us a bit to put in all numbers at this time. To make decisions at a point we

are not ready for.

 

 

I don't want to edit the floor height of a Stair at all (in 95%) as it has to go from this Story finish floor to the

one above automatically. And if you open a clean file VW will have already set of useful presets, for Stories

or Stairs or Windows.

That let a Window start as a reduced "framed glazing" type that you move and drag very easily until you are

pleased. And at one point decide that is quite good and it is ready to get some more details and save that

as a Style. 

Edited by zoomer

Share this post


Link to post
  • 0

Zoomer,

 

We have two different discussions going on here.

 

I am talking about the types of things that can be done using the existing environment. You are talking about what you something entirely new. Your "just a UI layer" is not something that could (easily?) be put on any type of an object in VW2017. It would have to be added at a very low level by VW, Inc.

 

It looks like a great way to define a placement and overall size of a window ( only 4 dimensions, but I would probably want the window size as well so you don't have to calculate it), but how does this work when you are doing something like a window with triple glazing , multiple moving sashes, muntins, all with very different scales. The ability to display what you need when you need it could be overwhelming for both the programmer and user.

 

Three things I have learned over many years of working with Vectorworks and VW, Inc.

1. It is better to tell them what you want to be able to do rather than how you want to do it. Usually, they have better ideas. In the past I have submitted wishes and told them EXACTLY what I wanted to do. When the fulfilled that wish, I found that the way it actually worked was just about useless and had to be modified.

2. They do listen. Sometimes it takes far longer for your priority to be their priority that you want, but many things eventually come around.

3. Things get better.

 

If you want an example of the direction things are going take a look at the Curtain Wall. It is not perfect, and there are things it can't do yet, but just a few years ago having an object like that that is graphically modifiable was almost unthinkable. I expect to see many other objects go this way once they figure out what works and what doesn't from an operator interface point of view.  Ship/Iterate/Ship/Iterate.

 

I think all of the ideas presented here are great and I hope VW is seriously looking at this thread, but these are all big ticket features and are likely to take a while to see in a released version.

  • Like 3

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

 

7150 Riverwood Drive, Columbia, Maryland 21046, USA   |   Contact Us:   410-290-5114

 

© 2018 Vectorworks, Inc. All Rights Reserved. Vectorworks, Inc. is part of the Nemetschek Group.

×