topic Re: Rule inline - geometry merge in ArcGIS CityEngine Questions

Rule inline - geometry merge

SteveFox — Mon, 22 Sep 2025 00:24:48 GMT

I've gone through the instructions on this page (https://doc.arcgis.com/en/cityengine/latest/cga/cga-inline-operation.htm) and replicated the FShape pieces (right image). However it appears that when the resulting split shapes aren't equal when modifying the split values, the cleanup geometry doesn't unify the shape (left image)? I'm having the same issue when using inline and cleanup geometry to unify other sub shapes.

Thanks

Re: Rule inline - geometry merge

JonasObertuefer — Tue, 23 Sep 2025 10:38:28 GMT

Hi @SteveFox,

Thanks for your question. For this example make sure the distances matches in both splits otherwise cleanupGeometry does not work.

Hope this helps!

Best,
Jonas

Re: Rule inline - geometry merge

SteveFox — Tue, 30 Sep 2025 01:24:33 GMT

Thanks Jonas, will cleanup geometry still work with splits calling up attribute/s (as it's the same attribute it will be matching in both splits) - it doesn't appear to.

Re: Rule inline - geometry merge

JonasObertuefer — Tue, 30 Sep 2025 06:30:34 GMT

Hi, not sure if I can follow. Do mean that if you replace the numbers marked in yellow with an attribute it does not work anymore for you? Can you share an example snippet?

Re: Rule inline - geometry merge

JonasObertuefer — Mon, 06 Oct 2025 07:48:29 GMT

Also the upcoming 2025.1 release of CityEngine will introduce the modify/inline(recompose) operation, which heavily simplifies this example:

Init --> inline(recompose) FShapePieces cleanupGeometry(edges, 0) House FShapePieces --> split(z, noAdjust) { Width: Done. | ~1: split(x) { ~Gap_Width: NIL | Width: Done. }* }

You can already test the above code when running the 2025.1 beta by joining the early adopter program.

Cheers
Jonas

Re: Rule inline - geometry merge

SteveFox — Thu, 09 Oct 2025 05:57:32 GMT

Thanks Jonas,

Follow up question - is it possible to inline recompose and geometry merge certain pieces? e.g. the front and rear building footprints below, which are the result of the split operation. So that we can then apply different subsequent operations to different buildings. The aim is to create a rule that works in a similar way to how we would normally design a block layout set out via a grid.

DevelopableArea --> split(x, noAdjust) { leftbuildingdepth: split(z) { ~1: leftbuildingrear | buildingseparation1: NIL | ~1: leftbuildingfront } | buildingseparation2: NIL | ~1: split(z) { buildingreardepth: rearbuilding | buildingseparation3: NIL | ~1: centrebuilding | buildingseparation4: NIL | buildingfrontdepth: frontbuilding } | buildingseparation5: split(z) { buildingreardepth: rearbuilding | buildingseparation3: NIL | ~1: NIL | buildingseparation4: NIL | buildingfrontdepth: frontbuilding } | buildingrightdepth: split(z) { buildingreardepth: rearbuilding | buildingseparation3: NIL | ~1: rightbuilding | buildingseparation4: NIL | buildingfrontdepth: frontbuilding } }

Re: Rule inline - geometry merge

SteveFox — Mon, 13 Oct 2025 01:21:54 GMT

Just to follow up - it seemed to be a simple solution to run the inline (recompose), clean up geometry, then after this run comp(f) to identify each individual building.