# 'PolyCurves may be branching' caused by Geometry Scaling setting?

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:

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.

6 Likes

Thanks for your very clear explanation @JacobSmall

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?

This is my Bounding Box:

Nothing at the origin.

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

1 Like

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.

1 Like

@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.

1 Like

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:

So this seems choosing between two evils then?

@John.DeLeeuw we need to cope with the warning for the time being.