[💬] [팁] 언리얼 블루프린트로 만들고 nativization으로 c++전환

[ㅇㅇㅁㄴㅇㅁㄴ(58.143)]

블루프린트를 꺼려하게 되는 가장 큰 이유는 퍼포먼스임. 

하지만 c++ nativization 기능이 생기고 나서부터는 그 괴리를 거의 없앨수 있게 됨.

사실 이게 한참 전에 나온기능이긴 한데 버그가 많아서 도저히 쓰기 힘든 상태였고 최근에서야 그마나 안정적이게 되었다.

그럼에도 불구하고 여전히 버그가 있어서  자체적으로 몇가지 제약을 걸고 사용하는게 정신건강에 좋다.

0. inclusive(통째로 c++화)는 사용하면 어디서 버그가 터질지 모르니 금지. exclusive로 사용해야함.

1. 독립적인 액터를 만들어서 그것만 c++화 시켜야하고 아래의 사항을 지켜야한다.

2. Enumeration이랑 관련된 버그가 예전부터많았고 지금도 여전히 문제가 있으니 사용 금지.

3. 다른 액터를 casting하거나 interface로 소통하려면  그에 해당하는 것들도 전부 nativization화할 exclusive목록에 포함해야하니 왠만하면 다른방법으로 소통.

결론적으로 이 기능을 버그없이 잘 사용하는 방법은 

독립적인 액터를 만들어서 c++화 시킬 기능을 쑤셔박되 enum이나 casting을 자체적으로는 사용하지 않는 형태로 구현하고

다른 블루프린트에서 그 액터를 호출해서 기능을 꺼내쓰는 방식으로 써야한다는거임. 

버그없이 잘 굴러가면 굳이 이럴필요없겠지만 c++화 시킨다는게 엔진 만드는 입장에서도 워낙 복잡한 과정이라 그런지 항상 버그가 있어서 어쩔수 없이 이렇게 써야한다.

그렇다면 이것으로 얻는 이득이 어떠한가? 

실제로 내가 사용하는 그리드 월드맵에서의 여러방향 대량 길찾기 기능으로 테스트해본 결과는 다음과 같음.

에디터상의 PIE 블루프린트 버젼

패키징된 상태의 BP버젼

c++ nativization된 버젼

170ms 에서 10ms로 대폭 줄어든 것을 볼수있다.  

끝.

 

[익명(211.178)]

ㅆㅅㅌㅊ

[phenom(222.109)]

오 ㅆㅅㅌㅊ;

[AK(125.134)]

nativization은 4.13쯤에 이미 안정화 끝났었음. 다만
http://api.unrealengine.com/KOR/Engine/Blueprints/TechnicalGuide/NativizingBlueprints/Advanced/index.html
가이드
라인을 잘 따라야 하는 문제가 있음
현업에서는 C++와 BP를 적절하게 사용해야되는데
http://api.unrealengine.com/KOR/Resources/SampleGames/ARPG/BalancingBlueprintAndC-/index.html
관련
문서임.
가이드라인만 잘 지키면 inclusive로 써도 됨.

[ㅇㅇㅁㄴㅇㅁㄴ(58.143)]

nativization이 4.12때 처음으로 experimental상태로 나왔는데 무슨 4.13에 안정화냐. 4.18때까지 버그 즐비했었다. 지금도 버그 꽤 있고. c++화된 버젼 잘플레이해봐 결과값이 다르게 나오는 경우가 꽤있어. enum이랑 map container관련 버그가 아직 남아있어서.