Three.js: 비차단 자산 로더

Promise+worker+incremental 기반 로더를 가질 수 있습니다(두 포인트의 혼합과 약간 비슷함)

소스 URL을 작업자 스크립트에 전달 하고 리소스를 가져오고 필요한 버퍼, 구조체, ImageBitmaps와 함께

GPU에 데이터를 업로드하는 것은 상관없이 차단되지만 display.rAF를 통해 다른 프레임에 명령을 배포하는 대기열을 만들 수 있습니다. 명령은 프레임당 한 번에 하나씩 실행되거나 작업의 평균 시간을 계산하고 현재 프레임 예산에서 실행하기에 "안전한" 만큼 실행할 수 있습니다(requestIdleCallback과 유사한 것이 좋지만 널리 지원되지는 않습니다. , WebVR 세션에서 문제가 있음). 또한 bufferSubData, texSubImage2D 등을 사용하여 개선할 수 있습니다.

작업자 및 전송 가능한 개체에 대한 지원은 현재 특히 WebVR 가능 브라우저에서 매우 견고합니다.

안녕하세요. 이 맥락에서 여러분이 관심을 가질 만한 프로토타입이 있습니다. 다음 분기를 참조하십시오.
https://github.com/kaisalmen/WWOBJLoader/tree/Commons
여기에서 의 메시 프로비저닝 부분이 WWOBJLoader2 완전히 분리되었습니다.
https://github.com/kaisalmen/WWOBJLoader/blob/Commons/src/loaders/WWLoaderCommons.js

WWLoaderCommons 사용하면 다른 메시 공급자(파일 형식 로더)를 쉽게 구현할 수 있습니다. 기본적으로 웹 작업자 구현이 메인 스레드에 메시 데이터를 다시 제공하고 이를 장면에 처리/통합하는 방법을 정의합니다. 기술 데모 역할을 하는 임의의 삼각형 정크 공급자 😉를 참조하세요.
https://github.com/kaisalmen/WWOBJLoader/tree/Commons/test/meshspray
https://kaisalmen.de/proto/test/meshspray/main.src.html

현재 구현에서도 WWOBJLoader2 는 전달 가능한 객체(ArrayBuffers/ByteBuffers)에 의존하여 작업자에서 메인 스레드로 Mesh 대한 원시 BufferedGeometry 데이터를 제공합니다. 제공된 ByteBuffers에서 시간적으로 Mesh 생성은 무시할 수 있습니다. 그러나 더 큰 메쉬가 장면에 통합될 때마다 렌더링이 중단됩니다(데이터 복사, 장면 그래프 조정 ... !?). 이것은 항상 출처와 무관한 경우입니다(제가 틀렸다면 정정해 주십시오).
WWOBJLoader2의 "스트림" 모드는 이러한 지연을 완화하지만 OBJ 모델의 단일 메쉬 조각의 무게가 50만 정점이면 렌더링이 더 오랜 시간 동안 일시 중지됩니다.

내가 맞춤식 지점에서 정확히 무엇을 했는지 그리고 그 이유를 자세히 설명하기 위해 새 문제를 열었습니다.
https://github.com/kaisalmen/WWOBJLoader/issues/11
이 문제는 아직 스텁이며 자세한 내용은 곧 나올 것입니다.

몇 가지 수치를 제공하기 위해 2048x2048 텍스처가 있는 13MB 모델을 로드하는 https://threejs.org/examples/webgl_loader_gltf2.html 의 성능 프로필이

이 경우 메인 스레드를 차단하는 주요 작업은 텍스처를 GPU에 업로드하는 것이며, 내가 아는 한 WW에서는 할 수 없습니다. 로더가 텍스처를 점진적으로 추가하거나 three.js가 내부적으로 처리해야 합니다.

호기심을 위해 메인 스레드를 차단하는 마지막 청크는 환경 큐브 맵의 추가입니다.

react-vr의 주요 목표는 벽시계 시간 측면에서 가장 최적의 로더를 가질 필요는 없지만 새로운 콘텐츠를 로드할 때 갑작스럽고 예상치 못한 프레임 아웃이 발생하지 않도록 하는 것입니다. 이를 최소화하기 위해 우리가 할 수 있는 모든 것은 특히 VR을 제외한 모든 사람에게 유익합니다.

텍스처는 확실히 문제이며 분명한 첫 번째 단계는 선택적으로 증분적으로 로드하는 것입니다(큰 텍스처의 경우 한 번에 일련의 라인). 업로드가 클라이언트 프로그램에 대해 숨겨져 있기 때문에 관리하기 어려울 것이지만 three.js의 부담을 덜기 위해 webgl 렌더러에 더 공개적으로 노출되는 것이 좋습니다.

gltf 구문 분석의 경우 일반적으로 테스트에서 500ms의 차단이 표시됩니다. 이는 중요하며 모든 로더(복제 가능해야 함)에 대한 점진적 접근 방식을 훨씬 선호합니다.

React VR의 전제는 웹 스타일로 구동되는 쉬운 동적 콘텐츠를 장려하여 더 많은 개발자를 격려하는 것이며, 이는 동적 처리 개선에 더 중점을 둘 것입니다. 대부분의 경우 사용자가 만든 응용 프로그램을 시작할 때 어떤 자산이 필요한지 모릅니다.

@kaisalmen 링크 주셔서 감사합니다

Elation Engine/JanusWeb에서 우리는 실제로 작업자 스레드 풀을 사용하여 모든 모델 구문 분석을 수행합니다. 이는 꽤 잘 작동합니다. 노동자가 각 모델 완성 로딩이되면, 우리는 사용하여 직렬화 object.toJSON() 으로 메인 스레드로 보내 postMessage() , 다음 사용하여로드 ObjectLoader.parse() . 이것은 로더 코드의 대부분의 차단 부분을 제거합니다. ObjectLoader.parse() 에 여전히 약간의 시간이 소요되어 아마도 최적화될 수 있지만 전반적인 상호 작용 및 로드 속도가 크게 향상됩니다. 작업자 풀을 사용하기 때문에 여러 모델을 병렬로 구문 분석할 수도 있습니다. 이는 복잡한 장면에서 큰 이점입니다.

텍스처 측면에서, 네, three.js의 텍스처 업로드 기능에 약간의 변경이 필요하다고 생각합니다. texSubImage2D 사용하는 청크 업로더가 이상적이며 위에서 언급한 것처럼 여러 프레임에 걸쳐 큰 텍스처를 부분적으로 업데이트할 수 있습니다.

Three.js를 기반으로 사용하는 많은 프로젝트에 도움이 되기 때문에 이 변경 사항에 대해 협력하게 되어 매우 기쁩니다.

texSubImage2D 를 사용하는 것이 좋습니다.
그러나 WebGL이 텍스처를 비동기적으로 업로드하지 않는 이유이기도 합니다.
OpenGL 및 기타 라이브러리에는 동일한 제한이 있습니까?

그리고 제가 생각하는 또 다른 것은 GLSL 컴파일입니다.
프레임이 떨어질까요? 아니면 충분히 빨라서 신경 쓸 필요가 없습니까?

예, 이것은 네이티브 OpenGL에서도 문제입니다. 셰이더 컴파일 및 이미지 데이터 업로드는 동기/차단 작업입니다. 이것이 대부분의 게임 엔진이 레벨을 시작하기 전에 모든 콘텐츠를 미리 로드하도록 권장하거나 심지어 강제하는 이유입니다. 일반적으로 하드 드라이브에서 새 리소스를 로드하기에는 성능 저하가 너무 큰 것으로 간주되며 여기서는 비동기식으로 수행하려고 합니다. 인터넷을 통해...우리는 실제로 대부분의 게임 개발자보다 더 어려운 문제를 가지고 있으며, 새로운 콘텐츠를 즉석에서 스트리밍할 수 있으려면 더 고급 기술을 사용해야 합니다.

앞으로 새로운 ImageBitmap API를 사용하면 텍스처 업로드가 덜 문제가 될 것입니다. https://youtu.be/wkDd-x0EkFU?t=82 를 참조

BTW: @spite 덕분에 이미 프로젝트에 실험적인 ImageBitmapLoader 가 있습니다.

@Mugen87 실제로 Elation Engine/JanusWeb에서 ImageBitmap으로 모든 텍스처 로드를 수행하고 있습니다. 확실히 도움이 되고 Three.js 코어에 통합할 가치가 있지만 WebGL에서 텍스처 사용과 관련된 두 가지 주요 비용이 있습니다 - 이미지 디코딩 시간 , 및 이미지 업로드 시간 - ImageBitmap은 첫 번째에만 도움이 됩니다.

이것은 내 테스트에서 CPU를 차단하는 시간을 약 50% 단축하지만 GPU, 특히 2048x2048 이상에 큰 텍스처를 업로드하는 데 1초 또는 그 이상이 쉽게 걸릴 수 있습니다.

@jbaicoianu 가 제안하는 것을 시도하는 것이 편리할 것입니다. 어쨌든 주 스레드 대안을 선택하면 setTimeout 대신 requestIdleCallback 과 완벽하게 일치하는 것 같습니다.

나는 여러분 모두에게 동의합니다. 작업자의 모든 것을 로드 및 구문 분석하고, 필요한 객체를 메인 스레드에서 다시 생성하고(매우 비용이 많이 드는 경우 여러 단계로 수행할 수 있음) 렌더러에 증분 로드를 포함하는 접근 방식을 믿습니다.
MVP의 경우 maxTexturesUploadPerFrame(기본적으로 무한)을 정의할 수 있으며 렌더는 해당 숫자에 따라 풀에서 로드를 처리합니다.
다음 반복에서는 @spite가 언급한 대로 논리를 추가하여 평균을 측정하고 차단하기 전에 안전한 범위 시간에 따라 자동으로 업로드할 수 있습니다. 이것은 처음에 각 텍스처에 대해 단위로 수행할 수 있지만 더 큰 텍스처에 대한 청크를 점진적으로 업로드하도록 개선할 수 있습니다.

requestIdleCallback은 좋겠지만 널리 지원되지 않고 WebVR 세션에서 문제가 됩니다.

@spite 나는 당신의 문장이 궁금합니다. 문제가 무엇을 의미합니까?

texSubImage2D를 사용하여 텍스처를 점진적으로 업데이트하는 THREE.UpdatableTexture가 있지만 three.js를 약간 조정해야 합니다. 아이디어는 지원을 추가하기 위해 PR을 준비하는 것입니다.

requestIdleCallback(rIC) 관련:

• 첫째, 크롬과 파이어폭스에서 지원되며, 폴리필이 쉽게 가능하지만 폴리필 버전은 목적을 약간 무너뜨릴 수 있습니다.

• 두 번째: 프레젠테이션할 때 window.rAF 대신 vrDisplay.requestAnimationFrame(rAF)을 호출해야 하는 것과 같은 방식으로, 이 crbug 에서 논의된 바와 같이 rIC에도 동일하게 적용됩니다. 즉, 로더는 항상 현재 활성 디스플레이를 인식해야 하며, 그렇지 않으면 표시되는 내용에 따라 실행이 중지됩니다. 그것은 매우 복잡하지 않으며 로더의 배선에 더 많은 복잡성을 추가합니다(이상적으로는 프리젠테이션 상태와 독립적으로 작업을 수행해야 함). 또 다른 옵션은 현재 디스플레이를 공유하기 위해 메인 스레드에서 증분 작업을 실행하는 부분을 threejs에 두는 것입니다. threejs의 VR에 대한 최신 변경 사항을 사용하면 이제 훨씬 더 쉽게 할 수 있다고 생각합니다.

또 다른 고려 사항: texSubImage2D(256x256 또는 512x512)를 사용하여 여러 단계로 하나의 큰 텍스처를 업로드할 수 있으려면 오프셋 및 클리핑 기능이 있는 WebGL2 컨텍스트가 필요합니다. 그렇지 않으면 이미지를 업로드하기 전에 기본적으로 클라이언트 측에 타일링된 캔버스를 통해 미리 잘라야 합니다.

@spite 좋은 점, 프레젠테이션할 때 rIC가 호출되지 않는 것에 대해 생각하지 않았습니다. 처음에는 display.rIC가 필요하다고 생각했지만 .rIC는 창에 연결되고 창이나 디스플레이가 표시될 때 호출되어야 한다고 생각합니다. 둘 다 유휴.
나는 내가 webvr 사양 토론이 관련 것도 어쩌면 자세한 정보를 가지고 있지만 확실히 우리가 해결해야하는 문제입니다 @kearwood을 듣지 않았다 생각합니다.

UpdatableTexture PR을 기대합니다! :) 그것이 단지 WIP일지라도 우리는 토론의 일부를 그곳으로 옮길 수 있습니다.

아마도 로더가 이렇게 될 수 있습니다 ...

THREE.MyLoader = ( function () {

    // parse file and output js object
    function parser( text ) {
        return { 'vertices': new Float32Array() }
    }

    // convert js object to THREE objects.
    function builder( data ) {
        var geometry = new THREE.BufferGeometry();
        geometry.addAttribute( new THREE.BufferAttribute( data.vertices, 3 );
        return geometry;
    }

    function MyLoader( manager ) {}
    MyLoader.prototype = {
        constructor: MyLoader,
        load: function ( url, onLoad, onProgress, onError  ) {},
        parse: function ( text ) {
            return builder( parser( text ) );
        },
        parseAsync: function ( text, onParse ) {
            var code = parser.toString() + '\nonmessage = function ( e ) { postMessage( parser( e.data ) ); }';
            var blob = new Blob( [ code ], { type: 'text/plain' } );
            var worker = new Worker( window.URL.createObjectURL( blob ) );
            worker.addEventListener( 'message', function ( e ) {
                onParse( builder( e.data ) );
            } );
            worker.postMessage( text );
        }
    }
} )();

THREE.UpdatableTexture의 첫 번째 제안 릴리스

이상적으로는 THREE.Texture의 일부여야 하지만 먼저 이 접근 방식을 살펴보겠습니다.

@mrdoob 작업자에게 정확히 동일한 코드를 파이프로 연결하는 것의 장점을 알 수 있습니다. 정말 잘못된 것 같습니다 😄. 나는 스크립트를 직렬화하고, 얼룩지고, 재평가하는 것이 어떤 영향을 미칠지 궁금합니다. 너무 끔찍한 것은 아니지만 브라우저가 이러한 단점에 최적화되어 있다고 생각하지 않습니다 🙃

또한 이상적으로는 리소스 자체의 가져오기가 작업자에서 발생합니다. 그리고 브라우저의 parser() 메서드는 three.js 자체의 importScripts가 필요하다고 생각합니다.

그러나 동기화/비동기 로더를 정의하기 위한 단일 포인트는 킥애스입니다!

@mrdoob builder 함수는 모든 로더에 완전히 일반적이고 공통적일 수 있습니다(WIP: https://github.com/kaisalmen/WWOBJLoader/blob/Commons/src/loaders/support/WWMeshProvider.js#LL215- LL367, 업데이트: 아직 함수에서 격리되지 않음). 입력 데이터가 THREE 객체에 대한 참조 없이 순수한 js 객체로 제한되는 경우(이것이 바로 여러분이 염두에 두고 있는 것입니다. 맞죠?) 작업자에서 가져올 필요 없이 직렬화 가능한 작업자 코드를 빌드할 수 있습니다( WWOBJLoader ). 이것은 Geometry에서는 쉽지만 Material/Shaders(파일에 정의된 경우)는 빌더에서만 생성될 수 있으며 이전에는 parser 의해 JSON으로만 설명될 수 있습니다.
작업자는 모든 새로운 메시와 완료 신호를 보내야 한다고 생각합니다. 다음과 같이 변경될 수 있습니다.

// parse file and output js object
function parser( text, onMeshLoaded, onComplete ) {
    ....
}

parse: function ( text ) {
    var node = new THREE.Object3d();
    var onMeshLoaded = function ( data ) {
        node.add( builder( data ) );
    };

    // onComplete as second callbackonly provided in async case
    parser( text, onMeshLoaded ) );
    return node;
},

작업자 빌더 유틸리티는 파서를 그대로 사용하는 아이디어와 모순되지 않는 일부 일반 통신 프로토콜이 도움이 되지만 일부 래핑이 필요하다고 생각합니다. WWOBJLoader 진화의 현재 상태: https://github.com/kaisalmen/WWOBJLoader/blob/Commons/src/loaders/support/WWMeshProvider.js#LL40 -LL133 반면 프런트 엔드 호출은 report_progress, meshData 및 완료입니다.

업데이트2:

• Parser가 stateless해야 한다고 생각하십니까? builder 에는 괜찮지만 parser 의 동작을 조정하기 위해 일부 매개변수를 설정할 수 있는 것이 합리적일 수 있습니다. 이것은 또한 구성 매개변수가 구문 분석과 독립적으로 작업자에게 전송 가능해야 함을 의미합니다.
• 일반 구성 개체를 먹는 실행 기능과 같은 것이 있으면 멋질 것입니다. 그런 다음 일반 디렉터는 모든 로더에 지침을 제공할 수 있습니다(이는 현재 WWOBJLoader , btw의 맞춤형 Commons 분기에서 작동 중입니다).
• 진행 중인 개발: WWOBJLoader2 이제 OBJLoader 확장하고 구문 분석을 재정의합니다. 따라서 우리는 두 개의 구문 분석 캡을 가지고 있지만 클래스는 다릅니다. 제안에 가까워졌지만 아직까지는 이르지 못했습니다. 일부 파서 코드를 통합해야 하며 결국 두 클래스를 융합해야 합니다.

지금은 그것뿐입니다. 피드백 환영 😄

@mrdoob 로더의 코드에서 작업자를 즉석에서 구성하는 아이디어가 마음에

기본 스레드로 다시 전달할 때 TypedArray를 전송 가능한 것으로 표시하는 것이 쉽기 때문에 작업자 간에 전달하기 위해 축소된 전송 형식을 사용하는 접근 방식을 좋아합니다. 현재 접근 방식에서는 작업자에서 .toJSON() 메서드를 사용하고 있지만 정점, UV 등에 대한 JS 배열을 살펴보고 적절한 TypedArray 유형으로 교체하고 호출할 때 전송 가능으로 표시합니다. 포스트 메시지. 이것은 작업자의 처리/메모리 사용량을 조금 더 희생시키면서 기본 스레드에서 구문 분석/메모리 사용량을 조금 더 가볍게 만듭니다. 새로운 전송 형식을 제안하거나 .toJSON() 를 수정하여 JS 배열 대신 TypedArray를 선택적으로 제공합니다.

이 단순화된 접근 방식의 두 가지 단점은 다음과 같습니다.

• 기존 모델 로더를 다시 작성해야 합니다. 많은 로더가 내장된 3개의 네임스페이스 클래스와 함수를 사용하여 작업을 수행하므로 아마도 최소한의 three.js 코드 세트를 가져와야 할 것입니다. 작업자의 경우 이것이 까다로워집니다.
• 전송 형식은 다른 개체 유형(Mesh, SkinnedMesh, Light, Camera, Object3D, Line 등)뿐만 아니라 개체 계층 구조를 적절하게 캡처해야 합니다.

@spite "또한 이상적으로는 리소스 자체를 작업자에서 가져오는 것이 좋습니다." - 이것은 내가 Elation Engine을 위한 작업자 기반 자산 로더를 처음 구현했을 때의 생각이었습니다. - 저는 4명 또는 8명의 작업자 풀을 가지고 있었고 그들이 사용 가능해지면 작업을 전달한 다음 작업자가 파일을 가져와 구문 분석합니다. 그것들을 메인 스레드로 돌려보냅니다. 그러나 실제로 이것이 의미하는 바는 다운로드가 구문 분석을 차단하고 한 번에 모두 요청하면 파이프라이닝 등에서 얻을 수 있는 이점을 잃게 된다는 것입니다.

이를 깨닫고 모든 자산 다운로드를 관리하기 위해 다른 계층을 추가한 다음 자산 다운로더가 이벤트를 발생시켜 자산을 사용할 수 있게 되면 알려줍니다. 그런 다음 이진 파일 데이터의 transferrable을 사용하여 작업자 풀로 전달하여 작업자에게 효율적으로 가져옵니다. 이 변경으로 인해 다운로드는 모두 기본 스레드에 있더라도 더 빠르게 발생하고 파서는 데이터를 기다리며 엄지손가락을 만지작거리지 않고 처리 시 전체 보어를 실행하게 됩니다. 전반적으로 이것은 자산 로드 속도 측면에서 우리가 만든 최고의 최적화 중 하나로 밝혀졌습니다.

텍스처 로딩 주제에 대해 FramebufferTextureLoader 와 함께 제공되는 새로운 FramebufferTexture 클래스의 개념 증명을 구축했습니다. 이 텍스처 유형은 WebGLRenderTarget 확장하며 해당 로더는 주어진 크기의 청크 타일에 텍스처를 로드하고 requestIdleCallback() 사용하여 프레임 버퍼로 구성하도록 구성할 수 있습니다.

https://baicoianu.com/~bai/three.js/examples/webgl_texture_framebuffer.html

이 예에서는 이미지 크기와 타일 크기를 선택하기만 하면 로드 프로세스가 시작됩니다. 먼저 텍스처를 순수한 빨간색으로 초기화합니다. 이미지 다운로드를 시작하고(약 10MB이므로 약간만 제공) 이미지가 완료되면 배경을 파란색으로 변경합니다. 이 시점에서 파일을 구문 분석하기 위해 createImageBitmap() 로 이미지를 구문 분석하기 시작하고, 완료되면 이미지를 타일로 효율적으로 분할하는 createImageBitmap() 대한 추가 호출을 포함하는 여러 유휴 콜백을 설정합니다. . 이러한 타일은 여러 프레임에 걸쳐 프레임 버퍼에 렌더링되며 한 번에 모두 수행하는 것보다 프레임 시간에 미치는 영향이 훨씬 적습니다.

참고 - FireFox는 현재 createImageBitmap 의 모든 버전을 구현하지 않는 것으로 보이며 현재 타일로 분할하려고 할 때 오류가 발생합니다. 결과적으로 이 데모는 현재 Chrome에서만 작동합니다. FireFox의 createImageBitmap 지원 로드맵에 대한 참조가 있습니까?

몇 가지 정리가 필요합니다. 이 프로토타입은 약간 지저분하지만 결과에 매우 만족하며 브라우저 간 문제(캔버스 대체 등)를 해결할 수 있는 방법을 알게 되면 이것을 JanusWeb의 모든 텍스처에 대한 기본값으로 사용하는 것을 고려합니다. 페이드 인 효과도 약간 깔끔하며, 축소된 버전을 먼저 화려하게 만든 다음 더 높은 디테일의 타일을 점진적으로 로드할 수도 있습니다.

표준 텍스처 참조가 아닌 장면의 모든 텍스처에 대해 프레임 버퍼를 사용하는 것이 왜 나쁜 생각일 수 있는지 누구나 생각할 수 있는 성능 또는 기능 관련 이유가 있습니까? 나는 max에 대해 아무것도 찾을 수 없었습니다. 장면당 프레임 버퍼, 일단 프레임 버퍼가 설정되면 알 수 있는 한, 렌더링하지 않으면 다른 텍스처 참조와 동일하지만 다음과 같은 분명한 것을 놓치고 있는 것 같은 느낌이 듭니다. 왜 이것이 정말 나쁜 생각이 될 것입니까? :)

@jbaicoianu re: firefox의 createImageBitmap, 그 이유는 사전 매개변수를 지원하지 않으므로 이미지 방향이나 색 공간 변환을 지원하지 않기 때문입니다. 그것은 API의 대부분의 응용 프로그램을 꽤 쓸모 없게 만듭니다. 문제와 관련된 두 가지 버그를 제출했습니다. https://bugzilla.mozilla.org/show_bug.cgi?id=1367251 및 https://bugzilla.mozilla.org/show_bug.cgi?id=1335594

@spite 그것도 내가 생각한 것입니다. 옵션 사전을 지원하지 않는 것에 대한이 버그를 보았지만이 경우에는 그것을 사용하지도 않고 x, y, w, h 옵션을 사용하려고합니다. 내가 얻는 특정 오류는 다음과 같습니다.

Argument 4 of Window.createImageBitmap '1024' is not a valid value for enumeration ImageBitmapFormat.

ImageBitmapFormat 를 인수로 사용하는 사양에 createImageBitmap 버전이 표시되지 않기 때문에 혼란스럽습니다.

표준 텍스처 참조가 아닌 장면의 모든 텍스처에 대해 프레임 버퍼를 사용하는 것이 왜 나쁜 생각일 수 있는지 누구나 생각할 수 있는 성능 또는 기능 관련 이유가 있습니까? 나는 max에 대해 아무것도 찾을 수 없었습니다. 장면당 프레임 버퍼, 일단 프레임 버퍼가 설정되면 알 수 있는 한, 렌더링하지 않으면 다른 텍스처 참조와 동일하지만 다음과 같은 분명한 것을 놓치고 있는 것 같은 느낌이 듭니다. 왜 이것이 정말 나쁜 생각이 될 것입니까? :)

@jbaicoianu THREE.WebGLRenderTarget 는 프레임 버퍼, 텍스처 및 렌더 버퍼를 유지합니다. 텍스처가 어셈블되면 프레임 버퍼와 렌더 버퍼를 삭제하고 텍스처만 유지할 수 있습니다. 다음과 같은 작업이 수행되어야 합니다(테스트되지 않음).

texture = target.texture;
target.texture = null; // so the webgl texture is not deleted by dispose()
target.dispose();

@wrr 좋은 정보 감사합니다. 나는 확실히 이것에 대해서도 메모리 효율성에 대해 패스해야합니다. 매개 변수를 충분히 변경하면 필연적으로 어느 시점에서 충돌이 발생하므로 아직 수행하지 않은 정리가 있다는 것을 알고 있습니다. 이와 같은 다른 힌트는 대단히 감사하겠습니다.

@mrdoob 과 @jbaicoianu 저도 그 아이디어가 마음에
OBJLoader 및 WWOBJLoader 및 모든 예제( code )의 코드(재작업된 초기화, 작업자 지침 개체, 쓰레기 다중 콜백 처리 대체, 공통 리소스 설명 등)를 정리했습니다. 이제 두 로더를 결합할 준비가 되었습니다. 그들은 내 여가 시간에 따라 다음 주에 당신의 청사진에 따라 될 것입니다.
지시된 WWOBJLoader2 테스트:
https://kaisalmen.de/proto/test/wwparallels/main.src.html
일반 WorkerSupport 의 직접 사용자:
https://kaisalmen.de/proto/test/meshspray/main.src.html
큰 압축 OBJ 파일 테스트:
https://kaisalmen.de/proto/test/wwobjloader2stage/main.src.html

사용 가능한 경우 위의 예제를 최신 코드로 업데이트하고 알려 드리겠습니다.
업데이트 2017-07-30: OBJLoader2 및 WWOBJLoader2 이제 동일한 파서를 사용합니다. 그들은 데이터를 공통 빌더 함수에 직접 또는 작업자로부터 전달합니다.
업데이트 2017-07-31: WWOBJLoader2 가 사라졌습니다. OBJLoader2 는 parse 및 parseAsync , load 및 run ( LoaderDirector 또는 수동으로 공급)

업데이트 2017-08-09:
업데이트를 새 게시물로 옮겼습니다.

OBJLoader2 는 OBJLoader 와 다시 호환되는 서명 및 동작입니다(진화 중에 이 문제를 해결했습니다). OBJLoader2 는 parseAsync 및 load 를 제공합니다 useAsync 플래그도 추가됩니다. 이제 V2.0.0-베타라고 부를 준비가 된 것 같습니다. 여기에서 현재 개발 상태를 확인할 수 있습니다.
https://github.com/kaisalmen/WWOBJLoader/tree/V2.0.0-Beta/src/loaders

유틸리티 및 필수 지원 도구 역할을 하는 LoaderSupport 클래스(OBJ와 무관)를 추출했습니다. 잠재적인 다른 작업자 기반 로더에 재사용할 수 있습니다. 아래의 모든 코드에서 OBJLoader2 의 종속성을 강조하기 위해 THREE.LoaderSupport 네임스페이스 아래에 넣었습니다.

• Builder : 일반 메쉬 빌딩용
• WorkerDirector : 리플렉션을 통해 로더를 생성하고 구성된 작업자 수로 대기열에서 PrepData 를 처리합니다. 로더를 완전히 자동화하는 데 사용됨(MeshSpray 및 Parallels 데모)
• WorkerSupport : 기존 코드에서 작업자를 생성하고 간단한 통신 프로토콜을 설정하는 유틸리티 클래스
• PrepData + ResourceDescriptor : 자동화를 위해 사용하는 설명 또는 예제 간의 통일된 설명을 위해 사용하는 설명
• Commons : 로더에 대한 가능한 기본 클래스(공통 매개변수 번들)
• Callbacks : (onProgress, onMeshAlter, onLoad) 자동화 및 방향 지정에 사용되며 LoadedMeshUserOverride 는 onMeshAlter 에서 정보를 다시 제공하는 데 사용됩니다(아래 objloader2 테스트의 법선 추가).
• Validator : null/정의되지 않은 변수 검사

@mrdoob @jbaicoianu OBJLoader2 이제 제안된 대로 파서를 래핑합니다(실행을 위해 PrepData 에 의해 전역적으로 설정되거나 수신된 매개변수로 구성됨). Builder 는 모든 단일 원시 메시를 수신하고 파서는 기본 노드를 반환하지만 그 외에는 청사진과 일치합니다.
OBJLoader2 에는 필요하지 않은 파서 직렬화를 위한 도우미 코드가 있습니다.
buildMeshes 함수에 대한 계약/매개변수 개체가 여전히 OBJ 로드의 영향을 많이 받으므로 빌더를 정리해야 하며 따라서 여전히 건설 중인 것으로 간주됩니다.

코드는 약간의 연마가 필요하지만 피드백, 토론, 비판 등을 위한 준비가 되어 있습니다... 😄

예 및 테스트

실행 및 로드를 사용하는 OBJ 로더:
https://kaisalmen.de/proto/test/objloader2/main.src.html
run async 및 parseAsync를 사용하는 OBJ 로더:
https://kaisalmen.de/proto/test/wwobjloader2/main.src.html
비동기 OBJLoader2 실행의 지시된 사용:
https://kaisalmen.de/proto/test/wwparallels/main.src.html
일반 WorkerSupport의 지시된 사용:
https://kaisalmen.de/proto/test/meshspray/main.src.html
큰 압축 OBJ 파일 테스트:
https://kaisalmen.de/proto/test/wwobjloader2stage/main.src.html

좋아 보여! OBJLoader 의 이러한 변경 사항을 알고 계십니까? #11871 565c6fd0f3d9b146b9434e5fccfa2345a90a3842

예, 이것을 이식해야 합니다. 재현 가능한 성능 측정을 제안했습니다. 이번 주말에 둘 다 작업을 시작합니다. 언제 r87을 출시할 계획입니까? N-gon 지원은 날짜에 따라 만들 수 있습니다.

@mrdoob 및 짜잔: https://github.com/mrdoob/three.js/pull/11928 n-gon 지원 😄

상태 업데이트( 코드 ):
생성된 작업자는 이제 메시지에서 수신한 매개변수를 통해 작업자 내부의 모든 파서를 구성할 수 있습니다. WorkerSupport 는 원하거나 필요한 경우 자체 코드로 완전히 대체될 수 있는 참조 작업자 실행기 구현( code )을 제공합니다.
작업자가 만들고있는 파서 실행됩니다 run 의 방법 WorkerRunnerRefImpl ( Parser 작업자 범위 내에서 사용할 수 있으며 this.applyProperties 통화 세터 또는 속성을 파서):

WorkerRunnerRefImpl.prototype.run = function ( payload ) {
    if ( payload.cmd === 'run' ) {

        console.log( 'WorkerRunner: Starting Run...' );

        var callbacks = {
            callbackBuilder: function ( payload ) {
                self.postMessage( payload );
            },
            callbackProgress: function ( message ) {
                console.log( 'WorkerRunner: progress: ' + message );
            }
        };

        // Parser is expected to be named as such
        var parser = new Parser();
        this.applyProperties( parser, payload.params );
        this.applyProperties( parser, payload.materials );
        this.applyProperties( parser, callbacks );
        parser.parse( payload.buffers.input );

        console.log( 'WorkerRunner: Run complete!' );

        callbacks.callbackBuilder( {
            cmd: 'complete',
            msg: 'WorkerRunner completed run.'
        } );

    } else {

        console.error( 'WorkerRunner: Received unknown command: ' + payload.cmd );

    }
};

OBJLoader2.parseAsync 메시지는 다음과 같습니다.

this.workerSupport.run(
    {
        cmd: 'run',
        params: {
            debug: this.debug,
            materialPerSmoothingGroup: this.materialPerSmoothingGroup
        },
        materials: {
            materialNames: this.materialNames
        },
        buffers: {
            input: content
        }
    },
    [ content.buffer ]
);

메시지 개체는 로더에 따라 다르지만 작업자의 파서 구성은 일반적입니다.
이전 게시물의 링크된 예제에서 사용된 코드는 최신 코드로 업데이트되었습니다.

OBJLoader2의 진화와 지원 기능의 추출은 이제 여러분의 피드백이 필요한 지점에 이르렀다고 생각합니다. 모든 예제가 해당 repo에서 위의 분기로 이식되면 완전한 요약이 포함된 PR을 열고 피드백을 요청할 것입니다.

https://webkit.org/blog/7846/concurrent-javascript-it-can-work/ 🤔

참고로, 위에서 설명한 대로 ImageBitmapLoader가 작업자를 사용하도록 하는 작업이 진행 중입니다. 아마도 더 흥미롭게도 결과에 대한 일부 어려운 숫자: https://github.com/mrdoob/three.js/pull/12456

firefox의 createImageBitmap은 사전 매개변수를 지원하지 않기 때문에 이미지 방향이나 색 공간 변환을 지원하지 않습니다. 그것은 API의 대부분의 응용 프로그램을 꽤 쓸모 없게 만듭니다.

이것은 불행한 일입니다. ☹️

@mrdoob 당신이 전환 할 계획이 있습니까 ImageLoader 에 ImageBitmapLoader 에서 TextureLoader ImageBitmap 텍스처에 업로드 덜 차단해야하기 때문에? createImageBitmap() 는 첫 번째 인수만 전달하면 지금까지 FireFox에서 작동하는 것 같습니다. (아마도 TextureLoader 를 통해 두 번째 및 더 많은 인수를 전달할 필요가 없습니까?)

return createImageBitmap( blob );

createImageBitmap () 가 옵션 사전을 지원하는 것이 실제로 중요합니다. 그렇지 않으면 이미지 방향(Flip-Y)과 같은 항목을 변경하거나 미리 곱한 알파를 나타낼 수 없습니다. 문제는 ImageBitmap WebGLRenderingContext.pixelStorei 를 사용할 수 없다는 것입니다. 사양에서 :

_TexImageSource가 ImageBitmap이면 이 세 가지 매개변수(UNPACK_FLIP_Y_WEBGL, UNPACK_PREMULTIPLY_ALPHA_WEBGL, UNPACK_COLORSPACE_CONVERSION_WEBGL)가 무시됩니다. 대신에 해당하는 ImageBitmapOptions를 사용하여 원하는 형식의 ImageBitmap을 만들어야 합니다._

따라서 FF가 옵션 사전을 지원하는 경우에만 ImageBitmapLoader 전환할 수 있다고 생각합니다. 게다가, 같은 속성 Texture.premultiplyAlpha 및 Texture.flipY 작동하지 않습니다 ImageBitmap 지금을. 사용자가 설정하면 ImageBitmap 를 기반으로 하는 텍스처에 영향을 미치지 않습니다. 이는 다소 불행한 일입니다.

그래. 그 사양을 놓쳤네요.

옵션 사전의 중요성도 여기에서 논의됩니다.

https://bugzilla.mozilla.org/show_bug.cgi?id=1335594

bugzilla의 버그(https://bugzilla.mozilla.org/show_bug.cgi?id=1367251, https://bugzilla.mozilla.org/show_bug.cgi?id=1335594)가 ... 2년 동안 그대로 유지되었습니다. 지금 몇 년? 나는 그들이 그것을 고치는 데 이렇게 오랜 시간이 걸릴 것이라고 생각하지 않았다.

따라서 문제는 "기술적으로" 기능이 FF에서 지원되지만 실제로는 쓸모가 없다는 것입니다. 그것을 사용하기 위해 우리는 그것을 사용하는 Chrome용 경로와 사용하지 않는 다른 브라우저용 경로를 가질 수 있습니다. 문제는 Firefox에 기능이 있기 때문에 UA 스니핑을 수행해야 한다는 것입니다.

실용적인 솔루션은 기능 감지를 수행하는 것입니다. 플립 플래그가 있는 cIB를 사용하여 2x2 이미지를 만든 다음 다시 읽고 값이 올바른지 확인합니다.

FireFox 버그에 대해서는 내부적으로도 연락할 것입니다. 그들의 계획을 들은 후 해결 방법이 필요한지 봅시다.

bugzilla의 버그(https://bugzilla.mozilla.org/show_bug.cgi?id=1367251, https://bugzilla.mozilla.org/show_bug.cgi?id=1335594)가 ... 2년 동안 그대로 유지되었습니다. 지금 몇 년? 나는 그들이 그것을 고치는 데 이렇게 오랜 시간이 걸릴 것이라고 생각하지 않았다.

넵 정말 한동안 못 따라해서 죄송합니다 -_-

따라서 문제는 "기술적으로" 기능이 FF에서 지원되지만 실제로는 쓸모가 없다는 것입니다. 그것을 사용하기 위해 우리는 그것을 사용하는 Chrome용 경로와 사용하지 않는 다른 브라우저용 경로를 가질 수 있습니다. 문제는 Firefox에 기능이 있기 때문에 UA 스니핑을 수행해야 한다는 것입니다.

실용적인 솔루션은 기능 감지를 수행하는 것입니다. 플립 플래그가 있는 cIB를 사용하여 2x2 이미지를 만든 다음 다시 읽고 값이 올바른지 확인합니다.

네, 두 솔루션 모두 정말 형편없다는 데 동의합니다. 따라서 이를 피하려고 노력해야 합니다. 따라서 이들 중 하나를 파고들기 전에 우리 측에서 차단을 해제할 수 있는지 확인해야 합니다.

ImageBitmap 업로드 성능 테스트를 했습니다. 5초마다 텍스처를 업로드합니다.

일반 이미지와 ImageBitmap을 비교할 수 있습니다.

https://rawgit.com/takahirox/three.js/ImageBitmapTest/examples/webgl_texture_upload.html (일반 이미지)
https://rawgit.com/takahirox/three.js/ImageBitmapTest/examples/webgl_texture_upload.html?imagebitmap(ImageBitmap )

내 창에서 나는 본다

| 브라우저 | 8192x4096 JPG 4.4MB | 2048x2048 PNG 4.5MB |
| ---- | ---- | ---- |
| 크롬 이미지 | 500ms | 140ms |
| 크롬 이미지비트맵 | 165ms | 35ms |
| 파이어폭스 이미지 | 500ms | 40ms |
| 파이어폭스 이미지 비트맵 | 500ms | 60ms |

( texture.generateMipmaps 은 true )

내 생각

1. Chrome에서 ImageBitmap을 사용하면 성능이 3배 향상됩니다. 아주 좋은 개선입니다.
2. FireFox에 ImageBitmap 성능 문제가 있습니까? 컴퓨터에서도 해볼 수 있나요? 모바일에서 시도하는 것도 환영합니다.
3. ImageBitmap을 사용하더라도 텍스처 업로드는 여전히 큰 텍스처에 대해 차단되는 것 같습니다. 비차단을 위한 점진적 부분 업로드 기술이나 무언가가 필요할 수 있습니다.

ImageBitmap을 사용하더라도 텍스처 업로드는 여전히 큰 텍스처에 대해 차단되는 것 같습니다. 부분 업로드 기술이나 비차단을 위한 무언가가 필요할 수 있습니다.

이 문제에 대한 한 가지 해결책은 텍스처 압축 형식을 사용하고 JPG 또는 PNG를 사용하지 않는 것입니다(따라서 ImageBitmap ). 이 맥락에서 일부 성능 데이터를 보는 것은 흥미로울 것입니다.

예, 동의했습니다. 그러나 특히 모바일과 같은 저전력 장치에서 큰 텍스처에 대한 차단을 여전히 볼 수 있을 것 같습니다. 어쨌든 성능을 먼저 평가하십시오.

또는 scheduled/requestIdleCallback texSubImage2D를 사용하십시오.

rIC = requestIdleCallback?

예, 닌자 편집을 했습니다.

좋아요. 네 동의했습니다.

BTW, 나는 아직 압축 텍스처에 익숙하지 않습니다. 이해를 확인하겠습니다. compressedTexImage2D 는 ImageBitmap 허용하지 않기 때문에 ImageBitmap 에는 압축 텍스처를 사용할 수 없습니다. 맞습니까?

https://developer.mozilla.org/en-US/docs/Web/API/WebGLRenderingContext/compressedTexImage2D

이전 TiledTextureLoader 실험을 다시 방문하기 위해 돌아갔습니다. 이제 비디오 드라이버가 충돌하고 다시 시작되는 것 같습니다.(

(편집: 실제로 가장 큰 텍스처(16k x 16k - https://baicoianu.com/~bai/three.js/examples/textures/dotamap1_25.jpg)를 크롬에 직접 로드하는 것조차 충돌을 일으키는 것처럼 보입니다. 이것은 잘 작동하는 데 사용되었으므로 크롬의 이미지 처리에서 약간의 회귀인 것 같습니다)

requestIdleCallback, ImageBitmap 및 ES6 생성기를 사용하여 GPU에 업로드하기 위해 큰 텍스처를 여러 청크로 분할하는 몇 가지 실험을 했습니다. texSubimage2D를 사용하여 이미지 데이터를 채우더라도 여전히 메모리를 미리 할당해야 하기 때문에 일반 텍스처 대신 프레임 버퍼를 사용했습니다. 단일 GL 호출로 초기화됩니다.

이러한 변경 사항에 대한 저장소는 https://github.com/jbaicoianu/THREE.TiledTexture/에서 계속 사용할 수 있습니다.

내가 기억하는 실험에 대한 몇 가지 메모:

• requestIdleCallback은 총 로드 시간을 크게 늘리는 대신 텍스처를 로드하는 동안 버벅거림을 줄이는 데 확실히 도움이 되었습니다.
• 약간의 추가 작업을 통해 먼저 축소된 버전의 텍스처를 업로드한 다음 더 여유로운 속도로 전체 해상도 데이터를 채우면 이 문제를 완화할 수 있습니다.
• ES6 생성기는 코드를 더 쉽게 이해하고 메모리를 낭비하지 않고 더 쉽게 작성하는 데 도움이 되지만 실제로는 필요하지 않을 수 있습니다.

내 결과는 비슷했습니다. 업로드 속도와 버벅거림 사이에 균형이 있었습니다. (BTW 이 https://github.com/spite/THREE.UpdatableTexture를 만들었습니다).

두 번째 옵션이 WebGL 1에서 작동하려면 실제로 두 개의 텍스처가 필요하거나 적어도 UV 좌표에 대한 수정자가 필요하다고 생각합니다. WebGL 2에서는 대상 텍스처와 크기가 다른 소스를 복사하는 것이 더 쉽다고 생각합니다.

예, texSubImage2D를 사용하면 그런 종류의 크기 조정이 가능하지 않을 것이라고 생각하지만 프레임 버퍼를 사용할 때 OrthographicCamera를 사용하여 텍스처 조각이 있는 평면을 렌더링하고 있으므로 평면의 크기를 변경하기만 하면 됩니다. 그 드로우 콜.

FireFox에서 ImageBItmap의 성능 문제에 대해 bugzilla에서 버그를 열었습니다.

https://bugzilla.mozilla.org/show_bug.cgi?id=1486454

텍스처와 관련된 데이터가 실제로 GPU에 로드되고 이 스레드를 발견한 시점을 더 잘 이해하려고 노력했습니다. 내 특정 사용 사례에서는 로컬 jpeg/gif 파일을 텍스처로 로드 및 디코딩하는 것에 대해 걱정하지 않고 GPU에 텍스처 데이터를 미리 로드하려는 시도에만 관심이 있습니다. 이 스레드를 읽은 후 나는 그것이 두 가지 문제를 모두 다루고 있는지 아니면 전자만 다루고 있는지 완전히 확신하지 못한다고 고백해야 합니다. 후자에만 관심이 있다는 점을 감안할 때 다른 솔루션을 찾아야 합니까? 아니면 텍스처 데이터를 GPU에 강제로 로드하는 데 도움이 되는 것이 있습니까?