이것은 정말 좋아 보인다!

그건 그렇고, 우리는 곧 THREE.GLTFLoader 를 제거하고 GLTF2Loader → GLTFLoader 이름을 바꿀 예정입니다*. 혼동을 피하기 위해 r87이 출시되기 전에 내보내기의 이름을 GLTFExporter로 바꾸는 것이 좋습니다. 따라서 릴리스 간에 이름을 변경할 필요가 없습니다. 앗, 이미 이름을 그렇게 지으셨군요.. 계속하세요! 😆

* @mrdoob , 언제 발생해야 하는지에 대한 선호 사항이 있습니까? IMO에서 GLTFLoader 를 사용 중단 경고와 함께 r87에 유지하고 r88에서 제거하지 않으려면 지금 이 작업을 수행할 수 있습니까?

빠를수록 좋다고 생각합니다. 새로운 GLTFLoader 가 1.0을 감지하고 사용자에게 2.0 이상만 지원한다고 경고할 수 있는 한.

IIRC는 앞에서 언급했듯이 asset 를 보고 감지할 수 있습니다.

IIRC는 앞에서 언급한 자산을 보고 감지할 수 있습니다.

✅ 네! https://github.com/mrdoob/three.js/pull/11864

멋있는! 하지만 사소한 버그를 발견했습니다. 지금 PR을 하고 있습니다. 이름을 바꾸기 전에 병합합시다.

누군가가 체크리스트에서 작업하고 있는 항목을 지정할 수 있습니까?

@takahirox 확실히! 사람들은 여기에 댓글을 작성할 수 있고 이미 진행 중인 일이 있으면 목록을 업데이트하고 PR을 가리킬 수 있습니다.

다음으로 작업할 작업은 url을 사용하는 대신 텍스처를 base64로 변환하는 것입니다.

감사 해요! 나는 glTF 수출업자를 만드는 것을 돕고 싶습니다. 체크리스트에서 무엇을 도울 수 있는지 찾고 있습니다 ...

BTW 의도적으로 두 개의 변수 WEBGL_CONSTANTS 및 THREE_TO_WEBGL 전역을 허용했습니까?

@takahirox 멋지다!
두 변수와 관련하여 이것은 WebGLUtils 일부로 만들고 가져오기 위해 다음 PR에서 다룰 것입니다. 이러한 상수를 필요로 하는 각 상수가 매번 다시 재정의해야 한다는 것은 말이 되지 않습니다.

@takahirox btw 물론 목록에 새 항목을 자유롭게 제안하십시오! ;)

@fernandojsg 물론이죠! 변수에 대해 의도적으로 전역으로 선언된 경우 변수를 어딘가로 이동하도록 제안하고 싶었습니다.

공유 버퍼 보기에서 작업하고 싶습니다.

BufferViews: 현재 각 접근자에 대해 새 bufferView를 만들고 있습니다. 동일한 componentType을 공유하는 이러한 속성에 대해 하나만 사용하도록 수정해야 합니다.

모든 속성에 대한 것이 아니라 동일한 componentType을 공유하는 속성에 대한 것이 데이터 정렬을 위한 이유가 맞습니까?

https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#data -alignment

멋지네요, 방금 목록에 추가했습니다 👍 예, 기본적으로 동일한 유형의 구성 요소에 대해 동일한 버퍼 보기를 공유하려고 합니다. 예를 들어 position 및 normal이 있는 경우 두 개의 VEC3 접근자가 있지만 가리킬 것입니다. 같은 버퍼뷰로 그것은 좋은 출발점이 될 수 있습니다 ;)

다른 componentType(예: float 및 short) 간에 버퍼 보기를 공유하지 않는 이유는 좋은 데이터 정렬을 유지하기 위함입니다. 맞습니까?

target 같은 normal (Vec3) , position (Vec3) 및 uv (Vec2) 같은 버퍼 뷰에 다른 구성 요소 유형을 저장할 수 있다고 생각합니다 target 동일한 버퍼 보기에 있을 수 있지만 indices 아닙니다. @donmccurdy 확인해 주시겠습니까?

예, 동의했습니다. 그리고 이 glTF 사양이 언급했듯이

https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#data -alignment

bufferView에 대한 접근자의 오프셋(즉, accessor.byteOffset)과 버퍼에 대한 접근자의 오프셋(즉, accessor.byteOffset + bufferView.byteOffset)은 접근자의 구성 요소 유형 크기의 배수여야 합니다.

단순함을 위해 서로 다른 componentType(= vec2 또는 vec3이 아닌 float 및 short와 같은 데이터 유형) 간에 버퍼 보기를 분리하는 것이 좋습니다. 서로 다른 데이터 길이 componentType으로 분리하면 더 최적화됩니다.

BTW 현재 내보내기가 accessor.componentType float, uint 및 ushort만 지원하는 특별한 이유가 있습니까? glTF 2.0은 char, uchar 및 short를 추가로 처리할 수 있습니다.

https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#accessorcomponenttype -white_check_mark

@takahirox는 그렇지 않습니다. 우리가 지금 지원하는 속성 유형(위치, 법선, 색상, UV, 인덱스 등)에 사용되는 속성이기 때문에 지금까지 정의했습니다.
내가 작업하고 있는 다음 단계는 텍스처이므로 uchar 와 같은 다른 요소가 필요합니다.

좋아, 그래서 나는 당신이 이미 impl을 시작하지 않는 한 먼저 accessor.componentType 에 대해 작업할 것입니다.

거의 준비되었지만 내 PR이 #11978과 충돌해야 합니다.
그래서 #11978이 병합되면 내 것을 보내고 충돌을 수정합니다.

목록에 애니메이션을 추가하시겠습니까?

@takahirox 확실히, 애니메이션을 추가하는 것이 좋을 수 있습니다. 그냥 three.js의 애니메이션 기능의 현재 상태에 대해 충분히 익숙하지 않아서 추가하지 않았지만, 당신이 그것을 인계 받고 싶다면 좋을 것입니다 ;)

BufferGeometry 그룹을 지원할 계획입니까?
GLTF 사양이 이를 포함합니까 아니면 모든 그룹에 대해 새로운 메시를 생성하게 됩니까?
이것은 또한 메시의 머티리얼 속성이 머티리얼 배열이라는 점을 염두에 두어야 합니다.

@marcatec glTF 사양에는 각각 다른 재료를 참조할 수 있는 BufferGeometry 그룹을 생성할 수 있는 "메시" 대 "기본" 구분이 있습니다. 현재 THREE.GLTFLoader는 로딩 프리미티브를 최적화하지 않고 별도의 메시를 생성하지만 구현할 수 있습니다.

훌륭한 작업, 훌륭한 목록 및 형식에 대해 이미 많은 지원이 있다는 것을 알게 되어 기쁩니다! 또한 gltf 블렌더 내보내기와도 매우 잘 작동합니다. 조명 지원을 기다릴 수 없습니다! 앞으로도 힘써주세요.

동의합니다, 훌륭한 일입니다!

StandardMaterial 이외의 다른 재료에 대한 지원을 추가할 계획이 있습니까?

감사 해요!

@homerjam MeshStandardMaterial 과 공유되는 모든 재질 속성은 유지됩니다. 예를 들어 map 및 normalMap 사용하는 MeshPhongMaterial은 해당 텍스처를 그대로 유지한 채로 내보내지만 three.js로 다시 가져올 때 MeshStandardMaterial이 됩니다. 수출업체는 현재 이를 위해 PBR로 순진한 변환을 수행합니다.

왕복 지원(GLTFExporter에서 Phong 내보내기, GLTFLoader에서 Phong 로드)에는 glTF 형식에서 진행 중인 작업이 필요합니다: https://github.com/KhronosGroup/glTF/pull/1150

baseColorTexture : 지원되지만(material.map) texCoord는 항상 0으로 설정됩니다.

@fernandojsg 여기에 누락된 것이 무엇인지 명확히 .map 는 항상 three.js의 첫 번째 UV 세트이기 때문에 glTF에서 이를 나타내는 올바른 방법처럼 들립니까?

또한 주의를 기울이면서 목록에서 세 항목을 지웠습니다. 아래의 추론:

• 접선
  
  
  
  • three.js는 GPU에서만 계산합니다. 수출업자만을 위한 구현을 추가하는 것은 이상적이지 않습니다.
  
  
• 희소 접근자
  
  
  
  • mattdesl의 스크립트 와 같이 내보내기 후 최적화에
  
  
• 재료가 glTF 기본값과 일치하는지 확인하고 생략하십시오.
  
  
  
  • 엣지 케이스처럼 느껴지거나 어수선하지만 누군가가 강하게 느낀다면 자유롭게 구현하십시오.
  
  

편집기에서 GLB로 내보내면서 alphaMap , roughnessMap 및 metalnessMap 가 내보내지지 않는다는 것을 알았습니다.

#13397에서 나는 normalMap 둘 다 내보내지지 않는다고 말했지만 내가 틀린 것 같습니다.

편집기에서 GLB로 내보내면서 alphaMap, RoughnessMap 및 metalnessMap이 내보내지지 않는다는 것을 알았습니다.

누군가가 이미 시작하지 않는 한 오늘 작업할 것입니다.

@donmccurdy

희소 접근자
mattdesl의 스크립트와 같이 내보내기 후 최적화에 맡기는 것이 가장 좋다고 생각합니다.

내보내기가 모프에 대한 희소 접근자를 지원하도록 하는 것과 같은 느낌입니다. 나중에 시도하겠습니다.

@takahirox 멋지다! 가자!

alphaMap 가 glTF 2.0에서 지원되지 않는다고 생각합니다.

https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#material

네, 그게 두려웠어요.... metalnessMap 와 roughnessMap 은요?

지금 작업 중입니다!

13415

이미지 형식에 대해. glTF 2.0은 외부 이미지 파일로 .png 및 .jpg만 지원합니다. embedImages 아닌 모드에서 지원되지 않는 이미지 형식 파일(예: .bmp)을 처리하는 방법을 고려 중입니다.

1. .png 또는 .jpg로 변환하고 포함
2. 신경쓰지마 원본 이미지 파일로 내보내기
3. 수출하지마

나는 1을 선호합니다. 어떤 생각이 있습니까?

와우, 정말 당신의 작품을 감상합니다.

대부분의 3D 모델이 다중 재료를 사용하고 있기 때문에 Multi-material meshes 이 빨리 구현되기를 바랍니다.

1. .png 또는 .jpg로 변환하고 포함
2. 신경쓰지마 원본 이미지 파일로 내보내기
3. 수출하지마

나는 3에 투표하고 콘솔에 경고를 기록합니다.

대부분의 3D 모델이 다중 재료를 사용하기 때문에 다중 재료 메쉬가 최대한 빨리 구현되기를 바랍니다.

동의합니다. 이것은 수출업체의 사용을 방해하는 가장 큰 문제입니다.

대부분의 3D 모델이 다중 재료를 사용하기 때문에 다중 재료 메쉬가 최대한 빨리 구현되기를 바랍니다.

다른 스레드에서 말했듯이, 나는 작업 중입니다.

1. .png 또는 .jpg로 변환하고 포함
2. 신경쓰지마 원본 이미지 파일로 내보내기
3. 수출하지마

나는 3에 투표하고 콘솔에 경고를 기록합니다.

예, 3.이 더 간단하고 사용자에게 혼동을 주지 않을 것이라고 생각하게 되었습니다. emedImages 아닌 모드에서 포함된 이미지를 가져오는 것은 약간 혼란스러울 수 있습니다.

내가 1을 선호하는 이유는 다른 형식에서 glTF로 변환하기 위해서였습니다. 일부(또는 많은) 다른 형식에는 이미지 형식 제한이 없습니다.

내보내기는 embedImages 모드로 변환합니다. 따라서 콘솔 경고에 "변환하려면 embedImages 옵션 사용"을 추가하는 것이 좋을 것이라고 생각합니다.

저도 3번으로 갑니다. 다른 형식에서 변환하는 것은 지루할 수 있으므로 어쨌든 다른 형식에 비해 일부 형식의 우선 순위를 지정해야 합니다. 아마도 지금 당장 3번을 하고 gltf가 ktx와 같은 새로운 텍스처 형식에 대한 지원을 추가하고 구현을 다시 방문할 수 있는지 확인하는 것이 좋습니다.

https://github.com/mrdoob/three.js/pull/13415#issuecomment -369022383에서 논의한 것처럼 exporter가 사용자를 위해 ambientRoughnessMetalness 텍스처를 구성할 수 있다면 좋을 것입니다. 하지만 그 코드를 ImageUtils 에 배치하는 것이 더 나을 것입니다.

최신 변경 사항으로 체크리스트를 업데이트했습니다. multimaterial 항목에 @takahirox 를 추가
나는 또한 material_unlit 확장자를 추가했습니다. 비록 아직 초안이지만 출시가 임박했으며 크게 변경되지 않을 것이라고 믿습니다(/cc @donmccurdy).

대부분의 3D 모델이 다중 재료를 사용하기 때문에 다중 재료 메쉬가 최대한 빨리 구현되기를 바랍니다.

다른 스레드에서 말했듯이, 나는 작업 중입니다.

WIP... (Miku에는 다중 재료가 있습니다)

지원되지 않는 이미지 형식에 대해서는 3으로 가자.

@takahirox 잘 보고 있습니다! 👍

BTW, zip 아카이브 지원에 관심이 있습니까? .glTF + 외부 .bin 및 텍스처는 다른 저작 도구(아마도)에 적합하지만 아카이브가 아닌 경우에는 어렵습니다. 따라서 zip 아카이브가 필요합니다. 내보낸 파일 크기를 줄일 수 있습니다.

나는 그것을 원하고 전에 내 지역 지점에서 시도했습니다. 관심이 있으면 나중에 공유할 수 있습니다.

glb를 압축하는 것과 거의 동일하지 않습니까?

.glTF + 외부 .bin 및 텍스처는 다른 저작 도구에 적합합니다(아마도).

저작 도구에 별도의 파일이 필요하지 않기를 바랍니다. 우리는 모든 사람이 기본적으로 GLB를 사용하도록 권장합니다. 그러나 이미지가 포함되지 않은 경우 이미지를 손으로 편집하는 것이 더 쉽습니다.

해당 기능을 THREE.GLTFExporter 직접 넣을 것인지 여부에 대한 강력한 의견은 없지만 glTF에서 사후 최적화가 될 수 있는 옵션이 너무 많아서는 안 된다고 생각합니다. 또 다른 예로, Draco는 일종의 복잡하고 여러 외부 파일이 필요하므로 특수 glTF-to-glTF 도구가 최적화를 수행하도록 하는 것이 더 나을까요? 그리고 마찬가지로 우리는 glb-unpacker(http://glb-packer.glitch.me/ 반대)를 만들어 사람들이 필요로 하는 파일을 GLB에서 ZIP으로 압축 해제하는 데 도움을 줄 수 있습니다.

https://github.com/KhronosGroup/glTF/issues/1256에서 —

... gltf-pipeline의 원래 의도와 일반적으로 glTF는 내보내기를 가능한 한 단순하게 만들고 최적화를 공통 도구로 푸시합니다. 물론 단편화에도 도움이 됩니다.

즉, 내가 아는 glb-unpacker는 아직 존재하지 않습니다 ...

@mrdoob

나는 텍스처 이미지가 .glTF 대 .glb가 아닌 외부에 있기를 원했습니다.

@donmccurdy

나는 https://github.com/KhronosGroup/glTF/issues/1117 토론을 따랐고 지금 .glb + 임베디드 파일 및 파이프라인 접근 방식을 장려하는 데 동의합니다. 하나의 .glb는 특히 웹용 데이터 전송에 적합하며 파이프라인 접근 방식은 내보내기 및 도구를 간단하고 재사용할 수 있도록 합니다. (저는 UNIX/Linux 명령 파이프라인 접근 방식도 좋아합니다!)

그래서 수출업자가 지금 zip 아카이브 지원을 필요로 하지 않는다고 생각합니다. 그리고 같은 이유로 희소 접근자와 draco 지원이 필요하지 않을 수도 있습니다.

glb-unpacker에 관해서는 여가 시간에 만들 수 있을 것입니다. 일부 아티스트는 glTF 특정 도구 없이 읽을 수 있기 때문에 .glTF + 외부 파일을 좋아한다고 생각합니다. 그리고 가끔 외부 파일은 병렬 로딩으로 인해 로딩 시간을 줄여 최적화 목적으로 사용할 수 있습니다.

파이프라인/최적화 도구와 관련하여 저는 네트워크를 통해 거대한 데이터를 전송하고 싶지 않다는 점에 주목하고 싶습니다. 사용자는 데이터를 ~변환~ 전송하기 전에 최적화/압축하기를 원합니다. 따라서 glTF 최적화 웹 서비스는 사용자가 서버에 대용량 파일을 보내야 하기 때문에 대용량 데이터에 대해 잘 작동하지 않는 경우가 있습니다.

또한 Three.js 및 기타 JavaScript 브라우저 기반 엔진의 경우 브라우저에서 실행되는 glTF 최적화 도구가 있으면 기쁩니다. 데이터가 사용자에게 전달되기 전에 최적화/압축할 수 있습니다. 이 도구가 없으면 사용자는 내보낸 데이터를 수동으로 다운로드한 다음 브라우저 제한으로 인해 파이프라인 도구에 전달해야 합니다.

이러한 관점에서 저는 도구가 브라우저, 서버, CUI 등 어디에서나 실행될 수 있도록 하여 보다 일반적이고 재사용할 수 있기를 바랍니다. 우리는 다른 플랫폼에 대해 같은 목적의 도구를 두 번 이상 만들고 싶지 않습니다. 그렇다면 node.js 기반 도구가 좋을까요? glTF(파이프라인) 팀에 제안 사항이 있습니까? (이 논의는 여기가 아닌 glTF에서 수행되어야 합니다.)

GLTFLoader 바이너리 지원은 확장으로 구현되지만 .glb는 glTF 2.0의 핵심 사양에 있는 경우를 대비하여 맞습니까?

GLTFLoader에서 바이너리 지원은 확장으로 구현되지만 .glb는 glTF 2.0의 핵심 사양에 있는 경우를 대비하여 맞습니까?

예, 그것은 glTF 1.0의 확장이었고 핵심 glTF 2.0 사양의 일부가 된 후 해당 코드를 재배치하거나 이름을 바꾸지 않았습니다.

이러한 관점에서 [최적화 도구]가 브라우저, 서버, CUI 등 어디에서나 실행되어 보다 일반적이고 재사용할 수 있기를 바랍니다. 그렇다면 node.js 기반 도구가 좋을까요? glTF(파이프라인) 팀에 제안 사항이 있습니까? (이 논의는 여기가 아닌 glTF에서 수행되어야 합니다.)

glTF-Pipeline 로드맵 에 glTF-Pipeline이 얼마나 일반적이기를 원하는지, 주로 Cesium 용도인지 또는 제한된 개발자 시간의 문제인지 확실하지 않습니다. 또한 glTF-Toolkit 은 관련성이 있어 보이지만 (현재) Windows에서만 실행됩니다. 개인적으로 Node.js를 좋아하지만 WASM으로 컴파일하면 C++ 또는 Rust가 합리적인 선택이 될 수 있습니다.

아, WASM에 대한 편집이 누락되었습니다. 몇 가지 권장 개발 플랫폼을 지정하는 것은 최적화 개발자에게 좋을 것입니다. 그래서 적절한 스레드에 제안할 것입니다.

파이프라인의 이러한 최적화가 three.js와 다른 저장소에 있을 수 있으므로 모든 사람이 혜택을 받을 수 있다고 생각하기 때문에 @donmccurdy에 동의합니다. 나는 여전히 gltf 파이프라인과 툴킷 도구 간의 차이점을 확인해야 하지만 이러한 종류의 기능이 포함되기를 기대합니다.
나는 또한 우리가 WASM을 가지고 있는 한 소스 언어는 별로 중요하지 않을 것이라는 데 동의하지만, 그것이 node.js로 작성된다면 아마도 3d 웹 엔진 주변의 많은 커뮤니티가 다음과 같이 개선하는 데 도움이 될 수 있다는 것 또한 사실입니다. 어쨌든 지금은 이 파일 형식의 주요 대상입니다.

"변환 전 최적화"에 대해 이해하고 있는지 잘 모르겠습니다... 파이프라인이 모델에서 수행할 수 있는 여러 유형의 변환이 있으며 최적화가 아마도 가장 일반적인 변환 유형일 것입니다.

그 이상으로 동의했습니다. 다른 도구를 빌드하는 데 사용하거나 보다 사용자 친화적인 GUI에 연결할 수 있는 낮은 수준의 집중 도구를 사용하는 것이 좋습니다.

오타입니다. 변신이 아니라 전이. 내 말은, 대부분의 사용자는 네트워크를 통해 데이터를 보내기 전에 최적화/압축을 원합니다. 나는 그들을 더 명확하게하기 위해 게시물을 업데이트했습니다.

안녕 얘들아

THREE.js GLTF 내보내기를 사용하여 전체 aframe 장면을 gltf 개체로 내보내고 있습니다.
프레임에 정의된 a-animation 태그를 gltf 개체의 애니메이션 일부로 가져오려면 어떻게 해야 합니까?

@sunsun_sss @ssssssssss ㅋㅋㅋ

안녕하세요 @siddhartpai — THREE.GLTFExporter 는 THREE.AnimationClip 개체만 glTF 애니메이션으로 변환하는 반면 A-Frame의 애니메이션 시스템은 TweenJS를 사용합니다. 그래서 현재는 불가능합니다. GLTFExporter 도 사용하는 A-Frame 또는 A-Frame Inspector에서 문제를 열어 향후 기능으로 요청할 수 있습니다.

다중 재료 지원 #13536

유효성 검사기가 정규화되지 않은 버퍼 뷰의 모든 일반 요소에 대해 오류를 던진다는 것을 방금 알아차렸습니다. 예를 들어 [0,0,0]과 같은 초기화되지 않은 값을 저장하면 해당 오류가 발생합니다.
경고/통지가 아닌 오류이므로 수정에 민감합니다. 정상적인 bufferview 요소가 정규화되었는지 확인하는 것에 대해 어떻게 생각하십니까? 그럼에도 불구하고 [0,0,0]과 같이 정규화할 수 없는 값의 경우 유효한 단위 벡터를 사용해야 합니까? /cc @donmccurdy

NORMAL 을 정규화해야 하는 것 같습니다.

https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#meshes

노멀 | "VEC3" | 5126(플로트) | 정규화된 XYZ 정점 법선

Three.js normal에는 이러한 제한이 없기 때문에 보장에 동의합니다.

네, 하지만 [0,0,0]의 사용되지 않은 값과 같이 실제 노멀이 없을 때 어떻게 해야 할까요? 그냥 유효한 값을 생성하면 됩니다. [1,0,0]이라고 합시다. 따라서 normal 속성을 구문 분석하고 데이터 보기에 저장하기 전에 각 속성을 정규화하고 있음을 감지하도록 bufferview 코드를 수정해야 합니다.

[0,0,0]의 사용되지 않은 값과 같이 실제 법선이 없을 때 수행할 작업

흠.... 유효한 것으로 교체하고 경고를 표시합니까?

따라서 normal 속성을 구문 분석하고 데이터 보기에 저장하기 전에 각 속성을 정규화하고 있음을 감지하도록 bufferview 코드를 수정해야 합니다.

다음과 같이 더 간단하기 때문에 processMesh() 에서 하는 것을 선호합니다.

var originalNormal = geometry.attributes.normal;

if ( hasNonNormalizedValues( originalNormal ) ) {

    geometry.attributes.normal = createNormalizedAttribute( originalNormal );

}

processAccessorHere();

geometry.attributes.normal = originalNormal;

processBufferView() 에서 이 작업을 수행하면 데이터가 위치 및 일반과 같은 다른 속성 간에 공유되는지 여부에 주의해야 하기 때문에 코드가 약간 복잡해집니다. (매우 드문 사용 사례라는 것을 알고 있지만 Three.js는 제한하지 않습니다.)

예, 나는 그 접근 방식을 좋아합니다. 내보내기 후에 법선을 수정하는 것이 두려웠지만 참조를 저장한 후 완료한 후 다시 저장하면 괜찮을 것입니다. :+1: 이러한 변경 사항으로 PR을 추진하시겠습니까? 아니면 내가 하기를 원하십니까?

알겠습니다. (그걸 고치느라 급하신가요?)

@takahirox 멋지네요 , 감사합니다! 서두르지 않고 그냥 수출업체 현황을 보고 있었어요 ^_^

좋아요, 그럼 ~내일~ 이번주에 하겠습니다.

맞습니다, glTF는 특정 정점에 대한 법선 생략을 허용하지 않지만 단일 프리미티브에서 다른 정점은 생략할 수 없습니다. 어떤 종류의 값을 제공하거나 이러한 정점을 제거하거나 오류를 발생시켜야 합니다.

나는 사용자를 위해 일을 더 쉽게 하는 것을 선호하므로 내 투표는 정규화하는 새 법선 배열을 만들고 빈 배열에 (0,1,0) 값을 추가하는 것입니다.

좋아 보여. 대형 모델의 경우 속도가 느린 경우 checkNormals 옵션 또는 이와 유사한 것을 원할 수 있으므로 이것이 필요하지 않은 사용자는 모든 정점을 스캔하는 대신 옵트아웃할 수 있습니다.

네 저도 그냥 쓰려고 했어요! :NS

대형 모델의 경우 속도가 느린 경우 checkNormals 옵션이나 이와 유사한 것을 원할 수 있으므로 이것이 필요하지 않은 사용자는 모든 정점을 스캔하는 대신 선택 해제할 수 있습니다.

먼저 그 옵션 없이 PR을 할 것입니다. 필요할 때/필요하다면 추가합시다. 개인적으로 이 검사는 그다지 느리지 않다고 생각합니다.

먼저 그 옵션 없이 PR을 할 것입니다. 필요할 때/필요하다면 추가합시다. 개인적으로 이 검사는 그다지 느리지 않다고 생각합니다.

페인터에서 각 스트로크를 로드할 때 전체 버퍼를 정규화했는데 상당히 느립니다.

정상화 되었는지 확인만 해도?

@takahirox 어쨌든 길이를 계산해야하므로 그렇게 많이 변하지 않을 것입니다.

흠, 알았어. PR로 평가하겠습니다.

이것은 우리가 도입한 첫 번째 GLTFExporter 기능으로 각 정점으로 모든 계산을 수행합니다(상대/절대 모프 대상 변환 제외). 그래서 잠재적으로 더 느립니다. 어느 쪽이든.

훌륭한 일! IMHO는 "예제"가 아닌 핵심 three.js에 병합되어야 합니다.
KHR_lights_punctual 지원을 보고 싶습니다!

PR https://github.com/mrdoob/three.js/pull/15519는 KHR_lights_punctual을 추가합니다. :)

이 문제는 닫을 수 있다고 생각합니다. 나머지 항목은 덜 중요한 편의성이나 최적화이며 다른 곳에서 추적할 수 있습니다.

• [ ] 버퍼 뷰 재사용
• [ ] 금속/거친/ao 텍스처 자동 병합

안녕하세요, 모프 변경 사항을 적용하고 최종 개체에서 제거하여 사용자 정의 모양의 메쉬를 내보내는 방법을 아는 사람이 있습니까?
이 질문처럼 https://stackoverflow.com/questions/57423471/how-to-export-morph-changed-meshes-from-threejs-application
미리 감사드립니다!

@vini-guerrero GitHub 문제보다는 포럼(https://discourse.threejs.org/)이나 Stack Overflow를 이용해 도움을 주세요.