Problem With Trimmed Geo and Balconies

3153
15
03-19-2012 03:00 AM
AndréCardoso
New Contributor III
Hi, I have a problem 😛


I'm building balconies, and I'm relying on the trim planes to "join" balconies on different facades:

BalconyStripe -->
    s('3, '1, balconyLength)
    center(x)
    i("builtin:cube:notex")
    BalconySupport



The problem is that after trimming I get NO endings on the volume, just a hole. Like in the screenshot.

Can someone help me with this? What's the best approach for these situations?

Thanks!
André
0 Kudos
15 Replies
AndréCardoso
New Contributor III
And thanks for the explanation 🙂

I think I'm going to change my balconies to use your asset 😛


hi !

I've had a look at your asset and it makes sense that it cannot be closed.

CE can only close 'cylinder - like', CLOSED assets, even if the ends are missing as on my asset. your asset is open on the back side, thus it is not closed as an 'O', but open as a 'C', profile-wise spoken.

once you have it closed, make sure you merge all the vertices and eges properly to make the tube mathematically 'watertight'.


ok ?

I'll track the linux/windows changing indices down !

matt
0 Kudos
by Anonymous User
Not applicable
Original User: thyandrecardoso

As I told you, I was trying to use your asset "profileAsset.obj" instead of the one I've been using on the balconies. But the asset you gave me comes with normals pointing inside. If you import the asset into CE, and turn on "Backface Culling" you'll see through it!


Now the interesting part:
- to overcome this, I made a small change to your previous CGA code:
PutBalcony -->
 s('20, thickness, depth)
 center(x)
 i(profileAsset)
 reverseNormals
 LeftTrim(leftEdgeID)


And now I can't seem to produce the closing geometry anymore. I think I tried all the edge IDs...

Can you replicate this?
0 Kudos
AndréCardoso
New Contributor III
Of course that, for this specific case -- using your asset, with the normals as they are -- a simple workaround is to leave the "reverseNormals" command to last place:

LeftTrim(n) -->
 alignScopeToGeometry(yUp, n)
 alignScopeToAxes(y)
 split(z) {miniCutDepth : NIL | ~1 : RightTrim(rightEdgeID)}

RightTrim(n) -->
 alignScopeToGeometry(yUp, n)
 alignScopeToAxes(y)
 split(z) {miniCutDepth : NIL | ~1 : reverseNormals X.}



This way, using the indices 3 and 1 to "split" the geometry continues to work!


Can you explain me what is going on? I'm a bit confused here...
0 Kudos
by Anonymous User
Not applicable
Original User: matthiasbuehler

hi !


indeed, the normals of my asset were inverted. how EVER that happened .. 😞

attr depth = 2
attr thickness = 0.3
attr miniCutDepth = 0.5

profileAsset = "assets/profileAsset_normalsOutside.obj"


attr leftEdgeID = 0
attr rightEdgeID = 2

Lot -->
 extrude(10)
 split(y){~3 : comp(f) {side :Facade(split.index) | top : Roof.} }*

Facade(i) -->
 case i != 0 && p(0.6) :
  Facade.
  PutBalcony
 else :
  Facade.

PutBalcony -->
 s('20, thickness, depth)
 center(x)
 i(profileAsset)
 LeftTrim(leftEdgeID)

LeftTrim(n) -->
 print (geometry.nEdges)
 alignScopeToGeometry(yUp, n)
 split(z) {~1 : RightTrim(rightEdgeID) | miniCutDepth : NIL}

RightTrim(n) -->
 alignScopeToGeometry(yUp, n)
 split(z) { ~1 : X. | miniCutDepth : NIL}


I adapted the code as seen here and it works again (you can even delete the additional alignScopeToAxes(y) in the Left and RightTrim rules, as done here). Note the 'new' indices which work here. I tested those indices both on Windows and Linux (including backface culling) !

* * *

I faced the same issue as you did where it seemed that no index seems to work : that fix was easy.

since the normals drive the scope alignment (and the normals were inverted), inverting the asset to the 'correct sidedness' inverts the split direction. this means that the split order has to be reversed (note that ~1 : is now first in the split)!

with the indices 0 and 2 and the new asset, everything works fine.

* * *

*phew* .. I'm glad the edge indexing after the trim is consistent on both Linux and Windows !


more questions ? 🙂

btw. sorry for the confusion with the normals !
0 Kudos
AndréCardoso
New Contributor III
Now, that's more clearer 😄
Many thanks for the time spent around this problem, finally understood it 🙂

No, no more questions... for the time being 😛

Thanks!!
André
0 Kudos
by Anonymous User
Not applicable
Original User: matthiasbuehler

ha !

it's been a nice session indeed ! 😮
0 Kudos