이것은 내가 전에 가장 걱정했던 것이다. 당사의 제품은 PhysX 의 뛰어난 효율성 덕분에 동적 장면의 빠른 베이킹 (간접 조명 사전 계산) 을 실현했습니다. PhysX 를 js 로 인코딩한 후 효율성은 어떻습니까? 실험 결과는 다음과 같습니다.

서로 다른 플랫폼에서 두 장면의 베이킹 시간입니다. 단위 (초)

두 장면의 베이킹 결과

Firefox 의 운영 효율성은 만족스럽다. 우리는 Unity 가 Mozilla 가 제안한 asm.js 를 사용하여 js 의 운영 효율성을 높였다는 것을 알고 있지만, 현재 다른 브라우저는 asm.js 를 최적화하지 않고 시간문제일 뿐이다. 베이킹 기능 외에 다른 기능은 다른 브라우저에서 큰 성능 차이를 볼 수 없습니다.

둘째: js 포장 크기

또한 페이지가 로드된 후 즉시 컨텐츠를 렌더링할 수 없는 경우 사용자가 인내심을 잃고 페이지를 닫을 수 있다는 점도 걱정입니다. 모든 최적화 옵션을 설정한 후 당사 제품이 내보내는 패키지 크기는 다음과 같습니다 (압축 후).

마스터 프로그램 (프로젝트 이름). Jsgz): 5.1m.

메모리 초기화 패키지 (project name.html.memgz): 2.7m.

내장 리소스 (프로젝트 이름). 데이터 gz):1m.

그래도 크다고 말할 수 밖에 없다. 글꼴은 내장 리소스의 상당 부분을 차지합니다. 앞으로 모든 인터페이스를 웹 페이지로 만들 수 있어 브라우저 글꼴을 사용할 수 있다. 마스터 패키지는 Unity 의 전체 런타임 및 자체 코드를 컴파일하기 때문에 매우 큽니다. 나는 이에 대해 Unity 팀에 편지를 몇 통 써서, 그들이 한번도 사용하지 않은 모듈을 컴파일하지 않을 수 있는지 물었다. 그들은 고려할 것이라고 말하지만, 결합도 등으로 인해 더 어려울 것이다. 메모리 초기화 패키지에 대해 잘 모릅니다. Asm.js 는 Unity 가 웹 GL 정식 버전을 출시할 때 이 문제가 개선되기를 바랄 수 있습니다.

출력 항목에는 두 개의 폴더인 Release 와 Compressed 가 포함되어 있지만 압축 상태만 유지됩니다. 생성. Htaccess 파일은 이 압축 버전의 패키지로 주소를 자동으로 전송하고 HTTP 요청에 압축 헤더를 추가합니다. 브라우저가 다운로드되면 자동으로 압축이 풀립니다.

셋째, 모바일 플랫폼

이것은 많은 사람들이 관심을 갖는 문제이다. 웹 GL 은 HTML5 의 일부로 모든 플랫폼에서 실행할 수 있겠죠? 하지만 사실, WebGL 은 현재 모바일 플랫폼에서 잘 지원되지 않고 있으며, 위챗 진출은 더욱 어렵다. 이와 관련하여 Dell 의 시나리오는 사용자가 만든 각 템플릿 사이에 일련의 360 도 파노라마를 저장하는 것입니다. 위챗 공유는 로밍할 수 있지만 편집할 수는 없습니다. 이런 방안을 고려하는 것은 합리적인 것 같다. 휴대폰 화면이 작아서 복잡한 3D 편집에 정말 적합하지 않습니다. 모바일 플랫폼이 WebGL 을 완벽하게 지원하면 휴대폰에 적합한 3D 어플리케이션이 더 많이 등장한다.

4: 그래픽 인터페이스 맞춤

Unity5 는 마침내 DeferredShading 을 지원했습니다. 이전에는 DeferredLighting 만 부를 수 있었습니다. 그러나 현재 WebGL 1.0 에서는 여전히 사용할 수 없으며 연기 조명에만 사용할 수 있습니다. WebGL 1.0 은 OpenGL ES 2.0 에 해당하고, WebGL2.0 은 OpenGL ES 3.0 에 해당하므로 프로젝트가 WebGL 플랫폼에 적응하는 것은 기본적으로 모바일 플랫폼에 적응하는 것과 같다는 것을 알고 있습니다. 웹 GL 2.0 의 표준이 막 제정되어 지원되는 브라우저가 언제 출시되는지 모르기 때문에 현재 적응 작업은 웹 GL1.0 을 기반으로 합니다. MRT 를 사용할 수 없는 것 외에도 2D 슬라이스를 패치하여 3D 텍스처를 구현해야 합니다. DepthTexture 는 수동으로 RGBA 형식으로 인코딩해야 합니다. 이 작품들은 마치 10 년 전에 한 것처럼 친숙한데, 우리는 실시간 3D 가 최근 몇 년 동안 이렇게 느리게 발전한 것을 한탄하지 않을 수 없다. 게임 외에는 정말 좋은 응용이 없는 것 같다.