2026-08-19(수) 세션 — 아티클 형태 재검토: imos DWG 실좌표 대조기(verify3) + 배치 규칙 근본수정
지시(페페, 채팅) = ①밴드 전면/후면 기준 문제 ②선정된 pncad 아티클로 imos 생성 시 판넬 위치·방향 검토 ③3축 좌표 + 두께·폭·길이 비교 ④실생성 아티클 내부파트 대조 후 원인 규명·수정, 새 규칙도 적용 → 운영배포까지. 범위 제외 = 하드웨어 · 보링(가공) · 도어. 최초 시험 대상 = 아티클 트리 BC(코너 하부장 6종).
🔑 이 세션의 근본 성과 — 「좌표 정본」을 처음으로 확보했다
imos 는 부재 좌표를 DB 에 저장하지 않는다(매 렌더 재계산). 그래서 지금까지 대조는 「치수 집합」뿐이었고 위치·방향은 검증 수단 자체가 없었다. 이번에 그 정본을 찾았다.
IDBGPL(부재 86컬럼)·IDBINFO·IDBGEOM전수 확인 → 부재 단위 XYZ 는 DB 어디에도 없다.IDBGEOM(19,435행)은 아티클 삽입점이다(IDBINFO.ID와 조인,IDBGPL과는 0건).- 유일한 실좌표 = 오더 DWG 의 3D 솔리드. 사무실 imos PC(
poinimos01)의D:\ProgramData\imos AG\Factory\Imorder\<오더>\*.DWG를 받아 AutoCAD 2024 COM 으로 뜯었다. - 오더 24건 → 아티클 379 · 부재 3,676매의 실좌표 확보.
좌표 규약 (실측 확정)
아티클 로컬 원점 = 앞·아래·왼쪽 모서리. +x 오른쪽 · +y 앞→뒤 · +z 위
월드 = IDBGEOM.IP + 로컬 (OR_* = 0 일 때)
PNCAD part.box{x,y,z,w,d,h} 와 축·원점이 완전히 같다 — 변환 없이 1:1 비교된다.
페페 질문 ① 밴드 전면/후면 기준 — 답
| 대상 | 정본 컬럼 | 규칙 |
|---|---|---|
| 밴드(TRAVERSE) | VORNE/HINTEN |
앞밴드 = 앞면 플러시(y=0)·z위 = H − 찬넬높이 · 뒤밴드 = 뒷면이 뒤판 앞면·상단 플러시 |
| 천/지판(CABIN 02·03) | UEBERST_V(ueb.v) |
전면 기준이 기본(v=0 → y=0). Rv(리빌)면 그만큼만 뒤로 |
| 밴드 깊이 | 오더변수 $밴드폭 |
CP fixW 보다 우선(60/56). 이름에 mm 박힌 CP(_F_40mm)만 예외 |
| 밴드 눕힘/세움 | TRAVERSE.LAGE |
0 눕힘 · 2 세움(깊이↔높이 뒤집힘) · 1 VV · 3 mixed |
→ 즉 「제한된 폭의 천지판은 전면 기준」이 답이다. 밴드는 애초에 앞/뒤 CP 가 따로 있고 우리 구현이 이미 맞았다. 종전 코드는 천지판을 무조건 뒤기준으로 잡아 벽장·키큰장의 천지판이 21~80mm 뒤로 밀려 있었다(실측 78건).
고친 근본원인 (전부 imos 원본 컬럼 근거 · 추측 0)
- 🔴
convert.mjsFACE_KEY 의 좌우가 뒤집혀 있었다 —{1:'L',3:'R'}→{1:'R',3:'L'}. imos ELEMID = 앞0 → 우1 → 뒤2 → 좌3 시계방향. 대칭 장에선 치수가 같아 안 보이고, 코너 기둥목처럼 좌우가 다른 부재에서만 드러난다. 근거 = ①BC_R_001 도어존 기둥목(ELEMID 1)이 그 존 오른쪽 모서리에 그려진다(DWG x335..350) ②imosRIGHTSIDE가 ELEMID 3 에서 1030/1036 False. ⚠ 라벨을 바꾸면 트림 결합표(PLAN_JOIN)도 같이 미러링해야 한다 — 한쪽만 고치면 치수가 조용히 틀어진다. - 🔴
SIZREF 'O'(Outer)는 앞판 평면뿐 아니라 몸통 존 자체를 장 외곽에 재기준한다. 종전엔fbase만 돌려서 덧방은 맞고 기둥목만 왼쪽 끝에 박혔다(Δx 최대 +570). ※ imos 에 깊이 분할축은 없다(DIVDIR = V/H/I/A 뿐,LINDIVZ10,604행 전부 빈값) — 3축 분할이 아니라 기준면 문제였다. - 🔴 LINDIV 혼합칸 —
1+($CH높이)MM은 「66mm 고정」이 아니라 비율 1 + 65mm 가산이다. 종전엔 단위가 하나라도 붙으면 통째 고정으로 뭉갰다(그래서1-30MM이 −29mm 짜리 칸이 되는 물리적으로 불가능한 값이 나왔고, 자체검사가 그걸 정답으로 박제하고 있었다). → 코너장 이동선반이 존 맨 아래(z=81)로 내려앉던 것이 imos 실측 z=362.5 와 정확히 일치. - 🔴 「밴드는 두께+1 을 먹는다」는 증상보정이었다. 진짜 −1 은 그 부재 자신의 TOPOFFS/BOTOFFS(−0.5×2)다. 존을 깎으면 같은 존을 쓰는 이동선반까지 같이 틀어진다. 존은 두께만 먹고, 세로 부재(L/R·앞면 구조재)가 자기 오프셋만큼 짧아지고 그만큼 떠 있게 했다.
- 🔴
anglelem.INSET= 그 면의 바깥쪽 법선 방향 밀어내기. 앞면이면 −y, 뒷면이면 +y. 도어 INSET −20 → DWG y −20..−2 · 코너 덧방 −4.5 → −4.5..−1.5 · 뒤판각목 −18/−19/−20(189/190). 카탈로그에 이미 들어와 있었는데 좌표에 안 쓰고inner.d깎는 데만 쓰고 있었다. - 뒤판 앵커 — 내경 끝이 뒤판 앞면이고(종전 뒷면), 세로는 아래로 나가는 양만큼 내려간다(종전 가운데정렬). 길이식이 이미 쓰던 항을 그대로 빼면 맞는다. D=330·570·620·650 전량 일치.
- 구조재 앞면은 오버레이가 아니다 — 존 앞면에서 안쪽으로 채운다(inset 0). 종전엔 도어처럼 −t 로 밀어 장 밖으로 15mm 튀어나왔다(BS_DD·W_DD 36건 전량).
- 세운 밴드(LAGE 2) — 깊이=판두께·높이=밴드폭으로 뒤집히고, 깊이 기준이 장 외곽 깊이다 (뒤판 뒤쪽 남는 공간을 채우므로). 뒤판이 깊이를 먹은 장은 뒤끝에서 1mm 띄운다(BS_DD 18 · BO 8).
검증
| 지표 | 착수 | 완료 |
|---|---|---|
| 부재 좌표 일치(verify3) | 35.9% | 60.8% |
| 부재 치수 일치(verify2, 2,726 인스턴스) | 58.3% | 59.1% |
| BC 코너장 6종 좌표 | 45.5% | 97.4% (333/342) |
BC 개별 = BC_R_001 99.4% · BC_L_001 92.5% · 아일랜드 L/R 100% · BC_DD_L 100% · BC_DD_R 90.9%
자체검사 = node lindiv.js PASS · node schema.js PASS
남긴 것 (근거 부족으로 일부러 안 고침)
주방가구_밴드_15T_Rv(서랍장 앞밴드) 의 앞 들여쓰기 38 은 상수가 아니라 텐덤박스 모델별 오더변수다 (38=24건·41=6·36=3·22=3 — 하드코딩하면 65%만 맞는다). 하드웨어 영역이라 이번 범위 밖.BC_DD_R_001기둥목 Δx 7.5(3슬롯 혼합 LINDIV) 1건 ·BC_L_001덧방 L−6/W−6 1건.- BO(오픈장)류
DIVTYPE='A'서브아티클 전개 미구현은 그대로(대조기는 자식 부재를 부모로 롤업해 공정하게 비교).