기존에 나와있는 3D 라이브러리들은 복잡한 기능에 치중하여 느리고 사용할 때 호스트 코드가 비대해지는 불편함이 있었다. 사실 사용하는 목적이 엄청난 3D를 렌더링하는 경우도 있지만 그저 간단한 입체효과를 사용할 때도 있는게 아닌가.

플10API는 DisplayObject를 간단히 3D위상으로 바꿔주는 능력이 있으니 그 정도 기능만 라이브러리화 해서 간단히 사용할 수 있으면 좋겠다는 생각을 늘 했고, 그러한 간단한 프레임웍이 pyramid3D였다.

하지만 제작한 버전의 가장 큰 문제가 컨테이너와 엘레멘트가 다른 부모로부터 상속하기 때문에 엘레멘트안에 컨테이너를 포함할 수 없다는 점과 엘레멘트가 다른 엘레멘트를 포함하는 능력이 커지면서 사실 상 컨테이너의 의미가 무의미해진 점이다.

이러한 프레임웍의 클래스 구조변경과 함께 기존에 느리게 만들었던 알고리즘을 대거 개선할 목적으로 3일간에 걸쳐 pyramid3d 1.5 작업에 돌입했으나, 실패했다. 이유는 다른게 아니라 transform.getRelativeMatrix3D( root ) 의 문제를 해결하지 못해서다. 네이티브3D의 핵심적인 엔진의 기능은 z소트인데 자식의 자식을 연속으로 소팅해가는 경우 현재 자신의 전역에서의 정확한 z값을 알기 위해 저 변환을 사용한다. 이 변환은 보통 정상적으로 작동하지만 자식이 rotationX, Y, Z가 적용되는 경우에는 적용되기 전 기준으로 z값을 반환하는 오류가 있다.

아마로 이 오류를 해결하는 방법은 커스텀으로 좌표변환 행렬과 벡터연산 클래스를 작성하는 수 밖에 없을 것이다. 그 오류를 간단히 살펴보면 아래와 같다.

마우스를 기준으로 2개의 그룹이 회전하고 있는데 하나의 그룹은 자식이 회전하지 않은 그룹으로 z소트가 올바르게 일어난다. 하지만 다른 그룹에서 자식들이 제각각 회전한 상태로 이 경우 같은 로직임에도 불구하고 자식의 z소트가 제대로 일어나지 않는걸 알 수 있다.

그래서 3일간 삽질해서 네이티브 API로 어떻게든 승부를 보려 했으나 실패하고 이제 차기 3D프레임웍은 ND3D를 쓰기로 결정했다.

엔디는 사용방법이 매우 간단한 플10API기반의 3D라이브러리로 간단한 작업을 하기엔 그만이다. 샘플사이트의 주소는 아래와 같다.

http://www.nulldesign.de/projects/nd3d-as3-3d-engine/

엔디는 카메라, 렌더러, 오브젝트 라는 간단한 3개의 조합으로 표현되며 프로그래밍적인 인터페이스가 매우 직관적이다. 적당히 래핑해서 사용할까 생각 중이다. 아래 샘플은 불과 몇 줄로 만들어내는 간단한 샘플이다.