extruder.py -> .reverse()

[AdrianKriger]

Please open a Discussion.
I might have missed something obvious and basic that might not need the title of Issue.

[hugoledoux]

issue is fine

[AdrianKriger]

These have helped me so much its pretty incredible. Thank you.

I am experiencing challenges with a range of 208, 303 and 307 errors.
It might be the orientation (is_ccw == False / True) of the polygons somewhere or/and the order in which I am adding the vertices. Lets start with the orientation.

extruder -> lines 83-to-102

def extrude_roof_ground(orng, irngs, height, reverse, allsurfaces, cm):
    oring = copy.deepcopy(orng)
    irings = copy.deepcopy(irngs)
    if reverse == True:
        oring.reverse()
        for each in irings:
            each.reverse()
    for (i, pt) in enumerate(oring):
        cm['vertices'].append([pt[0], pt[1], height])
        oring[i] = (len(cm['vertices']) - 1)
    for (i, iring) in enumerate(irings):
        for (j, pt) in enumerate(iring):
            cm['vertices'].append([pt[0], pt[1], height])
            irings[i][j] = (len(cm['vertices']) - 1)
    # print(oring)
    output = []
    output.append(oring)
    for each in irings:
        output.append(each)
    allsurfaces.append(output)

You go:

    if reverse == True:
        oring.reverse()
        for each in irings:
            each.reverse()

but then do nothing with each. Is .reverse() inplace?.
Should it not be reassigned? Into a new rirings.append(each) and then
for (i, iring) in enumerate(irings): becomes -> for (i, iring) in enumerate(rirings):
[and of course irings[i][j] = becomes -> rirings[i][j] = and for each in irings: becomes -> for each in rirings:]

While a new rirings appears correct the result is NOT.

.reverse() inplace	.reverse() assigned

Is .reverse() inplace? If not and needs to be reassigned; this challenge is fixed but there is a problem somewhere else.

[AdrianKriger]

I left the code as extruder.py says and adjusted the order of the vertices.
The .CityJSON is better but the .OBJ needs work -> here.

Can I ask a question about the .OBJ here?
Is the 302 SHELL NOT CLOSED error on the val3dity output for the OBJ: because of the nature of the input ~~ A Solid Building CityObject with no ground floor? I ask this because parsing the surface, from which the .OBJ is created, through val3dity reports a 302.
I do not understand why rings are self-intersecting / partly collapsed.

Should I not create 2.75D surface.obj? I'm not very knowledgeable about these formats and don't want to produce junk.

You are welcome to close.