Origin of shapes imported from FGDB seems arbitrary

03-13-2013 04:09 AM
New Contributor II
Here's something I haven't yet been able to figure out. I'm importing simple building footprints from FGDB into an empty scene. Although I have no street network, I do know what direction each model should face (in other words, which side of the model should be the front).This I'm trying to model based on the shape's first edge. Trouble is that the placement of the origin (and therefore first edge) of each shape seems completely arbitrary.

I would have thought it had something to do with the order of vertices of the 2D shapes, but I can't work out any logic - see attached image, which is a composition of 4 shapes from ArcMap showing vertices. I manually painted in purple lines where CityEngine places the first edge.

This is a problem, since I don't want to set the first edge of each footprint manually (it's a lot of houses). Besides, "set first edge" doesn't always seem to persist if I regenerate a lot of models. Exports to FGDB and KML also show random behaviour with origin placement.

So my question is: how does CityEngine work out where to put the origin of a shape imported from FGDB? Can I solve this problem in another way than manually setting each first edge?

0 Kudos
4 Replies
Frequent Contributor II
Hi Eva.

The issue is that ArcGIS ALWAYS stores shapes in a clockwise manner. CityEngine interprets the normal of a face by interpreting the data counterclockwise.

This means that no matter if the user has drawn the shape initially in ArcGIS clockwise or counterclockwise, ArcGIS stores the data clockwise. Depending on this, you may get an offset in the edge index in CityEngine depending on this.

The best is to :
- make a test dataset for yourself similar to the attached image I did some time ago.
- adapt your dataset in ArcGIS so your data will turn out well in CityEngine.

Ok ?

0 Kudos
New Contributor II
Yes - this makes 95% sense. I've since worked out that based on the value of initialShape.origin.oy I can work out which direction the first edge is facing. This means I then know where the x and z-axes of the shape lie. When I add an attribute FRONT_ORIENTATION to my source data with the direction the front of the shape *should* be facing, I can work out how to initially split the building (along x or z) to create a front and a back part in the model.

attr FIRSTEDGE_ORIENT_Y = initialShape.origin.oy

else : ""

The 5% that isn't yet making sense: why is it initialShape.origin.oy providing me with this angle (and not ox or oz)? And why are ox and oz either 0 or -0?
0 Kudos
Frequent Contributor II
Hi ..

Just a note as a quick input ..

ArcGIS works in XY space with z being the height.

CityEngine stores all data yUp, X and Z being the 'ground plane'.

Check out the axis jack, which you can toggle with d,a
Check out the compass, which you can toggle with d,c
Check out the navigation display, which you can toggle with d,n
And most important :
Check the 'View Coordinate System', which you can set in the viewport display settings.

Note that the whole HUD ( Heads Up Display ) adapts to the VCS. Means that the navigation display displays the data depending on the VCS which you have set. 'CityEngine CS' displays all data the way it is stored, in cartesian coordinates. Note how the axis jack switches too !

When working with CGA, you always work in the cartesian system, so the direction of the first edge is along the initial scope.sx. Means you want to try to change your code to '*.ox'.

may help you too ! Check the docs on that one ..

Let me know if this changes your findings ! :o

0 Kudos
New Contributor II
OK, this is very useful!

I'll need to delve a little deeper into all this angle/coordinate stuff, obviously...

My scene uses a projected coordinate system so it's set to "Scene CS (meters)". In any case, *.ox is always 0 or -0, but*.oy can be used to calculate the orientation of the first edge. Geometry.angle(azimuth) can indeed also be used.

Anyway, even if it's not completely clear to me yet, I can at least solve my problem! Perhaps this stuff is quite obvious to 3D cracks but a newbie like me would be quite happy with more elaborate explanation in the Help file... ;)

Thanks again for taking the time!