이 페이지는 일반적인 성능 문제와 이를 해결하는 방법에 대해 설명합니다.
스크립트 계산
Lua 코드의 고가 작업은 처리하는 데 더 오래 걸리고 따라서 프레임 평가영향을 미칠 수 있습니다. 병렬로 실행되지 않는 한 Lua 코드는 동기적으로 실행되고 스레드를 생성하는 주 스레드를 차단합니다.
일반적인 문제
테이블 구조에 대한 집중된 작업 - 복잡한 작업, 예를 들어 직렬화, 디세리얼라이즈 및 딥 클론은 대규모 테이블 구조에 대해 높은 성능 비용이 발생합니다. 이는 특히 이러한 작업이 재귀적으로 대규모 데이터 구조를 처리하는 경우에 해당됩니다.
고주파 이벤트 진행 상황을 기반으로 한 프레임 기반 이벤트의 Class.RunService 의 고가 작업을 제한하지 않고 연결하여 이 작업이 반복되면 계산 시간이 불필요하게 증가하는 경우가 많습니다. 이 이벤트에는 다음이 포함됩니다.
방지
- Class.RunService 이벤트에서 코드를 호출하는 경우 높은 주파수 호출이 필요한 경우에만 사용을 제한하고 다른 코드를 대부분 다른 이벤트에서 실행하거나 좀 더 자주 실행할 수 있습니다(예: 카메라를 업데이트). 대부분의 다른 코드는 다른 이벤트에서 실행하거나 좀 더 자주 실행할 수 있습니다.
- 작업을 여러 프레임에 걸쳐 확장하려면 task.wait() 를 사용하여 대규모 또는 비용이 많은 작업을 작성하십시오.
- 필요 없는 비용이 많이 드는 작업을 식별하고 비용이 많이 드는 작업에는 멀티 스레드를 사용하여 데이터 모델에 액세스할 필요가 없는 계산 비용이 높은 작업을 수행하십시오.
- 특정 서버 사이드 스크립트는 기본 코드 생성에서 이익을 얻을 수 있습니다. 이는 스크립트를 머신 코드로 컴파일하는 간단한 플래그입니다.
마이크로프로파일 범위
| 범위 | 연관 계산 |
| RunService.PreRender | PreRender 이벤트에서 코드 실행 |
| RunService.PreSimulation 실행 | 단계 이벤트에서 코드 실행 |
| RunService.PostSimulation 실행 | 하트 비트 이벤트에서 코드 실행 |
| RunService.Heartbeat | 하트 비트 이벤트에서 코드 실행 |
MicroProfiler를 사용하여 스크립트에 대한 자세한 정보는 debug 라이브러리에 참조하십시오, 이 라이브러리에는 특정 코드에 태그를 지정하고 특정성을 더 높이는 기능을 포함하여 태그를 기능을 포함하여 태그를 기능을 포함하여 태
스크립트 메모리 사용
메모리 누출은 가비지 수집기가 제대로 릴리스하지 못할 때 스크립트를 작성할 때 발생할 수 있습니다. 누출은 특히 서버에서 발생하는 경우가 많은데, 클라이언트 세션은 몇 일 동안 지속될 수 있지만, 가비지 수집기는 몇 일 동안만 지속될 수 있습니다.
개발자 콘솔의 다음 메모리 값은 추가 조사가 필요한 문제를 나타낼 수 있습니다.
- LuaHeap - 높거나 증가하는 사용량은 메모리 누출을 나타냅니다.
- InstanceCount - 인스턴스 수를 일관되게 증가시키면 코드의 일부 인스턴스에 대한 가비지 수집이 수행되지 않습니다.
- PlaceScriptMemory - 메모리 사용량을 스크립트별로 분석합니다.
일반적인 문제
연결된 연결을 해제합니다. - 엔진은 연결된 콜백에 참조된 이벤트를 연결한 연결을 해제하지 않습니다. 따라서 연결된 인스턴스 내의 이벤트 및 코드 활성 연결, 연결된 함수 및 참조된 값은 메모리 가비지 수집기에서 작동하지 않습니다. 심지어 이벤트가 발생한 후에도 메모리 가
인스턴스가 소속된 인스턴스가 파괴되면 이벤트는 해당 인스턴스에 대해 더 이상 연결할 수 없으므로 일반적인 오류입니다. 사용자가 경��
테이블에 개체를 삽입하지만 더 이상 필요하지 않을 때 해당 개체를 제거하지 않으면 불필요한 메모리 사용이 발생합니다. 예를 들어, 다음 코드 샘플은 사용자 데이터를 추적하는 테이블을 만듭니다. Inserting objects into tables but not removing them when they are no longer needed - 사용자 데이터를 추적하는 테이블을 만듭니다.
예시
local playerInfo = {}
Players.PlayerAdded:Connect(function(player)
playerInfo[player] = {} -- 일부 정보
end)
필요하지 않게 된 이 항목을 제거하지 않으면 테이블은 크기가 계속 증가하고 세션에 더 많은 사용자가 참여함에 따라 메모리를 더 많이 사용합니다. 이 테이블을 반복하는 코드는 테이블의 크기가 증가함에 따라 더 비용이 많이 듭니다.
방지
메모리 누출을 방지하기 위해 사용된 모든 값을 클리어하려면:
모든 연결을 해제하십시오. - 코드 기반으로 각 연결이 위의 다음 경로 중 하나를 통해 제대로 마감되었는지 확인하십시오.
- Disconnect() 함수를 사용하여 수동으로 연결 해제하십시오.
- 이벤트에 속하는 인스턴스를 Destroy() 함수로 파괴합니다.
- 연결이 되는 스크립트 개체를 파괴합니다.
플레이어 개체 및 캐릭터 후에 남겨진 후 제거 - 사용자가 떠난 후 연결이 유지되지 않도록 코드를 구현하십시오, 예를 들어 다음과 같은 예에서 볼 수 있듯이:
예시Players.PlayerAdded:Connect(function(player)player.CharacterRemoving:Connect(function(character)task.defer(character.Destroy, character)end)end)Players.PlayerRemoving:Connect(function(player)task.defer(player.Destroy, player)end)
물리 계산
과도한 물리 시뮬레이션은 서버와 클라이언트 모두에서 프레임당 계산 시간이 증가하는 주요 원인이 될 수 있습니다.
일반적인 문제
과도한 물리 시간 단위 주기 횟수 - 기본적으로 단위 행동은 적응 모드에 있으며, 단위 행동은 물리 메커니즘의 복잡성에 따라 60 Hz, 120 Hz 또는 240 Hz입니다.
물리학의 정확도를 향상시킨 고정 모드도 사용할 수 있으며, 이는 모든 물리학 구성 요소가 240 Hz(프레임당 4번)로 단계를 밟도록 강제합니다. 이로 인해 각 프레임에 대해 더 많은 계산이 수행됩니다.
복잡한 개체의 과도한 수 - 시뮬레이션된 복잡한 개체의 수가 증가할수록 물리 계산이 각 프레임에 걸리는 시간이 길어집니다. 종종 경험에는 구현되지 않거나 제한 메커니즘이 더 많이 필요한 개체가 시뮬레이션됩니다.
과도하게 정확한 충돌 감지 기능은 메쉬 부품에 Class.MeshPart.CollisionFidelity|CollisionFidelity 속성이 있어 충돌을 감지하여 다양한 수준의 성능 영향을 제공합니다. 메쉬 부품의 정확한 충돌 감지 기능은 가장 비용이 많이 드는 성능 코스트를
방지
물리적 시뮬레이션을 사용하지 않는 고정 부품 - 물리적 시뮬레이션을 사용하지 않는 모든 부품, 예를 들어 고정 NPC.
적응 물리 단계를 사용합니다. - 적응 단계는 물리 메커니즘에 대한 물리 계산 속도를 동적으로 조정하여 물리 업데이트를 일부 경우 덜 자주 만들 수 있습니다.
메커니즘 복잡성 줄이기 * 가능하면 조립에 물리 제약 또는 연결을 최소화하십시오.
- 메커니즘에 대한 충돌 가능성을 줄이려면 제한 또는 충돌 제한 조건을 적용하여 렉돌 팔을 조정하여 충돌을 방지하십시오.
네트워크 메쉬에 대한 정확도 맞춤 충돌 사용 최소화 * 사용자가 차이를 드러내기 드물게 하는 작거나 상호 작용 불가능한 개체의 경우 상자 정확도를 사용하십시오.
소형 중간 크기 개체의 경우 상자 또는 선박 충실도를 사용하십시오, 모양에 따라.
대형 및 매우 복잡한 개체의 경우, 가능하면 투명한 부품을 사용하여 사용자 정의 충돌을 빌드하십시오.
충돌이 필요 없는 개체의 경우, 충돌 비활성화 및 범위 맞춤 사용을 사용하여 메모리에 충돌 지오메트리가 여전히 저장되지 않도록 합니다.
Studio에서 디버깅 목적으로 충돌 기하를 렌더링하려면 시각화 옵션 위젯에서 충돌 정확도를 토글하여 확인할 수 있습니다.
또한, CollisionFidelity = Precise 필터를 탐색기에 적용하여 모든 메쉬 부품의 정확한 위치를 표시하고 쉽게 선택할 수 있습니다.
정확도 및 성능 요구 사이에서 균형을 유지하는 충돌 유사도 옵션을 선택하는 방법에 대한 자세한 내용은 설정 물리 및 렌더링 매개 변수를 참조하십시오.
마이크로프로파일 범위
| 범위 | 연관 계산 |
| 물리학 계단 | 전체 물리 계산 |
| 월드 스텝 | 각 프레임마다 사용되는 불연속 물리 단계 |
물리 메모리 사용
물리 이동 및 충돌 감지는 메모리를 소모합니다. 메쉬 부품에는 CollisionFidelity 속성이 있으며, 충돌 한 메쉬의 접근 방식을 결정합니다.
일반적인 문제
기본 및 명확한 충돌 감지 모드는 높은 해상도 충돌 모양과 함께 사용하는 두 가지 다른 모드보다 훨씬 더 많은 메모리를 소비합니다.
PhysicsParts 아래에서 메모리 사용량이 높은 경우 경험에서 개체의 충돌 정확도를 줄이는 것이 좋습니다.
방지 방법
충돌 신뢰성에 대한 메모리 사용을 줄이려면:
- 충돌이 필요하지 않은 부품의 경우, 충돌 비활성화를 설정하여 BasePart.CanCollide, BasePart.CanTouch, BasePart.CanQuery를 2>Class.BasePart.CanQuery2>로 설정하여 5>Class.BasePart.CanRender5>를 8>Class.BasePart.CanRender8> 로 변경합니다.
- 충돌 유사도를 줄이려면 CollisionFidelity 설정을 사용하십시오. Box는 가장 낮은 메모리 오버헤드를 가지고 있으며, Enum.CollisionFidelity
- 작은 고정된 부품의 충돌 정확도를 Box 로 설정하는 것이 일반적으로 안전합니다.
- 매우 복잡한 대형 메쉬의 경우 상자 충돌 정확도가 낮은 작은 개체에서 콜리셔ン 메쉬를 직접 빌드하는 것이 좋습니다.
인간형
Humanoid 는 플레이어와 비플레이어 캐릭터(NPC) 모두에게 다양한 기능을 제공하는 클래스입니다. 강력하지만, Humanoid 는 엄청난 계산 비용이 듭니다.
일반적인 문제
- NPC에서 모든 HumanoidStateTypes 을 사용하지 않도록 하는 경우에는 성능 비용이 발생합니다. - 특정 Ennum.HumanoidStateType|HumanoidStateTypes 을 사용하도록 설정하는 경우 필요하지 않은 경우 모든 Climbing 상태를 비활성화할 수
- 인간 노이드와 자주 모델을 시작, 수정 및 재생성합니다. * 이 작업은 엔진이 처리하는 데 시간이 오래 걸릴 수 있습니다. 특히 이 모델이 층 복장을 사용 하는 경우. 이 작업은 또한 아바타가 자주 리스폰하는 경험에서 특히 문제가 될 수 있습니다.
- In the MicroProfiler , lengthy updateInvalidatedFastClusters tags (over 4 ms) are often a signal that avatar instantiation/modification is triggering excessive invalidations.
- 일반적으로 이동하지 않는 정적 NPC의 경우 인간형을 사용하지 않습니다. - 일반적으로 이동하지 않는 정적 NPC의 경우 Humanoid 클래스가 필요하지 않습니다.
- 서버에서 많은 NPC에 대해 애니메이션 플레이 - NPC 애니메이션은 서버에서 실행해야 하며 클라이언트에 복제해야 합니다. 이는 불필요한 대기 시간일 수 있습니다.
방지
- 클라이언트에서 NPC 애니메이션 플레이 - 대규모 NPC 수 있는 체험에서 클라이언트에서 애니메이션을 생성하고 로컬로 실행하십시오. 이렇게 하면 서버에 부하가 줄어들며 필요한 복제를 local로 만들 수 있습니다. 또한 추가 최적화가 가
- Humanoids에 적합한 대체 사용 - NPC 모델에는 반드시 인간형 개체가 포함되지 않아도 됩니다.
- 고정 NPC는 단순한 AnimationController 를 사용하십시오, 움직일 필요가 없기 때문에 단순히 애니메이션을 플레이할 필요가 있습니다.
- NPC를 이동할 때 자체 이동 컨트롤러를 구현하고 복잡성에 따라 AnimationController를 사용하는 것이 좋습니다.
- 사용되지 않은 상태의 인간 표시 비활성화 - Humanoid:SetStateEnabled()를 사용하여 각 인간에게 필요한 상태만 활성화하십시오.
- 자주 재생성되는 풀 NPC 모델 - 대신 NPC를 완전히 파괴하지 않고 풀에 있는 비활동 NPC로 보내십시오. 이렇게 하면 새로운 NPC가 재생성되면 풀에서 즉시 하나의 NPC를 다시 활성화할 수 있습니다. 이 프로세스는 풀링이라고
- 사용자가 근처에 있을 때만 NPC를 생성합니다. - 사용자가 범위 내에 있지 않은 경우 NPC를 생성하지 마십시오. 및 사용자가 범위를 떠날 때 필터링합니다.
- 만들기 후 아바타 계층에 변경을 피하십시오 - 아바타 계층에 대한 일부 변경은 성능 측면에서 중요한 영향을 미칩니다. 일부 최적화는 사용할 수 있습니다:
- 사용자 지정 절차 애니메이션의 경우 JointInstance.C0 및 JointInstance.C1 속성을 업데이트하지 마십시오. 대신 Motor6D.Transform 속성을 업데이트하십시오.
- 아바타에 어떤 BasePart 개체를 부착하려면, 아바타의 모델 Model 계층 외부에서 수행하십시오.
마이크로프로파일 범위
| 범위 | 연관 계산 |
| 단계 인간형 | 인간형 컨트롤 및 물리 |
| 스텝 애니메이션 | 인간형 및 애니메이터 애니메이션 |
| 업데이트 안 됐어요FastClusters | 아바타를 즉시 생성하거나 수정하는 데 연관됩니다. |
렌더링
클라이언트가 각 프레임에서 지출하는 시간의 상당한 부분은 현재 프레임에서 시간을 표시하는 데 사용됩니다. 서버는 렌더링하지 않으므로 이 섹션은 클라이언트에게만 독점됩니다.
드로우 콜
드로우 콜은 엔진에서 GPU로 렌더링할 무언가를 설정하는 집합입니다. 드로우 콜은 대기 시간이 오래 걸립니다. 일반적으로 프레임당 드로우 콜이 적으로 감소할수록 렌더링 시간이 단순히 감소합니다.
Studio에서 Render Stats > Timing 항목과 함께 많은 그림 호출이 현재 발생하고 있음을 확인할 수 있습니다. 클라이언트에서 Render Stats 를 클릭하여 클라이언트에서 볼 수 있습니다.
지정된 프레임에 있는 장면에 그려야 하는 개체가 늘수록, 더 많은 드로우 콜이 GPU에 호출됩니다. 그러나 Roblox 엔진은 개체와 텍스처를 동일하게 결합하는 프로세스를 instancing이라고 하며, 다음과 같은 여러 개체를 단일 드로우 ��
- SurfaceAppearances 및 TextureIDs는 동일합니다. SurfaceAppearance가 존재하지 않을 때 0>Class.MeshPart.TextureID|TextureIDs0>가 동일합니다.
- 두 SurfaceAppearance 및 MeshPart.TextureID 가 존재하지 않는 경우 재료는 동일합니다.
기타 일반적인 문제
과도한 개체 밀도 사용 - 높은 밀도의 개체가 많이 있으면 이 장면의 렌더링이 더 많은 드로우 콜을 필요로 합니다. 특정 부분의 맵을 보는 경우 프레임 속도가 떨어지는 경우 이 개체 밀도가 너무 높음을 나타내는 좋은 신호일 수 있습니다.
데칼, 텍스처 및 입자와 같은 개체는 잘 묶지 않고 추가 그림 호출을 소개하지 않습니다. 특히 속성을 ParticleEmitters 에 변경하면 이행드라마틱한 영향을 미칠 수 있습니다.
놓치는 기회 - 종종 씬에 동일한 메쉬가 여러 번 중복되지만 메쉬의 각 복사본에는 다른 메쉬 또는 텍스처 자산 ID가 있습니다. 이렇게 하면 메쉬를 복제하여 불필요한 드로우 콜을 발생시킬 수 있습니다.
이 문제의 일반적인 원인은 개별 자산이 Roblox에 가져오고 나서 중복 포스트 가져오기를 통해 세트를 조합하는 것이 아니라 전체 씬을 가져올 때입니다.
과도한 개체 복잡성 - 많은 드로우 콜 수는 아니지만, 씬에 있는 트라이앵글의 수는 프레임이 렌더링되는 데 걸리는 시간에 영향을 줍니다. 매우 복잡한 메쉬를 가진 씬
과도한 그림자 캐스팅 - 그림자를 처리하는 것은 비용이 많이 드나, 그림자를 캐스트하는 높은 수의 빛 개체(또는 그림자에 영향을 주는 작은 부품의 높은 밀도)가 많은 수의 그림자를 캐스트하는 경우 성능 문제가 발생할 수 있습니다.
부분 투명도 개체 주위에 배치하면 엔진이 중첩된 픽셀을 여러 번 렌더링하여 이행저하시킬 수 있습니다. - 이 문제를 식별하고 수정하려면 중첩된 투명도 개체 주위에 배치를 참조하십시오.
방지
- 동일한 메쉬를 인스턴스화하고 유일한 메쉬의 수를 줄이십시오. - 모든 유일한 메쉬에 동일한 기본 자산 ID가 있는지 확인하면 엔진이 단일 드로우 콜에서 인식하고 렌더링할 수
- 렌더링 퀄리티 조정 - 렌더링 퀄리티를 자동 또는 성능 로 설정합니다. 이를 통해 메쉬가 그려야 할 폴리그론 수를 줄일 수 있습니다.
- 적절한 부품과 라이트 오브젝트에 대한 그림자 캐스팅 비활성화: - 시뮬레이션에 있는 그림자의 복잡성을 줄이려면 라이트 오브젝트 및 부품에 대해 선택적으로 그림자 캐스팅 속성을 비활성화하십시오. 이 작업은 편집 시간 또는 런타임에 동적으로 수행할 수 있습니다. 일부 예는:
Class.BasePart.CastShadow 속성을 사용하여 섀도우 캐스팅을 작은 부품에서 비활성화하십시오. 섀도우가 보이지 않을 가능성이 높은 부품에만 적용되는 경우 이 효과는 매우 효과적일 수 있습니다.
그림자에 시각적 유물이 나타날 수 있습니다.
가능하면 이동 개체의 그림자를 비활성화합니다.
개체에 그림자를 캐스트하지 않는 경우 라이트 인스턴스에서 Light.Shadows를 비활성화합니다.
조명 인스턴스의 범위 및 각도를 제한합니다.
적합한 수의 라이트 인스턴스를 사용합니다.
마이크로프로파일 범위
| 범위 | 연관 계산 |
| 준비 및 수행 | 전체 렌더링 |
| 스케치/스케치/스케치 조명 수행 | 라이트 그리드 및 그림자 업데이트 |
| 라이트그리드 CPU | 복셀 라이트 그리드 업데이트 |
| 그림자 맵 시스템 | 그림자 맵핑 |
| 액션/스케이프/업데이트뷰 수행 | 렌더링 및 입자 업데이트를 위한 준비 |
| Perform/Scene/RenderView | 렌더링 및 포스트 처리 |
네트워킹 및 복제
네트워킹 및 복제는 데이터가 서버와 연결된 클라이언트 사이에서 전송되는 프로세스를 설명합니다. 클라이언트와 서버 사이에서 모든 프레임에 정보를 보내지만, 더 큰 양의 정보는 더 많은 컴퓨팅 시간이 필요합니다.
일반적인 문제
과도한 원격 트래픽 발생 - 대량의 데이터를 RemoteEvent 또는 RemoteFunction 개체를 통해 보내거나 매우 자주 호출하면 각 프레임에 대해 처리하는 대기 시간이 길어질 수 있습니다. 일반적인 오류 포함:
- 복제할 필요가 없는 모든 프레임의 데이터를 복제합니다.
- 메커니즘이 없는 사용자 입력의 데이터를 복제하는 경우.
- 필요한 것보다 더 많은 데이터를 발생시킵니다. 예를 들어, 아이템을 구매할 때 플레이어의 전체 인벤토리를 보내거나 구매한 아이템의 세부 정보가 아닌 전체 정보를 보내는 등입니다.
복잡한 인스턴스 트리의 생성 또는 제거 - 서버의 데이터 모델에 변경이 있으면 연결된 클라이언트에 복제됩니다. 이는 런타임에 맵과 같은 대형 인스턴스 계층을 생성하고 삭제하는 경우 네트워크 트래픽이 매우 높을 수 있습니다.
여기에서 일반적인 죄수는 리그에서 애니메이션 편집기 플러그인에 의해 저장된 복잡한 애니메이션 데이터입니다. 게임이 게시되기 전에 이러한 애니메이션 모델을 정기적으로 클론하지 않으면 대량의 데이터가 불필요하게 복제됩니다.
서버 사이드 TweenService - 클래스 TweenService를 사용하여 개체 서버 사이를 트위니지면 트위니지된 속성이 각 클라이언트마다 프레임에 복제됩니다. 이렇게 하면 트위니이 클라이언트의 대기 시간이 변경되면 트위니이 너무 느리게 표시되지 않지만 필요한
방지
다음과 같은 전략을 사용하여 불필요한 복제를 줄일 수 있습니다.
- 대량의 데이터를 한 번에 보내지 않도록 원격 이벤트를 피하십시오. 대신, 필요한 데이터만 낮은 주기로 보냅니다. 예를 들어, 캐릭터의 상태를 위해 프레임을 변경할 때 대신 복제하십시오.
- 맵과 같은 복잡한 인스턴스 트리를 더미로 구성하고 이 더미를 여러 프레임에 작업 복제를 위해 부분별로 로드합니다. * 애니메이션 메타데이터 정리 , 특히 리그의 애니메이션 디렉터리 후에.
- 서버가 생성되는 인스턴스를 알 필요 없는 경우에 특히 인스턴스 복제를 제한합니다. 여기에는 다음이 포함됩니다.
- 폭발 또는 마법 스킬 폭발과 같은 시각적 효과. 서버는 결과를 결정할 위치만 알아야 하며 클라이언트는 시각적 개체를 로컬로 생성할 수 있습니다.
- 첫 번째 사람 아이템 뷰 모델.
- 서버가 아닌 클라이언트에서 트위니 개체.
마이크로프로파일 범위
| 범위 | 연관 계산 |
| 프로세스 패킷 | 이벤트 초대 및 속성 변경과 같은 네트워크 패킷을 처리하는 중 |
| 대역 폭 할당 및 실행 발신자 | 서버에 관련된 나가는 이벤트 |
자산 메모리 사용
크리에이터가 클라이언트 메모리 사용을 개선하기 위해 사용할 수 있는 가장 큰 영향 메커니즘은 인스턴스 스트리밍을 활성화하는 것입니다.
인스턴스 스트림
인스턴스 스트림은 필요하지 않은 데이터 모델의 부분을 선택적으로 로드하므로 클라이언트가 메모리 압력을 감지면 잠깐 더 빨리 로드되고 클라이언트가 메모리 압력을 감지하면 즉시 멈춥니다.
메모리 문제가 발생하고 인스턴스 스트림이 비활성화되어 있으면 경험을 업데이트하여 지원하십시오, 특히 3D 세계가 큰 경우. 인스턴스 스트림은 3D 공간의 거리에 기반하므로, 더 큰 세계는 자연스럽게 더 많이 이익을 얻을 수 있습니다.
인스턴스 스트림이 활성화되면 공격성을 높일 수 있습니다. 예를 들어, 다음을 고려하십시오.
- 지속적인 StreamingIntegrity 사용을 줄이십시오.
- 스트리밍 라디오를 줄이기 .
스트리밍 옵션과 그 이점에 대한 자세한 내용은 스트리밍 속성 을 참조하십시오.
기타 일반적인 문제
- 자산 중복 작업 - 자산 ID가 다른 자산 ID로 결정되는 경우 여러 번 업로드하는 것이 일반적인 오류입니다. 이로 인해 똑같은 콘텐츠가 여러 번 메모리에 로드됩니다.
- 과도한 자산 용량 - 자산이 일치하지 않더라도 동일한 자산을 재사용하고 메모리를 절약할 수 있는 경우가 있습니다.
- 오디오 파일 - 오디오 파일은 놀라운 기여자가 될 수 있습니다 메모리 사용, 특히 클라이언트에서 모두를 한 번에 로드하는 경우 필요한 것만 로드하는 대신 특히 경험의 일부입니다. 전략에 대해서는 로드 시간 을 참조하십시오.
- 고해상도 텍스처 - 텍스처에 대한 그래픽 메모리 사용량은 디스크의 텍스처 크기와 관련이 없지만 텍스처의 픽셀 수입니다.
- 예를 들어, 1024x1024 픽셀 텍스처는 512x512 텍스처의 그래픽 메모리를 4배 소비합니다.
- Roblox에 업로드된 이미지는 고정 형식으로 트랜스코딩되므로 색상 모델에 연결된 적은 비트당 메모리 혜택을 업로드하는 이미지를 압축하거나 업로드하기 전에 이미지 크기를 줄일 수 있습니다. 마찬가지
- 개발자 콘솔에서 그래픽 테텍스처 카테고리를 확장하여 지정된 텍스처에 대한 그래픽 메모리 소비를 식별할 수 있습니다.
방지
- 자산을 한 번만 업로드하십시오 - 동일한 자산 ID를 개체 간에 다시 사용하고 메쉬 및 이미지와 같은 자산이 여러 번 업로드되지 않도록 확인하십시오.
- 중복 자산 찾기 및 수정 - 다른 ID로 여러 번 업로드된 동일한 메쉬 부품 및 텍스처를 찾습니다.
- 비슷한 자산의 유사성을 감지하는 API가 없지만, 장소에 모든 이미지 자산 ID를 수집(수동으로 또는 스크립트로)하고, 다운로드하고 비교하는 데 외부 비교 도구를 사용할 수 있습니다.
- 메쉬 부품의 경우 유ника한 메쉬 ID를 가져와 크기별로 수동으로 중복을 식별하는 것이 가장 좋은 전략입니다.
- 다른 색에 대해 별도의 텍스처를 사용하는 대신, 단일 텍스처를 업로드하고 SurfaceAppearance.Color 속성을 사용하여 여러 컬러에 적용하십시오.
- 맵에서 별도로 자산 가져오기 - 전체 맵을 한 번에 가져오는 대신, 맵에서 자산을 개별적으로 가져오고 재구성하고 재구성합니다. 3D 가져오기는 메쉬의 중복 여부에 대해 중
- 이미지의 픽셀을 더 작게 제한합니다. 를 필요한 만큼만 사용하도록 합니다. 이미지가 화면에 많은 공간을 차지하지 않는 한 대부분의 작은 이미지는 256x256 픽셀 이하여야 합니다. 대부분의 작은 이미지는 256x256 픽셀 이상이 되면 안 됩니다.
- 절단 페이퍼를 사용하여 최대 텍스처 재사용을 보장합니다. 를 확인하려면 3D 맵에서 최적화 페이퍼를 만드는 단계 및 예를 참조하십시오. 절단 페이퍼 만들기 .
로드 시간
많은 경험은 사용자 정의 로딩 화면을 구현하고 ContentProvider:PreloadAsync() 메서드를 사용하여 배경에서 이미지, 음향 및 메쉬를 다운로드하므로 이미지, 음향 및 메쉬를 다운로드하므로 이미지, 음향 및 메쉬를 다운로드하므로 이미지, 음향 및 메쉬를 다운로드하므로 이미지, 음향 및 메쉬를 다운로드하므로 이미
이 접근 방식의 장점은 팝업 없이 경험의 중요한 부분을 완전히 로드할 수 있다는 것입니다. 그러나 일반적인 오류는 이 메서드를 사용하여 더 많은 자산을 미리 로드하는 것입니다.
나쁜 관행의 예로는 전체Workspace를 로드하는 것입니다. 이것은 텍스트 팝업을 방지할 수 있지만 로드 시간을 크게 늘립니다.
대신, 다음과 같은 경우에만 ContentProvider:PreloadAsync()를 사용합니다. 여기에는 다음이 포함됩니다.
- 로딩 화면에 있는 이미지.
- 버튼 배경 및 아이콘과 같은 경험 메뉴의 중요한 이미지를 가져옵니다.
- 시작 또는 생성 영역의 중요한 자산.
대량의 자산을 로드해야 하는 경우 자산 로드 건너뛰기 버튼을 제공하는 것이 좋습니다.