Setup Height Leaders Through Dimensions


I’m figuring out workflows for extracting height leaders from sketchup drawings. I just need the height value from a vertex but that’s impossible to get automatically from auto text leaders.

So I was thinking on adapting my standard workflow to a dimension leader that would graphically emulate what I do.

I couldn’t but I’ll show my results in the hope you might adapt them:

  • I usually establish a set of dimensions that go from level 0 into the several levels of my projects
  • Then I place 2 elements in each level, at the right spot in the drawing, a triangle pointing down and a text (I used to group them but editing the text was harder)
  • I then manually change text for every one of this sets so I create my standard height leaders.
  • I use the dimensions values for heights

(I used to do this workflow in cad too, but cad isn’t 3D but a CAD elevation isn’t aware of it’s space coordinates… a sketchup model is so something should adress this issue properly.)

You can understand this process better with the image below:

As my projects grow in complexity I get tired of this, my mind and body aren’t being creative, they’re just diving into mindless repetition of actions… I remember my CAD days without the advantages of fast drafting.

So I was trying to figure out other ways of doing it, and I thought of simply using dimensions to take a lot of the process out of the loop, and I created a dimension style. Take a look at the gif:

Unfortunatelly I couldn’t match my own style, so I’m considering alternative optionsm but it can still be of use to someone.

My request is:

  • To be able to have more styles on arrows so I can acomplish this;
  • Or allow an option for dimensions to have the arrows pointing from the outside to the inside, on small and big dimensions.
  • Allow for the text to be auto placed outside/inside of the end or start arrow. (this would also help with standard dimensioning as I often do this on the end dims of chained dimensions.)
1 Like

I wonder what kind of nonsense these dimensions will create on my CAD exports…

I agree that some kind of automation of elevations labeling is really desirable feature in LO. I also think it may take not that much effort to code a separate dimension tool just for elevation marks (this is just an assumption though). The logic of a new tool may be based on an existing linear dimension tool (I think your animation clearly shows it). In contrast to a linear dimensions dimensioning of elevation marks tool should be limited to vertical dimensions only (I think). And there should be an ability to use some symbols of elevation marks and elevation sign prefix obviously.
However it is also possible just to extend functionality of an existing linear dimensions tool as you suggested above. I guess resulted level label object will be exploded down to Mtext and line primitives during export to DXF/DWG.

Great idea jql. In cad I used ordinate dimensions for levels in elevations. Initially, they were used for coordinate notation, but as long as my ucs was properly placed, they worked just fine for elevations. Maybe something similar in layout?

Ordinate dims

I’d rather see it as a block with geometry text or as what Caronte Suggests on ordinate dimensions.

I also agree that the best aproach would be to have an Ordinate dimensions alike feature. What I was showing here is the process I currently use to establish my own datum and ordinate dimension system, which is obviously flawed and I also agree with you Kirill that it seems easy to adapt from existing dimensions (I’m of course having the same assumption)

Side note: Are you guys seeing a cake next to my avatar? What does that mean?

happy birthday?



Nope, it’s not my birthday. Maybe this is the date I joined this forum…

The point is that ordinate dimensions in cad (as @caronte01 mentioned) are strictly linked to UCS logic. I’m not sure it is really necessary to introduce something similar to UCS in LO (it will require far more effort during implementation obviously and the logic itself may look less obvious to some end-users). I mean current LO interface is so simple and easy to use/learn so is it really necessary to introduce some deeper level of abstraction like UCS etc?
As for me I like the initial idea of linear tool enhancement and/or new tool creation.

Well, I wasn’t aware of how that ordinate system worked. It just seemed that seting up dimensions that would use some kind of Sketchup model 3D datum, would be a clever aproach that would derive directly from the 3D model.

We are now able to retrieve point information from a Sketchup model already. This model information is a XYZ coordinate system.

Z coordinates are therefore already retrievable from the model even if, right now, they can’t be isolated automatically from X and Y.

I’ve also asked for this feature before, when the Auto text label feature was implemented. I don’t think that it was in this forum though…

Isolating X, or Y or Z would serve us well for many things, but in architecture Z info is key.

The current topic is about a height tool for elevations, but if Z coordinates of a point would be retriavable and related to a datum that is valid per model, then elevation tags could be created for elevations and also plans.

I also have FRs somewhere about pavement/roof gradient tags, about area tags and Layout+Sketchup teams should pair up and find ways of implementing all kind of standard architectural tags that can be directly retrieved from a Sketchup model.

I find these kind of Feature requests are easilly lost in these forums, but this kind of discussion is key for implementing a simple yet robust architectural system of accuratelly representing standard info from a model that already has it all in it’s geometry.

What really annoys me is that Layout is always almost there but these simple finishes are never done, release after release.

This time they nailed it with Dimensions and dwg exports, I hope next time they will fill all these gaps.


It’s not like we are asking for a full parametric BIM functionallity. That is over the top and Sketchup already has a wonderful unparametric modelling workflow and a classifier tool that complies with BIM classifications.

We just need to fine tune things that are already there, so we have a killer architectural app.

Sketchup is already great, but it could be unbeatable for many of us with such simple things.

I see the cake next to your avatar. It’s your forum joining anniversary.

If set as ordinate like dimensions, maybe there could be 2 ways to use them, relative or absolute.

Absolute, would be based on the location of the world axes. Most of my models are placed so z 0 corresponds to my 0 level in model, so it would not be a problem

A while ago, I did work on a large project that had it’s levels referenced to actual world elevation. The entire model was georeferenced in x y and z. It was not intutive to refer to a particular level in a building as level 1,835, but, it was too late to change. In this particular case, given sketchup’s limitation when modelling too far away from the origin, maybe one could set an additional axis, geolocated to world 0,0,0, and save them to a scene, and then, when dimensioning, reference all dims to that particular axis/scene. Since axes can be changed/moved, either dimensions are updated based on new axis location, or maybe, highlighted red when they are moved.

Sketchup already has a ucs system, so a ordinate like tool would only leverage sketchup’s axis

One concern with this, would be what would happen if layout looses the connection between the model and the dimensions. Similar to the problems with auto scale dimensions (I never use them, they are too unreliable). What if for example, the level references layout’s linework, instead of geometry inside a viewport?

Also, I agree with JQL, coordinate info, and particularly, z elevation is super useful and necessary for dimensioning, not only in architecture. Spot elevations in plan would be very welcome.

Yes but I was talking about LayOut (not SketchUp). Maybe I’m wrong but seems like LO doesn’t have any UCS logic. And as for me personally I think it’s totally OK not to add any kind of UCS logic to LO in order to keep things simple and intuitive.

That’s exactly what I was talking about. And proposed solution addresses exactly this situation. The idea is that level mark dimension is just a clone of an existing linear dimension, but in contrast to linear dimension it has its own formatting of measured results representation and its own text placing rules. The only limitation of such approach is that zero level (0.000) should be within visible boundaries of LO document in order to click at it during elevation mark creation. My reasons was that it will require not much effort to implement such tool and tool processing will be intuitively clear (no need to introduce any new abstractions like UCS in LO).

I also agree with @JQL about all ideas about retrieving of Z coordinate from SU model. Hope this feature will appear someday.
I think there can be a rather simple way to avoid origins, ucs etc in case if there will be ability to perform basic math operations with auto-text content.
[EDITED] Some irrelevant commenting was erased.