So I got the ‘PolyCurves may be branching’ error and searched for possible solutions in this forum. Appearantly this was caused by converging PolyCurves in a Y-like manner but I also found out that Geometry Scaling is directly effecting this?
There is no problem with the ‘Large’ setting:
Same script, an error with the ‘Extra Large’ setting:
Any ideas/conclusions about this?
This is caused by the geometry disposing of values after the decimal place in extra large settings. Therefore points which previously had X values of [0.1, 0.2, 0.3, 5, 10] now have values of [0, 0, 0, 5, 10]
The solution is to always manage your work so you’re within 100,000,000 units of precision. You can shift stuff whichever way you need/want to go, but from 1 to 100,000,000 is all the digits you get to work with.
If you’re using feet then:
Extra large will work for stuff as large as 3/4 of the way around the earth, but will ignore anything smaller then a large subway sandwich.
Large will work with stuff as big as 3 times as long as the English Channel, but will ignore anything smaller then a 1/2 carat diamond.
Medium works with stuff about as long as the Washington Mall in DC, but will ignore anything smaller then 4 red blood cells lined up.
Small works with stuff a bit longer then a basketball court, but will ignore anything smaller then 1/5 of a mitochondrion.
The values are similar for meters, but everything gets 3.28 times larger (so a whole two mitochondria at small scale).
As you can likely guess from the scale objects I presented, there is really no reason to be using Extra Large with feet or meters. If you’re measuring in inches or millimeters then maybe, but at building scale you have no need to keep more then a couple decimal places as you quickly wind up measuring fractions of an atom.
Thanks for your very clear explanation @jacob.small
The reason why I set the geometry scaling to Extra Large is because the 3D navigation is way better then only Large. This typical ‘large coordinates’ problem is bugging many applications.
Is Dynamo an 8 or 16bit application? The AutoCAD core runs on 16bit I believe. Revit on 8bit.
I believe is 32 and 64 respectively, but I may be wrong. @Michael_Kirschner2 would know better.
What are your project units, and where is the origin relative to your work?
I’m working in a Dutch Projected CS called RD Netherlands, in meters. The location of my project data is around 120000 meters in X and 480000 meters in Y.
The current units precision of AutoCAD is 16 decimals (64-bit double precision) and appearantly Revit also does. Still navigation in Dynamo is crap while Geometry Scaling is set to Large and becomes much better when set to Extra Large.
Something is outside of the limits of large geometry. Might have to share the files for it to be identified. Perhaps pull the bounding box of all geometry and check the extents?
The above example is different from my first post but the navigation troubles are the same. It especially happens when panning, then the geometry flies of to who know where?
@John.DeLeeuw I haven’t seen this behavior, or perhaps I am not understanding it. Can you do a quick screencast recording illustrating the behavior?
@Michael_Kirschner2 does this ring any bells for you?
Here a 1st screencast showing what I mean
Here a 2nd with geometry scaling setting to extra large showing the panning improvement
Woah. I haven’t seen this behavior previously. Wondering if the preview geometry is calculating the full length of an arc here.
FYI @solamour and @Michael_Kirschner2.
@John.DeLeeuw The default geometry scaling in Dynamo for Civil 3D is on Medium for a reason, when extracting feature lines from corridors you can get the wrong representation if you have it set on Large or Extra Large. It is one of the well known issues in CivilConnection as well since the Geometry Scaling was introduced.
There is also a reason why people set the geometry scaling on large 
I agree with @John.DeLeeuw that navigating with this setting is not pretty. You say it is a well known issue, will it be solved one day?
I’ve seen tips that users should correct large coordinates to the wcs origin and after the process correct them back, but that is not a real solution.
This works for Revit workflows and for operating on the data (e.g. debugging) it will not work for Civil 3D.
The panning is annoying but is not the biggest issue IMHO: the definition of the PolyCurves is affected.
I don’t hold the information for the resolution of this bug LINK
@Paolo_Emilio_Serra1, this is what Dynamo is telling me to do when I select an object in my Civil 3D CS:
I appreciate the explanations in this thread, but it seems to be a denial of the fact that in Civil3D we work with real world coordinates.
The actual area covered on a project will be ‘medium’, but the script won’t run unless it’s set to Extra Large … and then you get these branching errors, or other apparent glitches where a continuous polycurve is treated as if it has gaps.
We have from 0 to 100,000,000 to play with … but these errors still happen with typical UTM coordinates with eastings around 500,000 and northings around 5,500,000.
We shouldn’t have to shift anything. Dynamo Devs know the limitations of their systems. They should have a mechanism in place where Dynamo recognizes (or is provided with) the bounding box area of a task - which will dictate the scaling needed, and silently shifts the numbers if they can’t be digested, runs the process, and shifts them back to present the results.
I don’t understand this quote - when dynamo encounters a large number it raises a warning suggesting that you change the scaling factor, it does not stop the run or return null - I think the warning perhaps should be more informative and less instructive though, as you point out the solution in some cases is not to follow its advise.
Assuming you are measuring in feet, extra large coordinates will get you 3/4 of the way around the world but will round things off to the size of a subway sandwich, while and Large will get you across the English Channel But will round stuff to the size of a 1/2 carrot diamond.
If your both bigger than the English Channel and smaller than a sandwich then you have to get creative. Shift your relevant geometry to the origin prior to working with it, and shift it back afterwards. The data will be correct but you may see display issues in Dynamo.
Serious question that may sound sarcastic but isn’t: how do you account for the curvature of the earth distorting your dimensions on projects which are both ‘smaller than a sandwich and bigger than the English Channel’?
We didn’t make the coordinate systems we are required to work in. Can’t help that we have coordinates in the 500,000 - 1,000,000 range.
The Large range has been working well in most cases for me. I’ll be the first to admit that I’m becoming increasingly confused on this issue since we get varying recommendations on geometry scaling from different Autodesk representatives. Also, why include a geometry range setting in the software if you’re not supposed to use anything but medium?
