OOTB Multiple Visibility States - SOLUTION!

[Libbya]

I have done a fair amount of thinking on how to create multiple visibility states without using the broken vis-add-eng LISP and have come up with a workaround solution!  Obviously, doing all the itterations for multiple visbility states is a bit cumbersome, but at least there IS a workaround.  See attached.

[Libbya · Accepted solution]

An explanation:

I created the left and right squares, circles and triangles.

I defined all the possible itterations of visibility states, e.g. square - square, square - circle, square - triangle, square - off, etc....

I defined a Left and Right move parameter.  Each have 4 possible increments, no grips and move a circle that is hidden for all visibility states.  Essentially, the move parameters are both invisible and exist solely to give an input parameter for the left and right lookups.

I added Left and Right Lookups that have the state names (square, circle, triangle, off) and move the hidden ball to its specific location for the specific state.

I created a 'Bridge' Lookup parameter that links two lookup tables (right-click the lookup parameter tool on the palette and add two lookup actions to it).  On one of the lookup tables I placed all of the visibility states and on the other table I used the two move parameters as inputs and made all of their states correspond to all of the visibility states.

Clear as mud?

Anyone have any ideas on how to simplify the method?  

[jarredmonday]

This is very interesting. Thanks.

I like your examples. I'll work on something, per your instructions, within the next day and post it.

[Libbya · Accepted solution]

Right on.  I'll be interested to see what you come up with.  Let me know if you encounter difficulties.

Attached is a modified version of the above file.  In this one I added a third 'visibility'.  The obvious limitation to this method is that the number of permutations grows very rapidly.  The number of choices for each 'visibility' is multiplied together to find the total permutations.  In other words, if you have 4 choices on one, 4 choices on the next and 3 on the third (like in the attached file) the total permutations is 4x4x3 = 48.  The busywork of assembling the choices correctly is significant as the 48 individual visibility states need to be created and then the lookups need to be correctly constructed...  A very simple lisp routine could be used for creating the actual visibility states, but I am not sure how to edit the lookup tables via lisp.

In the attached file, for the input parameters I used the distanceX and distanceY of one invisible point move and distanceX of another.  I placed them at 0,0 so that the positions are more intuitive. 

[Libbya]

I did a little more testing and the point move parameter does not actually need to move anything or have any action attached so no need to have the hidden circle moved around.   

[Ron_M]

I find that the Add-Visibility-Engine works fine.

[Libbya]

Vis-add-eng doesn't work at all for anyone using a version of AutoCad later than 2010.  Even prior, from what I can tell, it has fairly significant limitations.  How do you add that flip action after-the-fact?  I think it's better than this option once you have to make more than 50 or so visibility states, but for anything smaller, I would rather use this method.  Don't get me wrong, it has its uses and I have an earlier version of CAD installed JUST for visibility-add-engine, but it only gets used for the more extreme case.  For example, I am currently working on a block that without vis-add-eng would require over 2,000 visibility states.  Obviously that isn't time effective to make without vis-add-eng, but when, down the road, I find that I want to add another set of dynamic actions I will be cursing having to remake the whole block...

[Ron_M]

I understand that visibility-add-eng doesn't work for all and not for verticals > 2010.  I have and will hang onto 2010 until such a time as something comes along that allows multiple visibilty parameters.  Hopefully Autodesk listens, what am I saying, they won't.  Maybe when I get done with my current 6 month (so far) process of re-writing VBA to VB.NET for another office I'll take a serious look into re-working visibility-add-eng.  Sounds like a fun project.

2000 visibility states?  WOW!!!  Share that piece of work just because you should be proud.

Added 3 flip parameters.  Took about 4 minutes.  I understand that this block comes nowhere near yours in complexity, 2000 visibility states, WOW!!!  I feel so inadequate. 

[Libbya]

I said that without using vis-add-eng it would require over 2000 visibility states.  I will be using vis-add-eng for that block so the number of states will not be nearly so large.  That block is quite complicated, but not outrageous.  There will be one potential choice where there will be the 7 independent visibility choices with selections of 6,6,6,3,3,3,2.  With vis-add-eng that will require 29 separate visibility states.  Without vis-add-eng it would require 11,664.  When I said more than 2,000 I was correct, but had not done the math...

Regardless, the method outlined in this thread is not in competition with vis-add-engine.  It is presented as potentially useful for some people.  If you do not find it so, then don't use it.

[Ron_M]

I didn't mean to imply a competition.  I've been playing with your method for a couple of hours right now and see a lot of potential with it.

[Libbya]

I'm glad you're finding it has potential uses.  If you, or anyone else, has the skills and inspiration to fix vis-add-eng, you'd definitely have my deep appreciation.  I haven't investigated it much with the later versions of cad, but although 'visibilit_add' does not work, I believe that some of the other commands still work.  I know that visibility-up does.  I have been wondering if it would be possible to make a 'template block' in an earlier version using V-A-E that housed something like 25 vis states, 50 stretches, 50 moves, 25 polar, 25 flips, etc... set all the grips to 0 and just use that file to start dynamic blocks in a later version.  At some point I will investigate that, andif it does work, then I will post up the 'template block'.

An appealing alternative to fixing vis-add-eng would be to make the grips of nested dynamic blocks accessible.  That would give all the functionality of vis-add-eng X 1,000. 

[Libbya]

This is the block I mentioned that I was working on.  The office standards where I work use a visual window schedule.  An example of a portion of a sheet is attached.  This block is to assist that process.  It obviously doesn't account for arched windows or some other more custom windows, but will accommodate 90+% of the window schedule.  The dimensions on the left are non-plotting and just for easy visual checking of the ead and sill heights if the 'dims' are turned off.  The nodes below the window are for accurate placement of the window tags.  For the window tags, I use the ACA 'intelligent' tags and so the information on window type and size is easily checked on the properties palette.  

The finished block has the 'triple picture' window type option that has 7 visibility grips (aside from typewith the number of options being 8,8,8,3,3,3,2.  Without vis-add-eng that would require 27,648 visibility states.  Not really worth the effort...  

With using vis-add-eng, the total number of visibility sets in this block is 18.  The total number of visibility states even using vis-add-eng is 95.

There are some other interesting methods used in this block.  The chained linear parameters allow the muntins to stretch properly and yet not stretch the window frame size.  Also extensive use of lookups allows the various visibility sets to be contextual.  In other words, it prevents the single picture window opening direction symbol from showing up on the double casement window, etc...

[Ron_M]

Very nicely done and covers a lot. I like that. The more you can do like this the less chance of a mistake being made. Again, very nice.

[Libbya]

Thanks.  It was a challenging and time consuming block to make but should pay back in spades with time saved in the long run and reducing erros.  I also find the puzzle of getting it all to work the way I want to be great fun.  

[vsrisaichaitanya]

HOW TO LINK TWO LOOP TABLE WITH SAME LOOKUP PROPERTY...

[Libbya]

On the right-click menu of the lookup parameter, select 'Properties'.   See the 'Lookup Parameter RC' jpg below to see what the lookup parameter right-click menu should look like.

When you have selected 'Properties' from the lookup parameter the tool properties window will pop up.  See the 'Lookup Properties' jpg below to see what the lookup properties window should look like.  

You can also see in the picture what it should look like when you click on Actions.  The three little 'browse' dots will appear at the right of the field (the cursor is on them in the jpg).  Click on those and it will take you to the Add Actions window.  See the 'Lookup ADD' jpg to see what the Add Actions window should look like.  

The cursor in the picture in on the Add button.  Click it and a second lookup action will appear on the action object list.  

Click OK and you will be back on the tool properties window where now the Actions field should say 'Lookup, Lookup'.  OK again and you will be back to the parameters tab of the authoring palette.  Select the lookup tool and place the lookup parameter in the block.  

You will need to have the system variable BACTIONBARMODE set to 0 instead of 1 in order to see the two lookup actions.  

Double-click on of them to open the table.

[vsrisaichaitanya]

THANK YOU ...THIS IS VERY HELPFUL...

[matthewpittman5777]

Any chance you can add more examples?  I am trying to create a dynamic Weld block and it am stuck.  I keep reading but it is not easy to understand the lookup part of this.

[Libbya]

The lookups function as follows.  A lookup is added for each faux visibility parameter.  Each lookup controls the position (either X or Y) of its input point parameter.  The 'Bridge' double lookup compares the relative positions of the input point parameters on one of its table in order to determine which state has been selected and the second table on the double lookup switches the visibility state to the appropriate one.  I'm not sure how to explain that more clearly.  Which part is not working for you?  

[jones]

How do you get your two lookup tables to show up with the BACTIONBARMODE=1

like in your Multiple visibility states block.

Mine works perfect and i see them with the BACTIONBARMODE=0 but would
be nice to see them also in mode=0

best regards

David