파생 된 obj 파일의 구조가 원본 단계 파일의 이름과 함께 있어야합니까?

Question

Model Derivative API를 사용할 때 단계 파일에서 obj 표현을 성공적으로 생성합니다. 그러나 그 과정에서 내가 완전히 이해하지 않는 몇 가지 단점이 있습니다 :

1. 포스트 작업이 "multiple"로 설정할 수있는 output.advanced.exportFileStructure 특성 및 모델의 어느 부분을 당신이 할 지정할 수있는 output.advanced.objectIds 속성이 있습니다 추출하는 걸 좋아해. 작은 문서에서 말하길, 요청 된 objectid 당 하나의 obj 파일을받을 것으로 기대합니다. 내 경험으로 볼 때 그렇진 않습니다. 압축 된 파일 (예 : .iam 및 .ipt)에서만 작동합니까?

2. 어쨌든, 대신 objectId 당 하나의 다각형 그룹을 가진 모든 objectIds에 대해 하나의 obj 파일을 얻습니다. 그룹의 이름은 (duh!)이므로, 나는 그것들이 objectId와 같이 이름이 붙여지기를 기대하지만 숫자가 무작위로 할당되는 것처럼 솔기가 있습니다. 그렇다면 어떻게 실제로 objectId를 해당 3D 파트에 매핑해야합니까? urn/metadata/: guid/properties를 GET에서 객체로 연결하는 방법이 있습니까?

누군가가 빛을 발할 수 있기를 바랍니다. 더 많은 정보가 필요하면 원본 단계 파일 인 obj와 내 서버 로그를 제공 할 수 있습니다.

Answer 1

파생 상품 API의 objectIds 속성을 잘못 이해했습니다.이 필드를 사용하면 특정 구성 요소 만 단일 obj로 내보낼 수 있습니다 (예 : 자동차 모델에 1000 개의 구성 요소가 있지만 엔진을 나타내는 구성 요소 만 내보내려는 경우). : [34, 56, 76] (나는 방금 그들을 만들었습니다 ...). 각 objectId를 별도의 obj 파일로 내보내려면 여러 작업을 시작해야합니다. "exportFileStructure"옵션은 복합 디자인 (즉, 어셈블리)에만 적용됩니다. 단일 : 모든 입력 파일 (어셈블리 파일)에 대해 하나의 OBJ 파일을 만들고, 다중 : 각 객체에 대해 별도의 OBJ 파일을 만듭니다. 단계 파일은 복합 설계가 아닙니다.

obj 그룹의 이름이 임의로 지정되었습니다. 내가 아는 한 .obj는 매우 기본적인 형식이고 메타 데이터를 지원하지 않기 때문에 obj 파일의 구성 요소를 원래의 objectId에 쉽게 매핑 할 수있는 신뢰할만한 방법은 없습니다. 기하학적 접근법 (공간에서 구성 요소가 어디에 있는지 알아 내고 테두리 상자를 사용하여 ...)을 사용하여 매핑을 달성 할 수 있지만 복잡한 모델에서는 어려울 수 있습니다.