MACROS for object dimensions, area, volume

[banelinde]

Hi there,

 

I'm looking for three separate basic macros for any object (here polyline solid) for dimensions WxHxL , area and volume.

Was trying to figure out variables in Text Macro Management,  but without success.

 

Have found OBJECT.PROPERTIES from Joe Carrick , but that is to much info for my application.

 

Can somebody assist with the super basic variables.

Looking for something like %width.object% , %area.obj% or %volume.obj.round(2)%   (syntax is wrong, but just for an idea)

 

Regards.

 

 

 

[Joe_Carrick]

Polyline Solids (3d Solids) do not have a width NVP.

 

For area and volume just put these in the object label

• %area%
• %volume%

I believe they will be rounded to 2 decimal places in X15 automatically.

[Renerabbitt]

2 hours ago, banelinde said:

I'm looking for three separate basic macros for any object (here polyline solid) for dimensions WxHxL , area and volume.

depending on your reason for this, maybe converting the solid to a symbol is your best solution

[Joe_Carrick]

3 hours ago, Renerabbitt said:

depending on your reason for this, maybe converting the solid to a symbol is your best solution

yes of course.  then you could use:

• %width%
• %depth%
• %height%

[banelinde]

Rene & Joe, many thanks.

 

Some variables DO NOT work on my crated symbol.

 

 

On a primitive like 3D box, labels aren't possible at all, unless I create a symbol.

But as above, some variables on a symbol do not work.

 

 

On a polyline solid, variables work in opposite as for symbol and I can not have other polyline solid shapes,

from which I can have labels with all mentioned variables.

 

 

Overview

 

Regards.

 

[Chopsaw]

34 minutes ago, banelinde said:

 

Some variables DO NOT work on my crated symbol.

 

It looks to me that what you are building would most suitably be a symbol so just do the math....

 

 

 

[banelinde]

@Chopsaw, bravo&thanks.

 

I already tried that, but the syntax was off (which is clear for Ruby connoisseurs).

 

Correct= %width*depth*height%

Incorrect=%width%*%depth%*%height%

 

Have you a solution for the reverse?

Volume=>X Y Z   (eg%volume%/x/y/z)

Area=> X Y

 

Then I can have desired parameters for both, symbol and polyline solid, whichever I use.

Regards.

 

[Chopsaw]

36 minutes ago, banelinde said:

Have you a solution for the reverse?

Volume=>X Y Z   (eg%volume%/x/y/z)

Area=> X Y

 

Then I can have desired parameters for both, symbol and polyline solid, whichever I use.

Regards.

 

Yikes !  Now there is a challenge.  Unfortunately I am not a mathematician but I think that would only work if you had a perfect cube and you took the cube root of the Volume and that would give you the width x depth x height.

Same with the Area.  Take the square root of the Area to get the width x  depth, but only for a perfect square or it is magic not math.

 

I would suggest that you use a general framing member and stick with the same methodology as the symbol, since your example is not a perfect cube.

[Renerabbitt]

8 hours ago, Chopsaw said:

perfect

I bet you could guess that I would say this…

use a cabinet

[Renerabbitt]

9 hours ago, Chopsaw said:

perfect cube

I take it back...

 

10 hours ago, banelinde said:

desired parameters for both, symbol and polyline solid

I think a room would serve you well for these conditions..really simple to create, simple to manipulate, especially in 3d..dynamic, can have outlets(windows) can have moldings, hatches(doors) and they can automatically report the values you are looking for to a room schedule without scripting.

[banelinde]

Chopsaw, no, there isn't perfect cube.

I meant to pool data with Ruby variable out of the object, where area or volume is known.

 

Renerabbit, no, using a room as a object would messup everything.

 

Thank you both.

 

[Chopsaw]

26 minutes ago, banelinde said:

Chopsaw, no, there isn't perfect cube.

I meant to pool data with Ruby variable out of the object, where area or volume is known.

 

Yes I don't think that is possible.  You mentioned using Joe's Object Properties macro.  That shows you what is available for each object you apply it to.

 

So for the "General Framing Member" you are working with width, length and depth rather than width, depth and height for the symbol.  We are limited to what is available and if you are dealing with any significant quantity of these items you will want to use the simplest item that serves your purpose.

 

[banelinde]

Many thanks.

[Joe_Carrick]

Personally, I would use a SLAB because it has both area & volume and it also has a Label.

You can change the thickness and modify the shape any way you want and the label will automatically update.

[Chopsaw]

4 hours ago, Joe_Carrick said:

Personally, I would use a SLAB because it has both area & volume and it also has a Label.

You can change the thickness and modify the shape any way you want and the label will automatically update.

 

Do you have a secret you are not sharing Joe ?   If you really need to you can get the height if you have the area and volume, but how do you propose getting the rest of the dimensions assuming they are not the same ?  The OP needs area, volume and three dimensions.

[Joe_Carrick]

1 hour ago, Chopsaw said:

 

Do you have a secret you are not sharing Joe ?   If you really need to you can get the height if you have the area and volume, but how do you propose getting the rest of the dimensions assuming they are not the same ?  The OP needs area, volume and three dimensions.

Well, %thickness% works for the vertical.

For Plan Dimensions I would just use manual dimensions either with or without dimension lines, extensions & arrows.

[Chopsaw]

5 minutes ago, Joe_Carrick said:

For Plan Dimensions I would just use manual dimensions either with or without dimension lines, extensions & arrows.

 

Ok I get it, but that is the same logic that presumably CA programmers used in thinking we would not need base NVP's, which leaves a lack of flexibility when you want that information displayed in the label. 

[Joe_Carrick]

1 hour ago, Chopsaw said:

 

Ok I get it, but that is the same logic that presumably CA programmers used in thinking we would not need base NVP's, which leaves a lack of flexibility when you want that information displayed in the label. 

It really depends on the object.  An irregular polygon can't be assumed to have a width or length.  So in that case their logic makes sense.  There are a lot of objects in Chief that don't have certain NVPs due to their nature.  That doesn't mean the programmers don't make logic mistakes - but in most cases I would agree with them.