algorithmic modeling for Rhino
This little script works fine in Rhino 5 from Grasshopper Python, to create a linear dimension, but it fails in Rhino 6 WIP which creates an invisible dimension that an be selected with Select All but has exactly zero size and cannot be zoomed in to with Zoom Selected. I can copy and paste the dimension created in Rhino 5 just fine into Rhino 6 WIP, or copy and paste the invisible dimension over to Rhino 5 and it's still not visible.
dimension = Rhino.Geometry.LinearDimension.FromPoints(StartPoint, EndPoint, OffsetPoint)
This is a drag since Grasshopper style dimensions can't be baked and the various Grasshopper plugins for dimensions spit out error messages in Rhino 6 WIP. For now I've just stopped using Rhino 6 WIP for a big project.
Is an annotation default not triggering, I wonder? I can do without a Grasshopper preview and in fact like to avoid plugins at all costs in favor of Python so I can much more easily offer a Grasshopper script to a client but Grasshopper and then Python themselves are plugins for Rhino 5, whereas they are included in Rhino 6 WIP.
I don't want to rely on Rhinoscript either.
Ah, the math is off. In Rhino 5 the properties show a valid second point, whereas above from Rhino 6 WIP the second point is at such tiny offset from the start point that the dimension collapses to zero and thus doesn't show up. Or are they in fact gigantic? The magnitudes are e+308. Is that to the power of ten to the 308?!
There seems to be a lack of model/layout scaling for dimensions in Rhino 5 that exists in Rhino 6 WIP, so this becomes much more urgent. I mean, it's sort of there in Rhino 5 but only affects text, not actually dimensions, when I switch to a layout the dimension text is tiny, or if I make it big enough to show up on a layout, it is too small to see in the normal model view.
So even in Rhino 5 there is a caveat that two point dimensions only come out horizontal and I tried to modify the .Plane property of it before creating it, but that gave odd result.
So I switched, in Rhino 5, to the deeper LinearDimension command with a 45 degree rotated plane, and it ALSO LOCKS TO THE HORIZONTAL DIMENSION first, and then only rotates that. Well so much for a useful command!
Even in Rhino 5 with Rhinocommon scripting, dimensions DO NOT ACT LIKE YOU WANT. They seem to first (in undocumented fashion) only create an initial HORIZONTAL dimension then merely rotate it if you alter it's defining plane, but that's complex math to ever again get the extended dimension line ends back where they belong. It's as if you are required to move your geometry into horizontal position to get a measurement and then rotate the dimension back to the original rotation.
This may explain why Grasshopper's dimensions are divorced completely from Rhino ones. You can't even bake them and obtain Rhino dimensions for a layout. Architects cannot be amused by this!
Even defining a plane and then using two points that form a 45 degree angle in the Rhino XY World Plane FAILS to create the right distance, the linear distance, instead of horizontal distance, between the points!
The problem in general is industry wide. APIs and SDKs fail to provide enough examples with graphics. So nobody knows what buttons to push. This is dirt simple. A dimension form point A to B. But the reference guide says NOTHING about actual command structure, from a pushing buttons on a keyboard perspective, and certainly nothing at all about workflow.
HOW DO I USE PYTHON TO MAKE A LINEAR DIMENSION BETWEEN TWO POINTS THAT ARE NOT HORIZONTALLY ALIGNED?
Is it even possible to make a vertical dimension that spans two points spaced out vertically?
WHEN I TRY, I GET A ZERO WIDTH DIMENSION THAT IS HORIZONTAL.
calm down dude.
Grasshopper dimensions DO bake to rhino dimensions in rhino 5. You are correct that this appears to be broken in the WIP due to some changes in RhinoCommon - the constructor that the component uses (the same one you are using I suspect) is deprecated.
In the WIP, you can create an aligned dimension between two points like so:
from Rhino.Geometry import *
RhinoDocument = Rhino.RhinoDoc.ActiveDoc
dimPlane = Plane(Point3d.Origin, end-start,Vector3d.CrossProduct(end-start,Vector3d.ZAxis))
dim = LinearDimension.Create(AnnotationType.Aligned,RhinoDocument.DimStyles,dimPlane, end-start, start, end, dimPt,0)
dim = createDim(x,y,z)
Life saver, thanks immensely.
My 4 line version of your 14 lines expands the naming shortcuts:
Indeed this is only good in Rhino 6 WIP. I wonder if a Rhino 5 version is a simple edit? I could check for the version in Python.
It would be nice if you could drop your code into the WIP Rhinocommon reference:
The Rhino 6 WIP Rhinocommon SDK reference page I was using failed to link to the Methods for LinearDimension which included the .Create command:
Yet it can be found right here in seemingly the RhinoCommonWin instead of RhinoCommon version of the reference:
The McNeel web site lacks the WIP version for its API options, regrettably:
It would be nice if the old WIP API version forwarded to the real one, too.
What is so confusing is that every single reference line requires massive decrypting. For instance the dimension style has a single line reference:
"StyleID as GUID"
What that REALLY means is this:
So how on Earth am I supposed to figure out that styleId requires me to then look up the command DimStyles which is hiding in Rhino.DocObjects.Tables?
Why not just reference the needed command?! Reference it directly:
"DimStyles as Guid"
Done, no more guessing. Where else am I going to get that Guid except from the actual Rhino command that grabs it?
If you are going to insist on a layer of abstraction that requires complete Rhinocommon jungle guide knowledge, then working examples are dearly missing that makes it usable in a work environment where you are promising to get stuff done.
If I search for the referenced "styleId," the needed DimStyles command does not even come up! So if I'm not myself a hard core insider McNeel developer, I cannot possibly work out this command myself without vast amounts of trial and error searching for days through the Rhinocommon reference, desperately searching Google, etc.
What would be useful is a flow chart of how object oriented properties attach to objects, with any branching shown too if there's multiple ways to skin each cat. Lacking that, it's mud and guts in war torn territory, working in a sausage factory with dull knives under harsh Soviet fluorescent lights that flicker with the wind, loudly at times. Then you are mugging people and shoplifting to build yourself up again to drug dealer status by making your first new buy, after being rendered homeless since McNeel didn't comment their code.