Title Block with Text Fields

Continuing the discussion from several other threads…

I hope to get a constructive, but specific, discussion going about where we are with regards to automating Title Blocks. What is possible? What is not? Are there workarounds? Bugs? Current platform is Rhino 6 for Windows.

I don’t do much detailing in Rhino (for one, that would require instant Make2D with hatching, etc - but that is a different story). Also, I work in heavy industry and I’m sure requirements for other sectors will differ. Therefore, I’m counting on those who do make layouts to contribute to the discussion by providing clear examples with 3dm files.

First off - it’s called a “TITLE BLOCK” [T/B] but, to me, that’s as close as it comes to what’s a block in Rhino. I don’t use blocks in Rhino and, in the specific case of T/B’s, the use of blocks limits what is possible to automate (or at least, makes it a bit more convoluted). In my world, having worked for the same company for 13+ years now, it is extremely rare that changes are made to the layout of the T/B. As such, I don’t see why it is important to be able to change one and have all the others update. Also, the combined “weight” of all T/B geometry in one file is negligible when it comes to size on disk and performance in the Rhino viewport. So, for me, no reason to use a block here.

In my template file, I have a (few) layout(s) with T/B, paper size, and detail(s) that I keep blank. When I need a layout, I will make a copy of this blank layout and make changes as required.

I see, however, that others insist on having the T/B as a block and, to humor them (and to show how that is limiting), I have turned the T/B in the following file into a block.

Secondly, this discussion is NOT about “PART LISTS”. While that might be possible to achieve by using GH, a productive way of producing these with just Rhino is not something for RH6 - as confirmed by Brian here:

Back to T/Bs:
DRW-8087693.3dm (462.2 KB)

image

The text in green is populated automatically by using Text Fields that link to either factory-default properties or custom Document User Text. Some of it will differ between sheets, other is identical across sheets. None of it is to be edited by interfacing the T/B itself but rather through editing user text and layout names.

Issues
By using the technique of keeping one layout as a template to be copied, the total amount of sheets that are used is not what you would want to appear in the SHEET x OF y space. I have to move that template sheet to the back and manually update the total sheets number.
This one is logged as RH-42968.

When that is solved as @stevebaer proposed, then also WEIGHT should be possible to automate. That would require some of the functionality that is needed for Part Lists as well though.

SCALE. This one is on the wish list as RH-12602 and RH-31361. I can see a complication where several details on a sheet have different scales and the T/B should only reference the “main” detail.

SIZE. I couldn’t find a YT issue for this one so I added a new one: RH-44703

OBJECT TEXT
Rhino blocks require identical objects. Turning the T/B into a block makes it so that when you embed a text field that points to a specifc object, that same specific object is referenced across all layouts - updating this in one T/B updates it all over. Instead of using long names for the layouts, it makes more sense to use text fields that reference specific objects and extract e.g. name and material. This cannot be part of a block, but for reasons I described above, I don’t see that as a problem.

BUGS
When you have a text field with long text (example included on the first sheet in the file that was posted), wrapping the text by moving the point will make Rhino show the text field “formula” instead of the resulting text. This one was logged as RH-43510 and RH-44247.

It should also be possible to pre-define the space where a text field is allowed to live, and make it wrap automatically.

USABILITY ISSUE
It is rather akward to edit a text that has text fields. Just repeating from this post:
Something I find lacking is a meaningful way to edit a text string with a text field in it.


Perhaps everthing between the %–% could be a Text Field button with easy access to (i) identify the object, (ii) change the object, (iii) change the property.

So, what else is missing?
@arquitextonica, @milezee


For the sake of completeness, some previous threads:
https://discourse.mcneel.com/t/rhinoceros-replacing-autocad/
https://discourse.mcneel.com/t/title-block-attributes/
https://discourse.mcneel.com/t/custom-text-fields-in-title-blocks/
https://discourse.mcneel.com/t/v6-wish-attributes-or-custom-data-field/

4 Likes

Hey Wim, I’ve had this one sitting in my inbox for a while because it is both a great write-up and covers a lot of advancements I would like to eventually see in text fields. Thanks for being so thorough and identifying/creating associated youtrack issues.

@Trav and @brian, I’m just mentioning you here to let you know about this post.

Text fields definitely leave a lot of room for improvement and have a ton of potential if we can figure out a good way to expand on what can be evaluated in a field and turned into text.

4 Likes

not a useful comment here, just thanks for laying all this out in one post, very useful resource! looking forward to seeing the issues fixed and updates.

I’m relatively new to Rhino 6, and seeing functionality such as this would be an enormous advantage. Even if that is simply to assist users in being productive rather than spending time on basic (and somewhat repetitive) document housekeeping and consistency. Thank you for spending the time to detail this, Wim.

1 Like

RH-44703 is fixed in the latest WIP