재료(텍스쳐) 간 성능에 미치는 영향

이번 주요 화제는 재질(무늬) 간의 성능의 영향, 입자 시스템의 지속적인 방출점 변경의 성능 최적 해결 방안, 저해상도 DepthTexture의 렌더링 방법, Unity 대상의 실시간 조명의 성능 비용이다.
만들다
Q1: 문제가 있습니다.우리 프로젝트에는 입자 시스템이 하나 있는데, 수시로 방출점을 바꾸어야 한다.월드스페이스 모드에서는 확실히 특정한 효과에 도달할 수 있지만, 지금은 한 프레임에서 여러 위치에서 입자를 동시에 방출해야 한다.같은 Partical System 여러 개가 확실히 목적을 달성할 수 있지만 약간의 낭비를 느껴 제작과 폐기가 자주 발생한다.전체 캐시를 하면 합계가 엄청납니다.Partical System에서 이 효과를 실현할 수 있는 방법이 있습니까?
이 문서를 참조할 수 있습니다.
https://docs.unity3d.com/ScriptReference/ParticleSystem.Emit.html
Particle System의 Emit 방법으로 입자를 발사한 후 하나의 프레임 안에서 서로 다른 EmitParam을 사용하여 Emit을 여러 번 호출할 수 있다.이렇게 되면 입자 시스템 자체가 이동할 필요가 없지만 Emit의 위치 파라미터는 매번 다르다.
자산 관리
Q2:
장면 1: 1장 512×256 텍스쳐.
장면2: 2장 256×256 텍스쳐.
나는 위의 어느 것이 원가가 높은지 알고 싶다.
그리고 같은 캐릭터가 됐다.
시나리오 1: 블레이드 1개 및 512 1개×256 텍스쳐.
시나리오 2: 블레이드 2개 및 256 2개×256 텍스쳐.
이런 상황에서 어느 쪽이 원가가 더 높은지 물어보고 싶습니다.판결의 근거와 원인은 무엇입니까?
메모리에 관해서는 설정이 같으면 두 개가 같아야 한다. (길이와 너비가 같은 부분의 압축 형식은 포함되지 않는다.)
CPU 비용은 거의 동일합니다.한 재질에 대해 한 장과 두 장의 차이는 샘플의 횟수에 있다.하나의 무늬는 한 번의 무늬의 귀속 원가를 줄일 수 있다.이론적으로 삭감된 시간의 비용은 ns수준이기 때문에 대부분의 경우 CPU 단말기의 차이는 무시할 수 있다.소재가 두 개면 영향을 받는 것이 많아집니다.더 많은 Draw Call과 RenderState 전환 등을 일으킬 수 있으므로 아틀라스 팩킹을 적용해 최적화해야 한다.
GPU 원가에 대해 무늬가 있는 Shader 샘플을 추가하려면 더 많은 계산이 필요하다.그리고 Shader Instruction과 Cycles도 많아질 것입니다.그런데 그게 정말 더 많은 실제 원가를 가져올 수 있을까요?절대 아니야.GPU의 압력은 Shader의 Instruction에 달려 있을 뿐만 아니라 이 Shader가 보여준 운행 시간의 픽셀 수에 달려 있다.자체 비율이 적은 경우 검체 1개를 늘리거나 줄여 사실상 차이가 없다.
렌더링
Q3: 저해상도 DepthTexture를 렌더링하고 싶은데 편리한 방법이 있나요?
저해상도 RenderTexture를 직접 만들고 Shader Replace ement를 사용하여 DepthTexture를 재현하는 방법(Shader는 Unity의 ShadowCaster를 참조하여 실현할 수 있음)이 있습니다.
그리고 또 하나는요.LastCamera DepthTexture의 다른 저해상도 카메라(있는 경우)에 렌더링된 DepthTexture에 액세스합니다.
렌더링
Q4: Unity에서 빛을 받아 음영을 생성하고 음영을 받아 표현하는 경우.세 가지 Unity의 성능 비용을 알고 싶습니다.또한 모바일 단말기는 상기 세 개 또는 일부의 가능성이 있습니까?
문제주가 말하는'헤드라이트 수락'은 리얼타임 헤드라이트 수락인가요?그러면 성능 원가를 예측할 수 없다.장면을 렌더링하는 복잡도, 빛을 받는 객체의 수 등과 큰 관계가 있기 때문에'켜면 시간이 걸리고 절대 켜지 않는다'고 쉽게 이해할 수는 없다.참고: 독립 게임 "Abi"의 장면 CPU 원가 분석
섀도우 생성과 섀도우 적용은 라이브 섀도우 기능의 두 가지 옵션에 불과합니다.UWA 성능 보고서에서 Shadows.RenderShadowMap 및 Shadows.PreptureShoadowMap에 주의하여 프로젝트의 구체적인 성능 시간 비용을 확인하는 것을 권장합니다.

현재 실시간 조명과 실시간 섀도는 많은 모바일 프로젝트에서 널리 사용되고 있다.
마지막으로 UWA 블로그에는 완벽한 실시간 섀도우에 대한 기사가 많이 올라왔다.나는 그런 것들을 검사하고 싶다. 문제에 주로 유용하다.
관리
Q5: Mono와 IL2 CPP 사이에서 망설이는 프로젝트 초기 단계입니다.Unity ILCPP 및 Mono 중 어떤 것이 더 좋습니까?IL2CPP 의 성능에 정말 큰 변화가 있습니까?사용하신 분 알려주세요!
①
IL2CPP와 모노는 현재 안드로이드에서 주로 선택된다.
우선 사업 초기 단계에서는 이 문제를 고려할 필요가 없고, 현재 IL2CPP의 성숙도만 있다면 언제든 신경 쓰지 않고 사용할 수 있다.초기 단계에서는 더 빨리 포장할 수 있도록 모노로 제출해주세요.IL2CPP의 공식 버전이나 성능 및 호환성 테스트 버전이 더 좋습니다. (물론.net에 있는 dll 코드의 핫 업데이트가 없으면)
다음 내용은 자신이 프로젝트에서 만들어 낸 것으로 아직 얻지 못했다.
요약:
Mono의 이점:
1) 충분히 테스트하였음;
2) 포장화 속도가 빠르다.
3) 포장 사이즈가 작다.
4) Android는 DLL 동적 로드 키트의 핫 업데이트를 지원합니다(사용하지 않았지만 IL2CPP가 전혀 지원되지 않음).
IL2CPP의 이점:
1) Mono 메모리가 상승하면 감소하지 않습니다.
2) C#측의 계산집약형 알고리즘의 성능이 N배 급상승(동일지도의 경로검색과 자동건축물위치계획 등 알고리즘의 속도가 3배 이상 증가)했다.
3) Lua 핫 업데이트에 문제가 없으며 반사 호출과 내보내기 호출이 모두 지원됩니다(장점은 아닐 수 있지만 예상 밖입니다).
그리고 IL2CPP의 문제점은 다음과 같습니다.
1) 구축 시간이 매우 깁니다.Windows 버전의 Android NDK 툴링크 성능은 어떻게 저하됩니까?AMD16 코어 및 32 스레드를 사용하여 NDK는 컴파일할 때 완전한 병렬화를 지원합니다.
2) IL2CPP를 적용한 후 ARMv7 버전만 컴파일하면 일부 시뮬레이터는 게임을 시작할 수 없습니다.FAT(ARMv7+x86)를 사용하면 되고 시뮬레이터도 순조롭게 실행할 수 있다.물론 포장 사이즈가 20MB가 커졌어요.
Mono 모드에서는 64비트를 지원할 수 없습니다.향후 IL2CPP는 유일한 옵션입니다.유닛은 지금 잘하고 있어.
②
내가 보충할게.안드로이드가 2019년 구글플레이에 발표하려면 IL2CPP 경로만 사용할 수 있는 64비트 라이브러리가 필요합니다.
또한 IL2CPP의 안드로이드에는 또 다른 문제가 있습니다.바로'Failed to extract resources needby Il2CPP'다.현재 사용을 방해하는 유일한 문제(2017.3에도 재현)가 될 것으로 보인다.
https://forum.unity.com/threads/failed-to-extract-resources-needed-by-il2cpp-unity-5-4-0f3.419593/
나는 이 문제에 대해 간단히 설명하겠다.Android에서는 시작할 때마다 Unity가 IL2CPP에 필요한 자산(assets/bin/Data/Managed에서 Mono의 config 및 각종 meta 데이터)을 동결해제합니다.문제는 이 조작이 실패할 수도 있다는 것이다.실제로 Unity는 apk에서 직접 읽을 수 있습니다.나는 Unity 공식이 가능한 한 빨리 이 문제를 해결할 수 있기를 바란다.
UWA Technology는 다양한 유형의 개발자를 대상으로 컴퓨터 분석 및 최적화 솔루션 및 컨설팅 서비스를 제공하는 회사입니다.
UWA 공식 사이트: https://jp.uwa4d.com
UWA 공식 블로그: https://blog.jp.uwa4d.com