Three.js: UV 오프셋/반복은 텍스처가 아닌 머티리얼의 일부여야 합니다.

관련 게시물: https://github.com/mrdoob/three.js/issues/3549

재료별로 텍스처를 복제해야 합니다(많은 메모리 낭비).

어떤 의미에서 수많은 메모리가 낭비됩니까?

"공유" 텍스처에서 공유 UV 오프셋/반복이 필요할 가능성은 낮습니다.

그게 무슨 뜻 이니?

현재 접근 방식을 유지하는 경우 변경해야 할 한 가지는 텍스처가 복제될 때 공유 이미지를 GPU에 한 번만 전달해야 한다는 것입니다.

많은 수의 프레임/시트가 있는 개체가 있는 경우 많은 쓸모 없는 개체가 생성되고 말씀하신 대로 이미지가 GPU에 여러 번 복사되어 매우 낭비됩니다. 훨씬 더 낭비가 되는 것은 다른 애니메이션에서 서로 다른 지점에 있어야 하는 여러 개체가 있는 경우 고유한 재질/개체별로 고유한 텍스처 집합을 만들어야 하므로 재질 유니폼이 이러한 추가 텍스처 오프셋/반복 데이터 구조가 제대로 작동하도록 하기 위해 잘못 생각한 API를 중심으로 구축하지 않고도 훨씬 더 쉽게 조작할 수 있습니다. 모든 곳에서 이러한 고유한 텍스처 그룹을 생성해야 하는 내 응용 프로그램의 특정 사용 사례에서 속도가 크게 느려지고 유일한 해결책은 이 단일 문제를 해결하기 위해 사용하는 모든 스톡 재질을 셰이더 재질로 교체하는 것입니다. 그렇지 않으면 내 THREE.js 버전을 포크하고 필요한 수정을 하십시오.

두 번째 진술과 관련하여:

현재 패러다임은 동일한 UV 오프셋/반복으로 동일한 텍스처를 적용하려는 경우에만 작업을 용이하게 한다는 것을 의미했지만 일반적으로 드문 경우입니다. 소재별로 유니폼을 입고 텍스처가 아닌 소재를 공유합니다.

현재 시스템의 주요 경고. 오프셋/반복은 셰이더의 모든 텍스처에 영향을 미치는 단일 유니폼으로만 존재하지만 THREE.Texture에 첨부되어 있다는 사실은 유니폼으로 제대로 사용할 수 없고 사람들이 오프셋/반복이라고 생각하도록 속이는 것을 의미합니다. 스톡 머티리얼에 적용할 수 있는 다양한 텍스처에 대해 다르게 선택할 수 있습니다(즉, 다른 디퓨즈 오프셋과 노멀 맵 오프셋을 정의할 수 있지만, 서로 다른 텍스처에 고유하게 설정할 수 있음에도 불구하고 실제로는 불가능합니다). 나는 그것이 캔버스 렌더러에서 남아 있을 수 있다는 것을 알 수 있지만, 그것을 크게 찬탈한 webGLrender / GLSL 머티리얼 시스템에서는 의미가 없습니다.

mrdoob은 재료별로 가지고 있는 것에 반대하는 이유로 다음과 같은 형식이 필요하다고 말했습니다.

재료.지도
material.map오프셋
material.map반복
재료.env
material.envOffset
material.env반복
... 등.

그러나 다시 오프셋/반복은 지금도 맵 유형별로 작동하지 않으므로 이것은 실제로 유효한 인수가 아닙니다. 어쨌든 맵 유형별로 사용하기에는 너무 많은 유니폼을 낭비하게 됩니다. (일반적으로 UV 세트를 하나만 사용하므로 노멀맵/범프맵/디퓨즈맵/스페큘러맵에 대해 여러 오프셋을 갖지 않을 것입니다). 모든 옵션을 합리적으로 평가한다면 텍스처 속성이 아니라 머티리얼 속성이어야 한다고 생각합니다. 현재 시스템에 어떤 이점도 없다고 생각합니다. UV 오프셋을 통해 머티리얼에 애니메이션을 적용하는 것은 속성을 가질 수 있는 주요 이유이기도 하고 제대로 사용하지도 못하는 것 같습니다. 말할 것도 없이 이러한 유니폼이 필요하지 않은 경우 셰이더 컴파일에서 생략할 수 있지만 지금은 맵이 있는 한 거기에 있습니다.

@QuaziKb 여기에서 제안한 것과 같이 라이브러리에 대한 근본적인 변경을 제안하려면 해당 변경에 대한 명확하고 설득력 있는 주장을 제공해야 합니다. 특정 응용 프로그램의 참조 프레임에서 논쟁하는 것은 그것을 자르지 않을 것입니다.

즉, 오프셋/반복이 Texture 에서 재료로 이동되는 것을 보고 싶습니다.

다음 맵이 동일한 오프셋/반복 값을 갖는다고 가정하는 것이 합리적이라고 생각합니다.

specularMap
normalMap
bumpMap
alphaMap
aoMap (future)
glossMap (future)
displacementMap (future)

단 하나의 예외는

이것이 현재 구현되는 방식입니다. 각 맵에는 고유한 오프셋/반복 값이 있지만 적용되지 않습니다.

따라서 MeshPhongMaterial , MeshLambertMaterial , MeshBasicMaterial 및 SpriteMaterial 에 추가할 수 있습니다.

mapOffset // or mapTranslate
mapRepeat // or mapScale

repeat 에서 Texture offset 및 repeat 제거합니다.

이러한 방식으로 스프라이트 시트를 구현하는 것은 간단합니다. 각 스프라이트에는 재질이 있으며 해당 재질은 단일 텍스처를 공유합니다. 질감에 이미지가 있습니다. 텍스처를 더 이상 복제할 필요가 없습니다. GPU 측에서 재료는 단일 셰이더 프로그램을 공유합니다.

IMHO, 이것은 보다 자연스러운 API입니다.

API가 그대로 구현된 이유를 기억하려고 합니다. 그럴만한 이유가 있었을 거라 예상합니다.

죄송합니다. 이것이 제 예에만 해당된다는 의미는 아닙니다. 단순히 현재 API가 실제 솔루션 없이 고유한 개체/재료별로 애니메이션 스프라이트 시트/오프셋을 사용할 때 상당한 부풀리기를 초래한다는 것입니다. 당연히 모델의 정점 UV에 오프셋/반복을 단순히 굽는 것보다 이것을 유니폼으로 사용하는 주요 목적은 오프셋을 애니메이션화하는 것이며, API를 돌아다니지 않고는 이것이 불가능하다고 제안했습니다. 텍스처에 붙는 것보다 훨씬 덜 유용합니다.

다음 맵이 동일한 오프셋/반복 값을 갖는다고 가정하는 것이 합리적이라고 생각합니다.
지도
...
알파맵

FWIW, 이 동작(현재 구현)은 지금 이 순간에 저에게 상당한 좌절을 야기하고 있습니다. 메쉬 재질의 alphaMap 오프셋을 분산 맵(고정 ​​상태로 유지됨)과 독립적으로 트위닝하여 메쉬 표시를 애니메이션으로 만들려고 합니다. 약간의 좌절 후에 https://github.com/mrdoob/three.js/pull/4987 및 이 버그를 통해 이것이 불가능하다는 것을 발견했습니다.

@jcarpenter 당신이 말하는 "버그"는 무엇입니까? 개선을 위한 제안 사항은 무엇입니까?

수정: "버그"는 이 문제를 의미했습니다. Bugzilla 문화에서 과도한 시간으로 인한 혼란. :p 이것은 버그가 아니라 의도된 동작이라는 것을 이해합니다.

Cinema 4D와 같은 기존의 3D 콘텐츠 제작 앱에 대한 제 경험을 바탕으로 WRT를 개선하여 사용자가 다음 두 가지를 모두 할 수 있다고 상상합니다.

• 다른 텍스처와 독립적으로 재질 내의 각 텍스처에 대해 오프셋/스케일/반복을 정의합니다.
• 상위 재료의 오프셋/축척/반복 정의

또는 내가 작업하고 있는 사용 사례("메쉬 공개 애니메이션 시도")의 경우 전혀 래핑하지 않는 wrapS 및 wrapT에 대한 옵션이 있으면 환상적일 것입니다. UVW 매핑을 위해 타일링을 완전히 비활성화하는 옵션이 있는 Cinema4D의 첨부된 GIF에 따라. 기존 wrapS 및 wrapT 메서드를 사용한 상당히 광범위한 테스트를 기반으로 하면 이와 같은 것은 불가능합니다. three.js에서 항목의 표시를 애니메이션화하는 옵션은 전체 메시의 위치와 불투명도를 트위닝하는 것으로 제한되어 있는 것 같습니다... 내가 뭔가를 놓치고 있지 않는 한.

동의. 계획은 이 모든 것을 단순화하고(셰이더에서 단일 매트릭스3 사용) 텍스처당 오프셋/반복(또는 이동/스케일)을 갖는 것입니다.

이것에 도움을 주고 싶은 사람은 누구라도 대단히 감사할 것입니다!

@jcarpenter

슬프게도 지금 당장 이것을 할 수 있는 유일한 방법은 여러 메시 w/ 다른 재질 또는 사용자 정의 셰이더 재질을 사용하는 것입니다. 둘 다 three.js 워크플로에 막 뛰어드는 사용자를 위한 것입니다.

사용성, 성능 및 확장성 사이에는 일정한 균형이 있습니다. 내 제안은 텍스처와 재료가 현재 API에서 작동하는 방식을 다시 작성하여 텍스처가 엄격하게 플러그인하는 매개변수이고 오프셋/반복/랩 모드와 같은 셰이더에서 실제로 균일한 값이 특별히 링크되도록 하는 것입니다. 재료. 어떤 경우에는 변경할 필요가 없는 텍스처에 대한 UV 제어에 유니폼 낭비를 원하지 않습니다(확산에만 필요한 경우 퐁 재질에 4*5 추가 유니폼을 갖는 것은 엄청난 낭비일 것입니다). 특정 UV가 필요하고 텍스처가 이러한 요구 사항을 충족하도록 재구축되는지 여부를 감지하는 배후에서 마술이 있거나 필요한 조정 가능한 UV의 수를 지정하기 위해 일부 매개변수를 선택적으로 전달할 수 있다면 멋질 것입니다. 오프셋 및 방법을 매핑하지만 해결하기 어려운 문제입니다.

계획은 이 모든 것을 단순화하고(셰이더에서 단일 행렬3 사용) 텍스처당 오프셋/반복(또는 이동/스케일)을 갖는 것입니다.

@mrdoob

1. 텍스처 변환이 재질에 있도록 _per material.map_을 의미합니까? 불행히도 많은 재료 맵이 있습니다. 라이트맵을 제외하고 모든 텍스처 변환이 동일하다고 계속 가정할 수 있습니다.
2. 당신도 로테이션을 지원하고 싶습니까? 그렇다면 회전 중심도 추가해야 합니다. 회전 중심을 텍스처 중심에 고정하고 싶지 않다면 말입니다.

이것은 매우 감사한 변화일 것입니다. 고유한 반복 값을 배치하기 위해 텍스처를 복제해야 하는 것은 매우 성가신 일입니다. 다른 도서관에서는 이렇게 합니까?

1. 텍스처 변환이 재질에 있도록 _per material.map_을 의미합니까? 불행히도 많은 재료 맵이 있습니다. 라이트맵을 제외하고 모든 텍스처 변환이 동일하다고 계속 가정할 수 있습니다.

맵당 mat3 가 있어야 하고 Texture 속성으로 구성되어야 한다고 생각합니다.

1. 당신도 로테이션을 지원하고 싶습니까? 그렇다면 회전 중심도 추가해야 합니다. 회전 중심을 텍스처 중심에 고정하고 싶지 않다면 말입니다.

회전 네. 중앙인지 아닌지... 확실하지 않지만 내가 이해하는 한 이 모든 것은 셰이더에 대해 단일 mat3 로 인코딩될 수 있습니다(맵당).

다음 은 Matrix3 가 셰이더에 전달되고 offsetX , offsetY , repeatX , repeatY 정의된 변환을 나타내는 방법을 보여주는 프로토타입입니다 offsetX repeatY , rotation , rotationCenterX 및 rotationCenterY .

center 가 옵션으로 허용되지 않으면 ( 0.5, 0.5 ) 고정 연결되어야 합니다.

댓글 환영합니다.

편집: 데모 업데이트됨

이것은 훌륭합니다! :+1: :+1:

하지만 translation 및 scale ( offset 및 repeat 대신)로 갈 것이라고 생각합니다.

새로운 재료 속성은 정확히 무엇이어야 합니까? 많은 재료 맵이 있습니다.

텍스처 속성에서 무엇을 제거해야 합니까?

wrapS/T 가 텍스처에 남아 있어야 한다고 가정합니다.

texture.offset 및 texture.repeat 를 제거해야 한다고 생각합니다.

새 속성은 texture.translation , texture.rotation , texture.scale , texture.center 및 texture.matrix 이어야 한다고 생각합니다. 렌더링 시 호출되는 texture.updateMatrix() 메서드도 필요할 것입니다. 물론 이것은 텍스처를 재사용하더라도 한 번만 하도록 해야 하는 문제가 있습니다.

이 게시물의 제목과 https://github.com/mrdoob/three.js/issues/5876#issuecomment -69483293의 인수를 참고하여 이러한 속성을 머티리얼로 옮기는 것이 포인트라고 생각했습니다.

/ping @bhouston에 대한 의견.

내 생각은 텍스처 오프셋/반복이 가능한 한 많이 UV에 구워져야 한다는 것입니다. 더 쉽습니다. 이것이 UE4/Unity 5가 대부분의 작업을 수행하는 방식입니다.

예외는 Unity 5가 모든 텍스처에서 공유되는 재질당 하나의 전역 오프셋/반복을 지정할 수 있다는 점입니다. 조정하는 것은 의미가 없습니다.)

여기서 많은 유연성을 옹호하지 않는 이유는 전문적으로 생성된 모델에는 일반적으로 필요하지 않은 적절한 UV가 있기 때문입니다. 콘텐츠 생성 도구에는 이를 굽는 방법이 있습니다. 다른 문제는 WebGL이 Fragment Uniforms -- 16 Vec4에 대해 터무니없이 낮은 하한선을 가지고 있다는 것입니다. 맵당 반복/오프셋이 있어야 하고 곧 많은 맵을 얻게 된다면 매우 적은 가치로 Fragment Uniforms를 낭비하게 될 것입니다.

실제로 최근 Clara.io에서 반복/오프셋을 추가한 다음 텍스처당 밝기/게인 컨트롤을 추가했으며 모든 Apple iOS 장치와 같은 저가형 장치에서 조각 유니폼 오버플로로 이어지기 때문에 이러한 변경 사항을 취소할 것입니다. 반복/오프셋 및 밝기/게인이 NVIDIA 980이 탑재된 데스크탑에서 훌륭하게 작동하지만 우리는 고급 컴퓨터가 아닌 모든 사람을 위해 설계해야 합니다. ;)

우리는 조각 유니폼을 존중해야 하며 필요할 때만 사용해야 합니다. 나는 이것이 그러한 경우 중 하나가 아니라고 생각합니다.

예외는 Unity 5가 재료당 하나의 전역 오프셋/반복을 지정할 수 있다는 점입니다.

이것은 기본적으로 three.js가 지금 하는 일입니다. 비록 그것이 확산 맵에서 오프셋/반복을 가져오고 다른 모든 재질 텍스처는 해당 맵의 설정을 사용하지만.

제안은 텍스처에서 오프셋/반복을 제거하고 대신 재료에 추가하는 것입니다. 아마도 이름이 변경될 것입니다. 다시 말하지만, 모든 머티리얼 텍스처는 동일한 설정을 공유합니다(일부 사용자는 이에 대해 만족하지 않을지라도). 이렇게 하면 균일한 사용량을 낮게 유지할 수 있습니다.

불행히도, 우리는 이것에 대해 많은 합의를 얻지 못하고 있습니다.

Unity 5가 하는 일을 하는 것은 좋은 생각입니다. 질감이 아닌 소재에도 올려봅니다. 당신은 내 지원이 있습니다.

맵별은 실제로 이상적이지는 않지만 필요한 경우에 대비하여 재료를 빌드할 때 플래그/키로 지정하여 해결할 수 있습니다.

일반적으로 셰이더에서 UV를 수정하는 유일한 이유는 UV가 애니메이션되기를 원하기 때문입니다. UV를 정적으로 변환하려는 경우 이 기능을 추가하기 위해 셰이더를 수정해서는 안 됩니다.

셰이더에 대해 제안된 유일한 변경 사항은

vUv = uv * offsetRepeat.zw + offsetRepeat.xy;

~와 함께

vUv = ( uvTransform * vec3( uv, 1 ) ).xy;

확인. 이것은 어떻습니까... texture.dynamic (기본적으로 false )를 추가하여 다음을 생성합니다.

vUV = uv;

사용자가 설정하는 경우 texture.dynamic 로 true 우리가 계산 texture.matrix 아웃 texture.translation , texture.rotation , texture.scale 및 texture.center , 우리는 그것을 programa에 전달하고 우리는 다음을 생성합니다:

vUv = ( uvTransform * vec3( uv, 1 ) ).xy;

물론 texture.dynamic 변경되면 프로그램을 다시 컴파일해야 합니다.

그렇게 하면 두 세계의 장점을 모두 얻을 수 있습니까?

@mrdoob

1. 귀하가 보기에 scale 는 텍스처의 속성입니까 아니면 texture.scale 는 재질의 속성입니까? 그것이 이 스레드의 전부이기 때문에 후자이기를 바랍니다.
2. .matrix 속성은 필요하지 않습니다. 새로운 Matrix3 는 재료 유니폼 offsetRepeat 을 대체하는 유니폼입니다. 렌더러의 다른 매개변수에서 계산되어 다른 유니폼과 마찬가지로 GPU에 전달됩니다.

1. 귀하가 보기에 scale 는 텍스처의 속성입니까 아니면 texture.scale 는 재질의 속성입니까? 그것이 이 스레드의 전부이기 때문에 후자이기를 바랍니다.

이 스레드에 동의하지 않습니다. mapMatrix , envMapMatrix , ... 또한 mapTranslation , mapRotation , mapScale 재료를 오염시켜야 한다고 생각하지 않습니다. THREE.Texture 에 translation , rotation , scale 그리고 아마도 center 가 있으면 더 깨끗하다고 ​​생각합니다.

1. .matrix 속성이 필요하지 않습니다. 새로운 Matrix3 는 재료 유니폼 offsetRepeat 을 대체하는 유니폼입니다. 렌더러의 다른 매개변수에서 계산되어 다른 유니폼과 마찬가지로 GPU에 전달됩니다.

우리는 그런 것이 필요합니다. 다른 맵에서 동일한 텍스처를 재사용한다고 가정해 보겠습니다. 우리는 모든 인스턴스에 대해 Matrix3 를 계산하고 싶지 않습니다.

이 스레드에 동의하지 않습니다. mapMatrix, envMapMatrix, ...도 mapTranslation, mapRotation, mapScale을 사용하여 재료를 오염시켜야 한다고 생각하지 않습니다. THREE.Texture에 변환, 회전, 크기 및 중앙이 있으면 더 깨끗하다고 ​​생각합니다.

다른 반복 속성을 가지려면 텍스처를 복제해야 합니까? 작은 장면에서는 별 문제가 아니지만 이미 40개 이상의 텍스처가 있는 큰 장면에서는 메모리 악몽입니다.

@titansoftime image 는 THREE.Texture 에서 분리되어야 합니다. 이상적으로는 translation , rotation , ... 구성이 다른 THREE.Texture 하나의 단일 THREE.Image 사용할 수 있습니다.

@titansoftime 이미지는

그것은 의미가 있습니다. texture.clone()이 이미 이런 식으로 작동합니까, 아니면 수동으로 설정해야 합니까?

texture.clone() 는 그런 식으로 작동하지만 WebGLRenderer 는 이미지가 동일한지 알 수 없으므로 텍스처 업로드가 필요하지 않습니다...

이 스레드에 동의하지 않습니다. mapMatrix, envMapMatrix, ...도 mapTranslation, mapRotation, mapScale을 사용하여 재료를 오염시켜야 한다고 생각하지 않습니다. THREE.Texture에 변환, 회전, 크기 및 중앙이 있으면 더 깨끗하다고 ​​생각합니다.

이것이 기본적으로 우리가 지금 하는 일입니다. 각 텍스처에는 고유한 offset 속성이 있으며 개별 오프셋은 적용되지 않습니다. 렌더러는 재질의 각 맵에 대해 동일한 오프셋을 사용합니다.

FWIW, https://github.com/mrdoob/three.js/issues/5876#issuecomment -69483293 에서 말한 대로 해야 한다고 생각합니다.

API가 @jcarpenter 가 원하는 작업을 허용하지 않는 이유를 알 수 없습니다( alphaMap 의 오프셋에 애니메이션 효과를 주는 반면 map 는 동일하게 유지됨 ). 캔버스에서 그렇게 할 수도 있지만 대신 GPU의 작업이라고 생각합니다.

사람이 할 수있는 일의 톤이 상쇄 ... 다른 맵의 오프셋 (offset)로 재생하여이 alphaMap 스케일링 만 normalMap , 등

재료당 uvTransform 하나만 갖는 것은 매우 제한적인 것 같습니다.

오, 잠깐. 재료별로 선호하시는 이유를 알 것 같아요. 이렇게 하면 조각 셰이더에서 픽셀당 uv를 계산하는 대신 정점 셰이더에서 단일 vUv가 계산됩니다. 오른쪽?

오프셋은 실제로 재료의 유니폼을 사용하여 구현되고 텍스처와 아무 관련이 없기 때문에 재료별이 이상적입니다. 수많은 새로운 객체/텍스처(JS에서는 상당히 나쁘고 WebGL에서는 끔찍함)는 사용자에게 숨겨져 있는 재료 유니폼의 기능일 뿐인 것을 제어하기 위한 것입니다. 결코 텍스처의 일부가 유리하거나 더 효율적이거나 더 명확하지 않으며 런타임에 변경되는 UV, 애니메이션을 지정하는 실제 응용 프로그램이 API로 인해 느리고 비효율적으로 렌더링됨을 의미합니다.

텍스처는 이미지와 그 이미지와 관련된 모든 것을 지정해야 합니다. UV 오프셋은 이미지/이미지 속성과 아무 관련이 없으며 텍스처를 표시하는 머티리얼과 관련된 모든 것입니다. 이 기능이 머티리얼의 일부가 아닌 경우에도 이 기능을 갖는 것은 말도 안 됩니다. 많은 경우에 실제로 기능을 사용하려는 경우 많은 텍스처를 동시에 업데이트합니다.

애니메이션 타일의 모든 프레임에 대해 다른 이미지가 있고 해당 타일의 오프셋/반복도 제어하고 싶어한다고 상상해 보십시오. 들어오는 모든 프레임을 오프셋으로 업데이트해야 하고 해당 타일을 사용하는 모든 고유한 재료 인스턴스에 대한 모든 프레임의 복사본이 있어야 합니다. 실제로 제어하는 ​​것에 대해 수백 개의 새로운 개체와 추가 할당으로 빠르게 눈덩이처럼 쌓입니다. 정당한 이유 없이 이러한 모든 객체를 사용하는 장면 뒤에서 재료당 몇 개의 수레가 발생합니다.

맵당 변환에 관해서는, 좋겠지만 대부분의 경우 균일 비용이 이유 없이 너무 높습니다. 변환이 고유하거나 공유 또는 동적이어야 하는 시기와 방법을 제어하는 ​​복잡한 API가 있는 경우를 제외하고 IMO 그 통제를 갖는 것은 좋은 일이지만 신중하게 생각해야 할 것입니다.

오, 잠깐. 재료별로 선호하시는 이유를 알 것 같아요. 이렇게 하면 조각 셰이더에서 픽셀당 uv를 계산하는 대신 정점 셰이더에서 단일 vUv가 계산됩니다. 오른쪽?

아니오. uv는 언제나처럼 정점 셰이더에서 계산됩니다.

스프라이트 시트와 20개의 스프라이트를 상상해 보십시오. 현재 http://threejs.org/examples/misc_ubiquity_test2.html 에서와 같이 20개의 복제된 재료와 20개의 복제된 텍스처가 필요합니다 SpriteMaterial.rotation 있습니다.)

재료로 오프셋을 이동하려면 복제된 재료 20개와 ​​텍스처 1개가 필요합니다.

실제로 오프셋을 스프라이트로 이동하려면 1개의 재질과 1개의 텍스처가 필요합니다.

스프라이트 시트와 20개의 스프라이트를 상상해 보십시오. 현재 20개의 복제된 재료와 20개의 복제된 텍스처가 필요합니다.

옴, 나는이 사용 사례를 고려하지 않았습니다. 감사 해요!

이것저것 생각해볼게...

나는 텍스처에서 UV 변환이 아닌 것을 옹호합니다.

두 가지 이유가 있습니다. (1) 혼란스럽고, (2) 전파할 이벤트가 더 많고, (2) 낭비입니다.

혼란: 그 이유는 메인 맵에 대해 하나의 UV 변수만 있기 때문입니다. 그러나 텍스처 중 하나에 UV 변환이 있는 경우 이 UV 변환이 첫 번째 UV를 사용하는 모든 맵에 적용될 수 있다는 것이 혼란스럽습니다. 다른 텍스처에 변형이 있는지 여부에 관계없이 채널. 각 맵이 머티리얼에 고유한 UV 변환을 가질 수 있도록 허용했다면 텍스처와 관련된 UV 변환이 더 괜찮을 것입니다. 하지만 단편의 균일한 사용으로 인해 그렇게 하기 어렵습니다.

더 많은 이벤트 전파: Clara.io에서 만난 또 다른 문제는 텍스처 매개변수에 애니메이션을 적용하려고 할 때 발생하는 이벤트 전파입니다. 각 텍스처를 사용하여 사용 중인 각 머티리얼을 추적한 다음 해당 머티리얼에 더럽고 다시 계산해야 한다고 알려야 합니다. 이 작업을 수행하는 것이 불가능한 것은 아닙니다. 더 많은 작업이 필요할 뿐입니다.

낭비: 다른 문제는 3D 모델 또는 악의의 인스턴스가 여러 개 있고 모두 동일한 애니메이션 텍스처가 있는 경우입니다. 이 경우 텍스처 데이터 자체가 동일하더라도 다르게 애니메이션되도록 하기 위해 메모리에 텍스처의 고유한 복사본이 있어야 합니다. 그런 면에서 머티리얼에 UV 트랜스폼 데이터를 넣는 것과 비교하면 조금 낭비입니다.

따라서 머티리얼당 UV 변환이 하나만 허용된다면 머티리얼 자체에 적용하겠습니다. UV 오프셋, 재료 회전이 있는 Unity 5 모델을 따릅니다. 게임 개발자는 이미 이 접근 방식에 익숙합니다.

스프라이트는 머티리얼에서도 UV Transform으로 잘 처리된다고 생각합니다. 위의 3D 모델 사례와 매우 유사합니다.

Having only one uvTransform per material seems very very limiting.

여기에 전적으로 동의합니다. 이 기능이 없으면 매우 제한적입니다. 모든 오프셋이 함께 잠겨 있기 때문에 제공되지 않는 환상적인 효과가 여기에서 제공될 수 있습니다.

그러나 클론을 질식시키지 않고 어떻게 이 기능을 사용할 수 있습니까?

텍스처가 아닌 머티리얼에 값을 지정하는 것이 모든 텍스처가 일치하는 일반적인 사용 사례에 적합하다고 생각합니다.

여기에 전적으로 동의합니다. 이 기능이 없으면 매우 제한적입니다. 모든 오프셋이 함께 잠겨 있기 때문에 제공되지 않는 환상적인 효과가 여기에서 제공될 수 있습니다.

그러나 클론을 질식시키지 않고 어떻게 이 기능을 사용할 수 있습니까?

THREE.ShaderMaterial 또는 THREE.RawShaderMaterial 는 이 기능을 제공하며 현재 일반 재료와 함께 작동하지 않는 경우 이 경로를 사용해야 합니다.

더 펑키한 작업을 수행하는 경우 맵 반복 및 오프셋을 독립적으로 조정하는 것보다 더 펑키할 수 있으므로 어쨌든 이 방법으로 기울일 것입니다.

이것에 대해 +1입니다.

거대한 스프라이트 시트(아틀라스라고도 함)가 있고 여러 THREE.Sprite 인스턴스에서 텍스처를 재사용하려는 경우 매우 유용합니다.

이것에 대한 소식이 있습니까? 이 문제는 여전히 API의 눈에 띄는 결함입니다. 대부분의 지도 유형에는 사용되지 않는 오프셋/반복이 있으며, 이벤트 전파는 평면의 애니메이션 스프라이트와 같은 것을 필요한 것보다 느리거나 메모리를 무겁게 만듭니다.

애니메이션 지도의 유연성은 현재 시스템에 없습니다. 설정을 머티리얼에 묶으면 유연성이 줄어들 것이라는 주장이 계속 제기되고 있습니다. 이러한 유연성은 현재 시스템에 존재하지 않기 때문에 이 주장은 무의미합니다. 재료에 대해 전역적으로 오프셋/반복만 설정할 수 있으며 확산 맵(?)에서 가져옵니다. 이것은 사용 중인 대부분의 맵에 중복된 "오프셋"/"반복" 설정이 있는 훨씬 더 나쁜 문제로 이어지며 애니메이션을 위해 텍스처를 공유할 수 없을 때마다 복제를 만들어야 하므로 유연성이 크게 향상됩니다. 줄인. 각 텍스처/맵에 고유한 오프셋이 있을 것으로 예상하지만 이는 상황에 따라 불가능하며 대부분의 경우 일반/사양에 대해 오프셋을 동일한 것으로 설정하는 것이 짜증나기 때문에 실제로 한 세트의 UV 오프셋을 원합니다. /diffuse(고정 확산 맵 위의 스크롤링 노멀 맵은 셰이더 재질을 사용할 수 있는 틈새 용도입니다).

빌드 중인 실제 셰이더를 보면 텍스처 오프셋/반복이 재료에 묶여 있지만 이상하게도 제어할 수 없는 한 맵에서 복사되었습니다. 중복 없이 빠르고 우아하게 하려면 재료를 제어해야 합니다.

두 세계의 장점은 수많은 추가 플래그로 가능하지만 이러한 종류의 특정 상황에 대해 대신 셰이더 재료를 사용하도록 사용자에게 지시하는 것보다 이것이 더 나은 솔루션이라고 생각하지 않습니다.

이에 대한 해결책은 @sunag 의 NodeMaterial btw입니다.

또한 이것을 위해 내 +1을 추가하십시오! 스프라이트 시트 작업을 훨씬 더 멋지게 만들 것입니다.

:+1: 놀라운 사실을 발견했습니다. 반복되는 모든 스프라이트가 서로 애니메이션을 생성했기 때문에 게임에서 각 스프라이트에 대한 텍스처를 복제하기 시작해야 했습니다. 중복 스프라이트 데이터를 GPU에 로드한다는 의미인가요?

누구든지 이 문제에 대한 해결 방법이 있습니까? 텍스처 인터페이스를 무시하고 셰이더에서 유니폼을 직접 설정하여 UV 오프셋을 조작할 수 있습니까?

이에 대한 해결책은 @sunag 의 NodeMaterial btw입니다.

@bhouston , 링크를 제공할 수 있습니까? 해당 이름을 가진 @sunag 의 계정 아래에는 공개 저장소가 없습니다.

@rhys-vdw dev 브랜치에만 있습니다.

https://github.com/mrdoob/three.js/tree/dev/examples/js/nodes

새롭기 때문에 스프라이트에서 사용할 준비가 되었는지 확실하지 않지만 완전히 그래프 기반 셰이더 시스템이므로 텍스처 액세스를 임의로 수정할 수 있는 유연성을 제공합니다.

새롭기 때문에 스프라이트에서 사용할 준비가 되었는지 확실하지 않지만 완전히 그래프 기반 셰이더 시스템이므로 텍스처 액세스를 임의로 수정할 수 있는 유연성을 제공합니다.

@bhouston Node로 예제를 만들 수 있습니다. 보기 좋습니다.

THREE.SpriteMaterial 대해 다음과 같이 spritesheet 를 생성하기 위한 오프셋/스케일에 액세스할 수 있습니다.

var offsetX = frameX / mapWidth;
var scaleX = mapWidth / frameWidth;

sprite.material.map.offset.x = offsetX;
sprite.material.map.repeat.x = scaleX;

https://github.com/mrdoob/three.js/blob/master/src/renderers/webgl/plugins/SpritePlugin.js#L53

노드 기반 시스템은 수정 사항이 아닙니다... 여전히 API 문제를 해결하지 않습니다. 머티리얼 프로토타입에 오프셋/반복을 추가하고 렌더러가 텍스처 대신 이를 읽도록 하는 데 2초가 걸립니다. 내 프로젝트를 위해 이미 수행했지만 사실은 일반적인 작업을 수행하려고 할 때 이 문제에 직면하게 될 신규 사용자의 골칫거리를 방지하기 위해 공식적으로 변경되어야 하는 API의 명백한 결함으로 남아 있습니다.

...그래서 텍스처 액세스를 임의로 수정할 수 있는 유연성을 제공합니다.

tbh 그게 무슨 뜻인지 모르겠습니다. 재료별로 "오프셋" 및 "반복"에 대한 개별 세트 셰이더 유니폼을 애니메이션합니다.

THREE.SpriteMaterial에 대해 예를 들어 다음을 사용하여 스프라이트 시트를 만들기 위해 오프셋/스케일에 액세스할 수 있습니다.

@sunag , 아마도 문제가 명확하지 않을 수 있습니다. 공유한 코드는 해당 재질의 모든 인스턴스에서 공유하는 텍스처를 변경합니다. 이것은 텍스처를 공유하는 두 개의 머티리얼을 가질 수는 없지만 고유한 오프셋이 있음을 의미합니다. 예를 들어 두 개의 적 스프라이트가 다른 애니메이션 프레임을 표시합니다.

내 프로젝트를 위해 이미 수행했지만 사실은 일반적인 작업을 수행하려고 할 때 이 문제에 직면하게 될 신규 사용자의 골칫거리를 방지하기 위해 공식적으로 변경되어야 하는 API의 명백한 결함으로 남아 있습니다.

@QuaziKb 내 프로젝트에서 타겟팅할 수 있는 PR이 있습니까?

@WestLangley가 말했듯이 다음이 사실이라면 이 모든 것이 문제가 되지 않을 것입니다.

현재 접근 방식을 유지하는 경우 변경해야 할 한 가지는 텍스처가 복제될 때 공유 이미지를 GPU에 한 번만 전달해야 한다는 것입니다.

그 맞습니까?

@sunag , 아마도 문제가 명확하지 않을 수 있습니다. 공유한 코드는 해당 재질의 모든 인스턴스에서 공유하는 텍스처를 변경합니다. 이것은 텍스처를 공유하는 두 개의 머티리얼을 가질 수는 없지만 고유한 오프셋이 있음을 의미합니다. 예를 들어 두 개의 적 스프라이트가 다른 애니메이션 프레임을 표시합니다.

흠, 이 NodeMaterial 확실히 해결될 것이므로, 동일한 텍스처를 다른 머티리얼과 독립적인 uv 오프셋과 공유할 수 있을 것이며, 노드 기반 머티리얼이 제공할 수 있는 맞춤형 필터 및 기타 기능과 같은 이점을 얻을 수 있을 것입니다.

https://github.com/mrdoob/three.js/issues/7522

그러나 현재 누군가가 다음과 같이 uuid를 인스턴스화하려고 시도했습니다.

THREE.Texture.prototype.createInstance = function() {

    var inst = this.clone();

    inst.uuid = this.uuid;
    inst.version = this.version;

    return inst;

}

needsUpdate 사용하는 경우 모든 인스턴스 version 도 업데이트합니다.

예시:

var uniqueTextureOffset = map.createInstance();
var material = new THREE.SpriteMaterial( { map: uniqueTextureOffset } );

동일한 uuid 하고 version 는 GPU에서 texture 를 공유합니다.

https://github.com/mrdoob/three.js/blob/master/src/renderers/WebGLRenderer.js#L2832
https://github.com/mrdoob/three.js/blob/master/src/renderers/webgl/WebGLProperties.js#L11

나를 위해 그것은 잠정적인 해결책이지만. 나는 미래를 위해 NodeMaterial 를 믿습니다.

uv 변환을 재료로 옮길 수 있습니까?

두 세계의 최고는 어떻습니까? 재료에 새로운 uvOffset 및 uvRepeat 가 있는 재료에 플래그 overrideOffsetRepeat 를 추가합니다. 이렇게 하면 플래그가 false이면 이전 버전과 호환되며 이것이 기본값입니다. 그리고 그것이 사실이라면 머티리얼 오프셋/반복을 사용합니다. 나는 그 필요성이 강렬하고 널리 퍼져 있는 것처럼 보이기 때문에 이것을 지지할 것입니다. @WestLangley? @mrdoob?

(나는 앞으로 모든 일에 NodeMaterial을 사용하는 것을 정말로 지원하지만, 그것으로 전환하는 것은 고통스럽습니다.)

나는 여전히 이에 대한 해결책이 THREE.Image 를 만드는 것이라고 생각합니다. https://github.com/mrdoob/three.js/issues/5876#issuecomment -81189892

THREE.Image

@mrdoob , 할당된 각 Texture 가 Material 와 함께 복제된다는 것을 의미합니까?

@mrdoob 은 다음

나는 여전히 이것에 대한 해결책이 THREE.Image를 만드는 것이라고 생각합니다.

예, 작동할 것입니다. 하지만 이전 버전과의 호환성은 약간 떨어지지만(이제 모든 사람이 텍스처를 만들기 전에 이미지를 만들도록 요구하는 경우) 전체적인 디자인이 더 깔끔해집니다. 별도로 지정하지 않은 경우 텍스처별로 이미지가 자동으로 생성되도록 할 수 있습니다. 그러면 이전 버전과의 호환성을 얻을 수 있습니까? 그리고 까다로운 작업을 수행하려는 경우에만 Image를 직접 조작하면 됩니다.

이 솔루션에는 스프라이트 세트에 대해 두 개의 새 개체가 필요하다고 생각합니다. 각 스프라이트에 대해 하나의 텍스처와 하나의 머티리얼이 필요합니까? 각 스프라이트마다 새로운 머티리얼이 필요한 다른 접근 방식은 어디에 있습니까?

Unity는 재질당 반복/오프셋을 지원하지만 3DS Max, Maya, Softimage와 같은 고급 VFX 도구는 지원하지 않습니다. 이 도구에는 Bitmap 노드와 Texture 노드(비트맵 노드와 UV 매핑 모두 포함)만 있습니다. nod), @mrdoob 의 디자인과 유사합니다.

UE4도 @mrdoob 이 제안한 것과 유사하며 비트맵 로더인 "텍스처" 노드가 있고 다양한 유형의 UV 매핑을 수행하기 위한 일련의 UV 매핑 노드가 있습니다.

고급 도구는 텍스처에서 이미지/비트맵을 분할하고 다음 형식으로 별도의 UV 매핑 노드도 분할합니다.

 -> Bitmap
 -> UVMapping

현재 기본 StandardMaterial에서 많은 UVMapping 옵션을 허용하지 않습니다. 그러나 UE4, Maya, Softimage, 3DS Max에서 사용되는 다양한 유형의 UVMappings는 사용할 채널, 적용할 변환, 소스로 World Coordinates 사용 또는 Spherical, Cube, Planar 투영을 수행해야 하는지 여부입니다. 이러한 예측에 필요한 매개변수를 기반으로 합니다.

UE4에는 머티리얼 내에서 반복/오프셋을 허용하는 스프라이트 텍스처가 있습니다.

https://docs.unrealengine.com/latest/INT/Engine/Paper2D/Sprites/index.html

Maya, Softimage, 3DS Max 및 UE4는 @mrdoob 이 제안하는 것처럼 텍스처(및 UV 생성)에서 비트맵/이미지를 분리하지만 모두 이를 달성하기 위해 셰이더 그래프를 사용합니다. 셰이더 그래프가 없는 Unity3D는 오프셋/반복을 머티리얼 자체에 통합하는 도구입니다. 아마도 셰이더 그래프 노드로 제대로 분리하지 못하기 때문일 것입니다.

별도로 지정하지 않은 경우 텍스처별로 이미지가 자동으로 생성되도록 할 수 있습니다. 그러면 이전 버전과의 호환성을 얻을 수 있습니까? 그리고 까다로운 작업을 수행하려는 경우에만 Image를 직접 조작하면 됩니다.

바로 😊

언급하기에는 다소 애매할 수 있지만 가능한 한 빨리 PTEX를 통합하는 것이 좋습니다.
http://ptex.us/PtexFile.html
일반적인 프로젝션 등을 NodeTexture(?)로 변환/변환하는 방법이 있다면 더 강력하고 포괄적인 기본 수준 텍스처 매핑 시스템인 새로운 옵션이 있습니까? ...그렇다면 미리 생각해 보아야 할 사항일 것입니다.
[같은 요점으로 더 나아가:]
ptex의 개념은 실제로 2d 이미지가 아니라 uv 관계이므로 2d를 3d로 변환하는 방법에 대한 개념/도전 없이 복잡한 표면 주위에 페인트/스탬프/투영할 수 있습니다. 이는 수학적으로 비교하면 기껏해야 해킹입니다( 항상 기술적으로 파괴와 싸우고 있습니다).
나는 단지 ptex가 20년 이상 전에 더 합리적이고 우선 순위가 되어야 했으며 확장 또는 2급 성능으로 간주되어서는 안 된다는 점을 지적하지만 실제로 나에게는 그 반대입니다. 2d 이미지가 ptex의 항상 작동하는 하나의 진정한 기본 레벨 시스템으로 투영/스탬프되는 방법을 선언적으로 말하는 오래된 원래 방법이어야 합니다. 어쨌든 더 중앙 롤을 취하는 것이 최선이 아니라면 통합되어야한다는 아이디어를 시행하는 것입니다.
고상한 제안을 할 수 있는 기회를 주셔서 감사합니다. ptex가 사양에 맞게 만들어져서 너무 기뻤습니다. 나는 10년 이상 전에 그것에 대해 스스로 생각했지만 어린 시절에는 새로운 사양 등을 정의할 권한이 없었습니다. 돌이켜 보면 내가 여전히 유지하는 관찰자의 역할 대신 변화를 시도할 수 있었다는 것을 보았어야 했습니다. 그래서 여기에 오랜 잘못을 되돌리려는 시도가 있습니다.

Flux의 잠재적인 현재 방법에 대한 더 깊은 이해를 가진 사람이 THREEjs에서 작동하는 방식에 대해 적용 가능한 제안을 할 수 있다면 누군가가 새 스레드를 시작할 수 있습니다.
다시 한 번 들을 수 있는 기회를 주셔서 감사합니다.

@MasterJames 종류의 주제에서 벗어난 ... 새 스레드를 만드시겠습니까?

"텍스처"를 계속 사용할 수 있도록 이미지가 있더라도 실제로는 둘 이상의 uv 오프셋/반복을 지원하지 않기 때문에 모든 재료를 다시 작성해야 합니다. 분명히 이것은 변경될 수 있지만 아마도 중복 유니폼이 필요할 것이기 때문에 복잡성이 추가될 것입니다(예를 들어 노멀 맵이 확산에서 오프셋되도록 오프셋/반복 세트를 두 개 이상 원하는 빈도). 성능이 프리미엄인 웹의 경우 가장 일반적인 사용 사례는 모든 맵에 영향을 미치는 하나의 전역 오프셋/반복이 있는 경우이며, 이는 결국 머티리얼 아키텍처의 일부가 되기 때문에 머티리얼에 있는 것이 합리적입니다. 커스텀 셰이더 머티리얼은 엣지 케이스를 잘 처리할 수 있습니다.

@QuaziKb 네. 바로 NodeMaterial 태클하는 것입니다.

Texture 가 각 .clone() 에 대해 동일한 OpenGL 텍스처 인스턴스를 사용하는 경우가 아닙니까, 아니면 제가 뭔가를 놓치고 있는 건가요? 실제로 각 클론에 대해 다시 업로드합니까? 그렇다면 이것은 _매우_ 심각한 문제입니다.

@evrimoztamur , 매번 텍스처를 복사한다고 생각합니다. WebGL Inspector 를 사용하여 진행 상황을 확인할 수 있습니다.

@sunag 의 해결 방법을 포함하여 생각할 수 있는 모든 접근 방식을 시도했지만 아무 것도 작동하지 않았습니다. 결과가 나오지 않는 실험과 위의 논의를 바탕으로 다른 라이브러리에서 스프라이트 애니메이션을 처리하는 방법을 살펴보았습니다. 저는 Babylon.js의 Sprite 및 SpriteManager API가 제 특정 요구 사항을 충족하는 솔루션이라는 것을 알았습니다. 스프라이트 시트, 오프셋 및 반복, 애니메이션을 처리합니다. 아마도 이것은 THREE.js가 제공하는 것보다 더 높은 수준의 추상화일 수 있지만 참조로 볼 가치가 있습니다.

@rhys-vdw: 현재 프로젝트의 경우 MeshBasicMaterial의 나쁜 버전으로 끝났습니다.
https://gist.github.com/karimbeyrouti/790d2e1a8c0137b16bae

맵을 설정하면 오프셋/반복 유니폼이 자동으로 할당됩니다. 별도로 쉽게 설정할 수 있습니다. 그러면 당장은 텍스처를 복제할 필요가 없습니다. (r73으로 작업)

이 문제를 해결해야 하는 PR을 방금 제출했습니다. PR #8278

@WestLangley 는 다음

다음 맵이 동일한 오프셋/반복 값을 갖는다고 가정하는 것이 합리적이라고 생각합니다.

지도
스페큘러 맵
노멀맵
범프맵
알파맵
aoMap(미래)
글로스맵(미래)
변위 맵(미래)

항상은 아닙니다. 저는 현재 동일한 재료(아스팔트)의 맵과 범프 맵에 대해 서로 다른 반복 값을 사용하여 둘 다 다소 작은 타일로 타일링된다는 사실을 숨기고 있습니다. 그렇게하면 큰 텍스처를 생성하거나 가질 필요가 없습니다. 그것은 매우 편리합니다. :-)

편집: 글쎄, 그것이 내가 한 일이라고 생각했던 것입니다. 트릭은 아마도 무시되었을 것입니다. 그리고 셰이더에 노이즈를 추가하여 비슷한 결과를 얻을 수 있습니다. WestLangley의 Matrix3 데모는 훌륭합니다.

이것이 Sprite에서 UV가 다른 인스턴스의 문제를 해결한다고 생각합니다. 동일한 텍스처를 유지하면서 vertex 및 pixel shader 수정할 수 있습니다.

https://threejs.org/examples/#webgl_sprites_nodes

SpriteNodeMaterial 및 Mesh 를 공유 PlaneBufferGeometry 와 함께 사용합니다. 인터페이스는 Sprite 하지 않지만 작동합니다. 인터페이스를 더 친숙하게 만들기 위해 SpriteMesh 로 진화할 수 있습니다.

이 스레드는 TL;DR입니다. 하지만 방금 r68(이전 프로젝트, 예)에서 이 코드를 발견했습니다.

        // uv repeat and offset setting priorities
        //  1. color map
        //  2. specular map
        //  3. normal map
        //  4. bump map
        //  5. alpha map

        var uvScaleMap;

        if ( material.map ) {

            uvScaleMap = material.map;

        } else if ( material.specularMap ) {

            uvScaleMap = material.specularMap;

        } else if ( material.normalMap ) {

            uvScaleMap = material.normalMap;

        } else if ( material.bumpMap ) {

            uvScaleMap = material.bumpMap;

        } else if ( material.alphaMap ) {

            uvScaleMap = material.alphaMap;

        }

        if ( uvScaleMap !== undefined ) {

            var offset = uvScaleMap.offset;
            var repeat = uvScaleMap.repeat;

            uniforms.offsetRepeat.value.set( offset.x, offset.y, repeat.x, repeat.y );

        }

그래서, 예...

여기에서 제안한 것과 같이 라이브러리에 대한 근본적인 변경을 제안하려면 해당 변경에 대한 명확하고 설득력 있는 주장을 제공해야 합니다.

나는 디퓨즈 맵과 노멀 맵에서 다른 반복을 설정하려고 했고 작동하지 않았기 때문에 머리카락을 뽑았습니다. API는 이 설정을 텍스처에 배치하기 때문에 그렇게 할 수 있다고 생각했습니다. 네, 설득력 있는 논쟁을 위해 제 머리카락을 아껴두는 것은 어떻습니까? 이 티켓은 여전히 ​​열려 있고 3js는 여전히 텍스처에 대해 이 설정을 가지고 있으며 텍스처 중 하나에 대해서만 존중됩니다 = 이것은 사실상 이미 재료별 설정입니다.

이것을 속한 곳으로 옮기지 않으려면 적어도 문서에는 영향이 없다고 말합니까?

@sunag 홍보용:
https://github.com/mrdoob/three.js/pull/11531

내가 만난 한 가지 문제 :
https://jsfiddle.net/f0j2v3s8/

SpriteNodeMaterial 투명도가 손실된 것 같습니다. 이 예제를 작동시키는 데 사용할 수 있는 혼합 조합이 없습니다.

어떤 아이디어?

@karimbeyrouti 는 다음

맵을 설정하면 오프셋/반복 유니폼이 자동으로 할당됩니다. 별도로 쉽게 설정할 수 있습니다. 그러면 당장은 텍스처를 복제할 필요가 없습니다. (r73으로 작업)

uniforms.offsetRepeat 가 uniforms.uvTransform (r88)로 변경되었기 때문에 이것이 더 이상 사용되지 않는다고 생각합니다.

'여러 Object3D 인스턴스가 있는 텍스처 아틀라스 재사용' 사용 사례와 관련하여 간단한 둘러보기를 제안합니다.

1. 아틀라스 json 객체에 UV 데이터(오프셋, 반복)를 저장합니다.
2. Object3D의 onBeforeRender\onAfterRender 함수 쌍을 연결합니다.
3. 렌더링 전 콜백에서 atlas json 객체에서 UV 데이터를 로드하고 material.map으로 설정합니다.
4. 렌더링 후 콜백에서 다시 재설정하십시오.

결과:

1. 하나의 텍스처와 여러 개체가 공유하는 하나의 재질, 복제가 필요하지 않으며 info.memory.textures 카운터가 증가하지 않습니다.
2. 그러나 여전히 다른 모든 맵(노멀, o, 변위...)은 동일한 UV 변환을 준수해야 합니다.