Text variables in layouts

blocks
usertext
unhandled
layouts

#1

When I make the layouts for a technical drawing I insert a block in every page which contains the frame and text field. Rhino offers some variables for basic information like page name, page number, date. There are new options like DocumentText which are very helpful and long overdue.
But it’s still not enough.
There is also some information which is not dependent on the document (let’s say “globally”) but rather dependent on a certain object.
In specific I mean characteristics like:

  • material
  • thickness of a sheet material
  • finish/surface (like anodized or powder coated for example)
  • scale of a specific detail view in the layout page (because the scale may change from page to page of course)

This is all information that may change from page to page. In the end I find myself exploding the blocks in order to fill in the necessary information manually.
Maybe I missed something and this is possible? I hope so.
If not, I have to say, that this is on of those many ways where rhino falls short compared to other CAD software. Does so many things but so many of those are not done right or are just implemented half way.

Wish:
There should be an option like MakeLayoutFromObject. So the created layout page is somehow referenced to that object and variables in the title block could pull info from it. That’s the way SolidWorks does it. Of course it’s different there, because there is essentially just one object/part in the file, so it’s probably easier to automate a drawing from that.

I hope other users feel the need for this too.

I also hope it’s easy to implement. Since we are talking about automating a workflow here, maybe some new Grasshopper components could do the trick, maybe even more GH and layouts in general?


#2

Definitely. And I have been meaning to get back to this thread:

First off: things like material, sheet thickness, surface finish, … can be easily set to an object using the new GUI for GetDocumentUserText & GetUserText for inclusion in text strings:

A text field for detail scale is on the wish list (RH-31361 and RH-12602).

I am a bit concerned with putting these things into a block. Blocks in Rhino are strictly for identical things. If you want one text string to point at one object and another text string at another object, these are no longer identical objects. Also, since the size (in bytes) of a “Title Block” is rather limited, I’m personally not afraid of just copying a “template layout” when I need a new layout in my file - and not use blocks at all. But I do see that it would make sense to somehow automate certain parts of it.

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.

[All this also reminded me of how clumsy the interface is for picking an object for text fields. I thought that Rhino had crashed as the the interface only replied with the default Windows ‘ping’ error sound but after a while I found that a dialog box was hiding behind the rest of the interface - Existing PaperCut report - RH-39133 ]


#3

thanks for your elaborate answer.

well, the variable is always the same, right? but yes, it points to different objects. but it works. or maybe not really and that was the problem why I had rhino wip crashing all the time when dealing with this, last week.
I’d be happy to use other solutions than blocks - it just has to serve the purpose. At the moment only with blocks I get the possibility to make changes (to other objects than the variables) later and have everything updated, right?
Groups are easy to c&p but they don’t update.

thanks, I’ll try that later today.

YES PLEASE!

you’re also totally right regarding text strings.

@DavidRutten, wouldn’t grasshopper be a good tool for that? new components regarding layouts?


#4

That’s correct, yes. But around here, changes to the T/B are extremely rare and as such it doesn’t really worry me. I do see the point, though, and I suppose that ideally, the T/B is an object type on its own that can be edited - and updated - in some sort of an editor. I agree that Grasshopper would be a likely candidate…


#6

I’m pretty disappointed. We are helping by testing the WIP and take our time to write about bugs, shortcomings and make suggestions. Some kind of feedback from the developers would be much appreciated. Even if you don’t plan on making progress in this direction - a short answer would be good.


(Brian Gillespie) #7

@hitenter, I’ve read through this thread a couple times now, and I’m really having a hard time understanding what you’re asking for. It sounds like you want to be able to associate the block that contains fields with an object or objects in the layout?

Are you imagining something like:

  1. A title block could have text fields that reference a yet-to-be-defined object. Something like:
    %< obj1.material >%
    %< obj1.finish >%
    %< obj1.thickness >%

  2. When you insert your title block with these fields, you’d be prompted to select a real object that would be “obj1”

  3. Rhino would see if there are any user strings with the names “material”, “finish”, or “thickness” on the object you selected, and use those to fill in the field.

Is that what you’re asking for? I imagine you’d want to be able to reference multiple objects about 12 seconds after we made it work for one object.

This isn’t something that we’re going to do for Rhino 6.


#8

first, thanks for getting back to this.

yes, what you describe sounds like a rhino-ish way to reference certain attributes(like material etc) to an object/part.
that way the attributes could be used in title blocks or a part list.
btw a part list is something pretty standard in industrial design - but it seems rhino has never heard of such a thing. i’d be happy if you’d tell me i’m wrong.

i don’t understand what you mean with the 12second sentence?

i think it’s a bit odd you don’t consider something that is so basic and important for drawings and manufacturing for rhino since it is meant to be a tool for industrial/designers.
this is just one of the many reasons some consider rhino more as a conceptional tool in an early design phase but use other programs like solidworks when it comes to actual manufacturing.


#9

For a part list, yes. It wouldn’t take me 12 seconds though… :grin:
Thanks for taking notes!


(Brian Gillespie) #10

I meant that if we were to make your wish work as you requested (making a drawing for a single object in a single title block) then immediately after the wish was granted, you’d want it to work for two objects - or maybe even three :slight_smile:

We have spent most of our development effort making Rhino do things that other products can’t do - that’s probably why you use Rhino at all!

It’s not that we don’t consider drawing production to be unimportant - it’s that we don’t consider it a problem that isn’t already solved elsewhere. And it’s something that we’re aware needs improvement in Rhino. It’s becoming more apparent that people don’t want to leave Rhino to do production drawings, shop drawings, or construction documentation.

I logged your feature request at RH-40750.


#11

People have wanted this in Rhino for years. It’s great that you can finally start considering full-featuring it!

I think there’s a small conceptual disconnect here between the users and the developers, even though they agree strongly on your point. The disconnect is that users think that when you develop all these great new things you should be starting with the things that all other products can do.


(Bob McNeel) #12

Yes, but if would have done that we won’t still be in business. We would have never gotten the things that aren’t available in other products. Hence, no reason to buy early versions of Rhino.