KR20070011062A - 모델 3ｄ 구성 애플리케이션 프로그램 인터페이스 - Google Patents

Abstract

API(application program interface)를 사용하여 모델 3D 오브젝트들에 의해 정의된 3D 모델들의 3D 화면을 구성할 수 있다. 인터페이스는 하나 이상의 그룹 오브젝트들 및 하나 이상의 리프 오브젝트들을 가진다. 그룹 오브젝트들은 다른 그룹 오브젝트들 및/또는 리프 오브젝트들을 포함하거나 수집한다. 리프 오브젝트들은 드로잉 오브젝트 또는 조명 오브젝트일 수 있다. 그룹 오브젝트들은, 그들의 그룹에 수집된 오브젝트들을 변환하기 위한 변환 연산들을 가질 수 있다. 드로잉 오브젝트들은 3D 화면의 3D 모델들을 그리기 위한 명령어들 또는 3D 모델들상에 2D 이미지들을 그리기 위한 명령어들을 정의한다. 조명 오브젝트는 3D 화면의 3D 모델들을 조명하는 광 유형 및 방향을 정의한다. API의 오브젝트들로 구성된 컴퓨터 프로그램 오브젝트들의 트리 계층구조를 처리하는 방법이 제공된다. 본 방법은, 그룹 오브젝트들 및 리프 오브젝트들을 처리하기 위해 오브젝트들의 3D 화면 트리 계층구조의 브랜치들을 순회한다. 본 방법은, 처리되지 않은 다음 오브젝트가 그룹 오브젝트인지 아니면 리프 오브젝트인지를 검출한다. 리프 오브젝트이면, 본 방법은, 리프 오브젝트가 광 오브젝트인지 아니면 드로잉 3D 오브젝트인지를 검출한다. 리프 오브젝트가 광 오브젝트이면, 3D 화면의 조명이 설정된다. 드로잉 3D 오브젝트가 검출되면, 조명에 의해 조명되는 대로 3D 모델이 그려진다. 본 방법은 또한, 그룹 오브젝트에 의해 수집된 오브젝트들의 그룹에 대해 그룹 연산을 수행할 수도 있다.

API, 계층구조, 그룹 오브젝트, 리프 오브젝트, 3D, 모델, 그리기, 광

Description

모델 3Ｄ 구성 애플리케이션 프로그램 인터페이스 {MODEL 3D CONSTRUCTION APPLICATION PROGRAM INTERFACE}

본 발명은 일반적으로 컴퓨터 그래픽 분야에 관한 것이다. 보다 구체적으로, 본 발명은 3차원 화면 그래픽을 위한 애플리케이션 프로그램 인터페이스(API)에 관한 것이다.

컴퓨터 시스템 상에서 그래픽을 액세스하는 종래 모델은 한계에 이르렀는데, 이것은 메모리 및 버스의 속도가 메인 프로세서 및/또는 그래픽 프로세서의 발전을 따라가지 못한다는 것이 원인의 일부이다. 일반적으로, 비트맵을 사용하여 프레임을 준비하는 현재 모델은 지나치게 많은 데이터 프로세싱을 요하기 때문에 복잡한 그래픽 효과를 원할 경우 하드웨어 리프레시 속도를 따라갈 수 없다. 그 결과, 종래의 그래픽 모델들을 사용하여 복잡한 그래픽 효과를 시도할 경우에는, 지각된 시각 효과들을 초래하는 변화들을 후속 프레임을 위한 시간 내에 완료하는 대신에, 그러한 변화들이 상이한 프레임들에 걸쳐 추가될 수 있으며, 그로 인해, 시각적으로 바람직하지 못한 결과들이 초래될 수 있다.

또한, 3차원(3D) 그래픽을, 2차원(2D) 이미지와 3D 화면이 혼합된 화면을 디스플레이하는 2D 합성 시스템에 도입하는 것에 의해, 이 문제는 악화된다. 이러한 혼합 시스템을 구현하는 것에 관련된 문제들 중 하나가 3D 모델을 위한 프로그램 오브젝트들을 정의하는 방법이다. 프로그램 오브젝트들은 어떻게 조직되어야 하는가?

본 발명은 이러한 고려들 및 그외의 것들을 참작하여 이루어졌다.

발명의 개요

상기한 문제점들 및 그외의 문제점들은, 컴퓨터 프로그램 오브젝트들에 적용되어 3D 모델들의 3D 화면을 렌더링하기 위한 트리 계층구조(tree hierarchy)를 구성하는 컴퓨터 데이터 구조에 의해 해결된다. 트리 계층구조의 루트 오브젝트는 3D 화면을 위한 오브젝트들을 수집한다. 트리 계층구조의 그룹 오브젝트는 트리 계층구조의 다른 그룹 오브젝트들 및 드로잉 오브젝트들(draw objects)을 수집하며 그룹 오브젝트에 의해 수집된 드로잉 오브젝트들에 대해 작용하는 그룹 연산들(group operations)을 정의한다. 트리 계층구조의 광 오브젝트(light object)는 3D 모델을 3D 화면에 렌더링할 때 사용될 조명을 정의하고, 하나 이상의 드로잉 3D 오브젝트들은 3D 모델을 3D 화면에 그리기 위한 연산들을 정의한다.

본 발명의 다른 양상들에 따르면, 본 발명은 합성 시스템에 의해 렌더링된 3D 모델들의 2D 뷰(view)를 그리기 위한 컴퓨터 프로그램 오브젝트들의 계층구조를 처리하는 방법에 관한 것이다. 본 방법은 그룹 오브젝트들 및 리프 오브젝트들(leaf objects)을 처리하기 위해 오브젝트들의 3D 화면 트리 계층구조의 브랜치들(branches)을 순회한다. 본 방법은, 처리되지 않은 다음 오브젝트가 리프 오브젝트인지 또는 그룹 오브젝트인지를 검출한다. 리프 오브젝트이면, 본 방법은, 리프 오브젝트가 광 오브젝트인지 또는 드로잉 3D 오브젝트인지를 검출한다. 리프 오브젝트가 광 오브젝트이면, 3D 화면의 조명이 설정된다. 드로잉 3D 오브젝트가 검출되면, 조명에 의해 조명되는 대로 3D 모델이 그려진다. 또한, 본 방법은 그룹 오브젝트에 의해 수집된 오브젝트들의 그룹에 대해 그룹 연산을 수행할 수도 있다.

다른 양상들에 따르면, 본 방법은 모델 3D 오브젝트들에 의해 정의된 3D 모델들의 3D 화면을 생성하기 위한 애플리케이션 프로그램 인터페이스에 관한 것이다. 인터페이스는 하나 이상의 그룹 오브젝트들 및 하나 이상의 리프 오브젝트들을 가진다. 그룹 오브젝트들은 다른 그룹 오브젝트들 및/또는 리프 오브젝트들을 포함하거나 수집한다. 리프 오브젝트들은 드로잉 오브젝트들이거나 또는 조명 오브젝트일 수 있다. 그룹 오브젝트들은 그들의 그룹에 수집된 오브젝트들을 변환하기 위한 변환 연산들을 가질 수도 있다. 드로잉 오브젝트들은 3D 화면의 3D 모델들을 그리기 위한 명령어들 또는 3D 모델들상에 2D 이미지들을 그리기 위한 명령어들을 정의한다. 조명 오브젝트는 3D 화면의 3D 모델들을 조명하는 광 유형 및 방향을 정의한다.

본 발명은 컴퓨터 프로세스, 컴퓨팅 시스템, 또는 컴퓨터 프로그램 제품 또는 컴퓨터 판독가능한 매체와 같은 제조물로서 구현될 수 있다. 컴퓨터 판독가능한 매체는 컴퓨터 시스템에 의해 판독가능하며 컴퓨터 프로세스를 실행하기 위한 명령어들의 컴퓨터 프로그램을 인코딩하는 컴퓨터 저장 매체일 수 있다. 또한, 컴퓨터 판독가능한 매체는 컴퓨팅 시스템에 의해 판독가능하며 컴퓨터 프로세스를 실행하기 위한 명령어들의 컴퓨터 프로그램을 인코딩하는 캐리어상의 전파 신호일 수 도 있다.

다음의 상세한 설명 및 관련 도면들의 개요로부터, 본 발명을 특징짓는, 이러한 특징들 및 다양한 그외의 특징들 뿐만 아니라 이점들을 분명히 알 수 있다.

도 1은 본 발명의 일 실시예에 따른 모델 3D 구성 API에서의 관련 오브젝트들에 대한 데이터 구조를 도시한다.

도 2는 본 발명의 실시예들이 구현될 수 있는 적당한 컴퓨팅 시스템 환경의 일례를 도시한다.

도 3은 본 발명이 통합될 수 있는 그래픽 계층 아키텍처를 일반적으로 표현하는 블록도이다.

도 4는 그래픽 커맨드들 및 그외의 데이터를 제공하기 위해 화면 그래프를 순회하는 것에 의한 것과 같이, 화면 그래프를 처리하는 비주얼들(visuals) 및 관련 컴포넌트들의 화면 그래프 표현이다.

도 5는 구성된 평가 비주얼들, 드로잉 비주얼들, 및 관련된 드로잉 프리미티브들의 화면 그래프 표현이다.

도 6은 오토바이를 3D 화면으로 렌더링하기 위한 예시적인 Model3D 트리 계층구조를 도시한다.

도 7은 도 6에 나타낸 것과 같은 3D 화면 트리 계층구조를 처리하기 위한 연산 흐름을 나타낸다.

도 8은 Model3D 그룹 오브젝트에 포함되어 있는 Transform3D 오브젝트들을 위한 관련 오브젝트들의 데이터 구조를 나타낸다.

도 9은 Model3D API의 광 오브젝트를 위한 관련 오브젝트들의 데이터 구조를 나타낸다.

도 1은 본 발명의 일 실시예에 따른 Model3D API를 구현하기 위한 컴퓨터 프로그램 오브젝트들의 아키텍처를 도시한다. Model3D 오브젝트(10)는 루트 또는 추상 오브젝트이다. 루트 오브젝트와 관련된 자식들인 4개의 가능한 Model3D 오브젝트들이 존재한다. Primitive3D 오브젝트(12), Visual Model3D 오브젝트(14), 및 광 오브젝트(16)의 3개 오브젝트들은 이 아키텍처에서의 리프 오브젝트들이다. Model3D Group 오브젝트(18)는 리프 오브젝트들 또는 그외의 그룹 오브젝트들을 위한 트리의 집결 노드이며 또한 Transform3D 오브젝트(20)도 포함한다. Transform3D 오브젝트는 그와 관련된 변환 오브젝트들의 계층구조를 가진다.

Primitive3D 오브젝트는, 프리미티브 3D 오브젝트(12)에 의해 그려지고 있는 3D 모델의 정의를 지원하기 위해 오브젝트들의 계층구조들을 참조하거나 포인팅할 수도 있는 메시 정보(26) 및 재료 정보(28)를 포함한다. Visual Model3D 오브젝트(14)는 3D 화면으로 통합하기 위한 2D 이미지를 정의한다. 광 오브젝트(16)는 3D 화면에 대한 조명을 정의하며 다양한 조명 조건들을 정의하기 위한 오브젝트들의 계층구조를 가진다. 이러한 오브젝트들 모두는 이하에서 Model3D API 정의들에 정의된다.

도 1의 오브젝트들은 모델 3D 화면 트리, 즉, 3D 화면을 렌더링하기 위한 모델 3D 오브젝트들의 트리 계층구조를 구성하는데 사용된다. 3D 화면 트리는 Visual 3D 오브젝트(22) 또는 드로잉 컨텍스트(Drawing Context)(25)를 가진 Visual 2D 오브젝트로부터 Model3D 루트 오브젝트(10)에 입력된다. Visual 3D 오브젝트(22), 및 Visual 2D 오브젝트(24)의 드로잉 컨텍스트(25)는, Model3D 루트 오브젝트(10) 및 카메라 오브젝트(32)를 가리키는 포인터들을 포함한다. Visual 3D 오브젝트의 포인터(33)는 Model3D 루트 오브젝트(10)를 가리킨다. Visual 3D 오브젝트의 포인터(34)는 카메라(Camera) 오브젝트(32)를 가리킨다. Visual 2D 오브젝트(24)의 드로잉 컨텍스트(25)에 포함된 포인터(31)는 Model3D 루트 오브젝트(10)를 포인팅한다. Visual 2D 오브젝트(24)의 드로잉 컨텍스트(25)에 포함된 포인터(35)는 카메라 오브젝트(32)를 포인팅한다.

카메라 오브젝트(32)는, 카메라가 3D 화면을 보는 관점 또는 시점 위치를 정의한다. 카메라 오브젝트(32)는 프로젝션(projection) 카메라 오브젝트(39), 투시(perspective) 카메라 오브젝트(36), 직교(Orthogonal) 카메라 오브젝트(37), 및 Matrix3D 카메라 오브젝트(38)를 포함하는 카메라 오브젝트들의 계층구조를 가진다. 이들 카메라 오브젝트들 각각은 이하에서 Model3D API 정의들에 정의되어 있다.

이하에서 설명되는 도 6은 도 1의 Model3D 오브젝트들을 빌딩 블록들로 사용하여 구성된 3D 화면 트리의 일례이다. 도 6으로부터의 3D 화면을 렌더링하기 위한 연산 흐름은 도 7을 참조하여 이하에서 설명된다. 이제는, 도 2 내지 도 5를 참조하여 본 발명을 구현하기 위한 예시적인 동작 하드웨어 및 소프트웨어 환경을 설명한다.

예시적인 동작 환경

도 2는 본 발명이 구현될 수 있는 적절한 컴퓨팅 시스템 환경(100)의 예를 나타낸다. 컴퓨팅 시스템 환경(100)은 단지 적절한 컴퓨팅 환경의 일 예이며 본 발명의 사용 또는 기능의 범위에 제한을 가하도록 의도된 것은 아니다. 컴퓨팅 환경(100)은 예시적인 오퍼레이팅 환경(100)에 도시된 컴포넌트들 중의 임의의 하나 또는 조합에 관하여 임의의 종속성(dependency) 또는 요구사항(requirement)을 갖는 것으로 해석되어서는 안된다.

본 발명은 많은 다른 범용 또는 특수목적 컴퓨팅 시스템 환경들 또는 구성들과 함께 동작될 수 있다. 본 발명과 함께 사용하기에 적합할 수 있는 잘 알려진 컴퓨팅 시스템, 환경, 및/또는 구성의 예로는, 퍼스널 컴퓨터, 서버 컴퓨터, 핸드헬드(hand-held) 또는 랩탑 장치, 태블릿 장치(tablet devices), 멀티프로세서 시스템, 마이크로프로세서-기반 시스템, 셋 탑 박스(set top box), 프로그램가능한 가전제품(programmable consumer electronics), 네트워크 PC, 미니컴퓨터, 메인프레임 컴퓨터, 상기의 시스템 또는 장치 중의 임의의 것을 포함하는 분산형 컴퓨팅 환경 등이 포함될 수 있지만, 이에 한정되지 않는다.

본 발명은 컴퓨터에 의해 실행되는, 프로그램 모듈과 같은 컴퓨터 실행가능 명령과 일반적으로 관련하여 기술될 수 있다. 일반적으로, 프로그램 모듈은 특정 태스크를 수행하거나 특정 추상 데이터 유형을 구현하는 루틴, 프로그램, 오브젝트, 컴포넌트, 데이터 구조 등을 포함한다. 본 발명은 또한 통신 네트워크를 통해 링크된 원격 프로세싱 장치에 의해 태스크를 수행하는 분산형 컴퓨팅 환경에서 실행될 수 있다. 분산 컴퓨팅 환경에서, 프로그램 모듈들은 메모리 저장 장치를 포함하는 로컬 및 원격 컴퓨터 저장 매체 내에 위치할 수 있다.

도 2를 참조하면, 본 발명을 구현하기 위한 예시적인 시스템은 컴퓨터(110)의 형태의 범용 컴퓨팅 장치를 포함한다. 컴퓨터(110)의 컴포넌트들로는, 프로세싱 유닛(120), 시스템 메모리(130), 및 시스템 메모리를 포함하는 다양한 시스템 컴포넌트를 프로세싱 유닛(120)에 연결시키는 시스템 버스(121)가 포함될 수 있지만, 이에 한정되는 것은 아니다. 시스템 버스(121)는 다양한 버스 아키텍처 중의 임의의 것을 사용하는 로컬 버스, 주변 버스, 및 메모리 버스 또는 메모리 컨트롤러를 포함하는 몇가지 유형의 버스 구조 중의 임의의 것일 수 있다. 예로서, 이러한 아키텍처는 산업 표준 아키텍처(ISA) 버스, 마이크로 채널 아키텍처(MCA) 버스, 인핸스드 ISA(Enhanced ISA; EISA) 버스, 비디오 일렉트로닉스 표준 어소시에이션(VESA) 로컬 버스, 및 메자닌(Mezzanine) 버스로도 알려진 주변 컴포넌트 상호접속(PCI) 버스를 포함하지만, 이에 한정되는 것은 아니다.

컴퓨터(110)는 통상적으로 다양한 컴퓨터 판독가능한 매체를 포함한다. 컴퓨터 판독가능한 매체는 컴퓨터(110)에 의해 액세스될 수 있는 임의의 이용가능한 매체일 수 있으며, 휘발성 및 불휘발성 매체, 분리형(removable) 및 비분리형(non-removable) 매체를 둘다 포함한다. 예로서, 컴퓨터 판독가능한 매체는 컴퓨터 저장 매체 및 통신 매체를 포함할 수 있지만, 이에 한정되는 것은 아니다. 컴퓨터 저장 매체는 컴퓨터 판독가능 명령, 데이터 구조, 프로그램 모듈 또는 그외의 데이터와 같은 정보의 저장을 위한 임의의 방법 또는 기술로 구현되는 휘발성 및 불휘발성, 분리형 및 비분리형 매체를 둘다 포함한다. 컴퓨터 저장 매체는 RAM, ROM, EEPROM, 플래쉬 메모리 또는 기타 메모리 기술, CD-ROM, DVD(digital versatile disk) 또는 기타 광학 디스크 저장장치, 자기 카세트, 자기 테이프, 자기 디스크 저장장치 또는 기타 자기 저장장치, 또는 컴퓨터(110)에 의해 액세스될 수 있고 원하는 정보를 저장하는 데 사용될 수 있는 임의의 기타 매체를 포함할 수 있지만, 이에 한정되지 않는다. 통신 매체는 통상적으로 반송파 또는 기타 전송 메카니즘 등의 변조된 데이터 신호에 컴퓨터 판독가능 명령, 데이터 구조, 프로그램 모듈, 또는 다른 데이터를 구현하며, 임의의 정보 전달 매체를 포함한다. "변조된 데이터 신호"라는 용어는 신호 내에 정보를 인코딩하도록 설정되거나 변환된 특성을 하나 또는 그 이상을 갖는 신호를 의미한다. 예로서, 통신 매체는 유선 네트워크 또는 직접 유선 접속 등의 유선 매체와, 음향, RF, 적외선 및 기타 무선 매체 등의 무선 매체를 포함하지만, 이에 한정되지 않는다. 상술한 것들 중의 임의의 조합이 컴퓨터 판독가능한 매체의 범위 내에 포함되어야 한다.

시스템 메모리(130)는 ROM(131) 및 RAM(132) 등의 휘발성 및/또는 불휘발성 메모리의 형태의 컴퓨터 저장 매체를 포함한다. 기동 중과 같은 때에 컴퓨터(110) 내의 엘리먼트들간에 정보를 전송하는 것을 돕는 기본 루틴을 포함하는 기본 입출력 시스템(133; BIOS)은 일반적으로 ROM(131)에 저장된다. RAM(132)은 일반적으로 프로세싱 유닛(120)에 즉시 액세스될 수 있고 및/또는 프로세싱 유닛(120)에 의해 현재 작동되는 프로그램 모듈 및/또는 데이터를 포함한다. 예로서, 도 2는 오퍼레이팅 시스템(134), 애플리케이션 프로그램(135), 기타 프로그램 모듈(136), 및 프로그램 데이터(137)를 도시하며, 이에 한정되는 것은 아니다.

컴퓨터(110)는 또한 다른 분리형/비분리형, 휘발성/불휘발성 컴퓨터 저장 매체를 포함할 수 있다. 단지 예로서, 도 2에는 비분리형 불휘발성 자기 매체로부터 판독하거나 그 자기 매체에 기입하는 하드 디스크 드라이브(141), 분리형 불휘발성 자기 디스크(152)로부터 판독하거나 그 자기 디스크에 기입하는 자기 디스크 드라이브(151), 및 CD-ROM 또는 기타 광학 매체 등의 분리형 불휘발성 광학 디스크(156)로부터 판독하거나 그 광학 디스크에 기입하는 광학 디스크 드라이브(155)가 도시되어 있다. 예시적인 오퍼레이팅 환경에서 사용될 수 있는 그외의 분리형/비분리형, 휘발성/불휘발성 컴퓨터 저장 매체는 자기 테이프 카세트, 플래쉬 메모리 카드, DVD(Digital versatile disk), 디지털 비디오 테이프, 고상 RAM, 고상 ROM 등을 포함하지만 이에 한정되지 않는다. 하드 디스크 드라이브(141)는 일반적으로 인터페이스(140)와 같은 비분리형 메모리 인터페이스를 통해 시스템 버스(121)에 접속되고, 자기 디스크 드라이브(151) 및 광학 디스크 드라이브(155)는 일반적으로 인터페이스(150)와 같은 분리형 메모리 인터페이스에 의해 시스템 버스(121)에 접속된다.

앞서 기술되고 도 2에 도시된 드라이브 및 그 관련 컴퓨터 저장 매체는 컴퓨터(110)를 위한 컴퓨터 판독가능 명령, 데이터 구조, 프로그램 모듈 및 기타 데이터의 저장을 제공한다. 도 2에서, 예를 들어, 하드 디스크 드라이브(141)는 오퍼레이팅 시스템(144), 애플리케이션 프로그램(145), 기타 프로그램 모듈(146), 및 프로그램 데이터(147)를 저장하는 것으로 도시된다. 이들 컴포넌트는 오퍼레이팅 시스템(134), 애플리케이션 프로그램(135), 기타 프로그램 모듈(136), 및 프로그램 데이터(137)와 동일할 수도 있고 다를 수도 있다. 오퍼레이팅 시스템(144), 애플리케이션 프로그램(145), 기타 프로그램 모듈(146), 및 프로그램 데이터(147)는 최소한 다른 복사본(different copies)임을 나타내기 위하여 다른 번호를 부여하였다. 사용자는 일반적으로 마우스, 트랙볼, 또는 터치 패드라 불리우는, 태블릿(전자 디지타이저)(164), 마이크로폰(163), 키보드(162) 및 포인팅 장치(161)와 같은 입력 장치를 통해 컴퓨터(110)에 커맨드 및 정보를 입력할 수 있다. (도시되지 않은) 기타 입력 장치는 조이스틱, 게임 패드, 위성 안테나, 스캐너 등을 포함할 수 있다. 이들 입력 장치 및 그외의 입력 장치는 시스템 버스에 연결된 사용자 입력 인터페이스(160)를 통해 종종 프로세싱 유닛(120)에 접속되지만, 병렬 포트, 게임 포트 또는 유니버설 시리얼 포트(USB) 와 같은 기타 인터페이스 및 버스 구조에 의해 접속될 수 있다. 모니터(191) 또는 다른 유형의 디스플레이 장치는 또한 비디오 인터페이스(190) 등의 인터페이스를 통해 시스템 버스(121)에 접속된다.

모니터(191)는, 터치스크린 인터페이스(192)와 같은 인터페이스를 통해 컴퓨터 시스템으로 핸드라이팅하는 것과 같은 디지탈화된 입력을 입력할 수 있는 터치 스크린 패널(193) 등과 함께 집적될 수 있다. 모니터 및/또는 터치 스크린 패널은 태블릿형 퍼스널 컴퓨터와 같은, 컴퓨팅 디바이스가 포함되는 하우징에 물리적으로 연결될 수 있으며, 터치 스크린 패널(193)은 본질적으로 태블릿(164)으로 기능한다는 점을 유의한다. 또한, 컴퓨팅 디바이스(110)와 같은 컴퓨터들은, 출력 주변 인터페이스(194) 등을 통해 접속될 수 있는, 스피커(195) 및 프린터(196) 등의 기타 주변 출력 장치를 포함할 수 있다.

컴퓨터(110)는 원격 컴퓨터(180)와 같은 하나 이상의 원격 컴퓨터로의 논리적 접속을 이용한 네트워크 환경에서 동작할 수 있다. 원격 컴퓨터(180)는 퍼스널 컴퓨터, 서버, 라우터, 네트워크 PC, 피어(peer) 장치, 또는 기타 공통 네트워크 노드일 수 있으며, 비록 도 2 에는 메모리 저장 장치(181)만이 도시되어 있지만, 컴퓨터(110)에 관하여 상술한 구성요소들 중 다수 또는 모든 구성요소를 일반적으로 포함할 수 있다. 도 2에 도시된 논리적 접속은 근거리 통신망(LAN; 171) 및 원거리 통신망(WAN; 173)을 포함하지만, 그 외의 네트워크를 포함할 수도 있다. 이러한 네트워크 환경은 사무실, 기업 광역 컴퓨터 네트워크(enterprise-wide computer network), 인트라넷, 및 인터넷에서 일반적인 것이다.

LAN 네트워크 환경에서 사용되는 경우, 컴퓨터(110)는 네트워크 인터페이스 또는 어댑터(170)를 통해 LAN(171)에 접속된다. WAN 네트워크 환경에서 사용되는 경우, 컴퓨터(110)는 일반적으로 인터넷 등의 WAN(173)을 통해 통신을 구축하기 위한 모뎀(172) 또는 기타 수단을 포함한다. 내장형 또는 외장형일 수 있는 모뎀(172)은 사용자 입력 인터페이스(160) 또는 기타 적절한 메카니즘을 통해 시스템 버스(121)에 접속될 수 있다. 네트워크 환경에서, 컴퓨터(110)에 관하여 도시된 프로그램 모듈 또는 그 일부분은 원격 메모리 저장 장치에 저장될 수 있다. 예로서 (한정하고자 하는 것은 아님), 도 1은 메모리 장치(181)에 상주하는 원격 애플리케이션 프로그램(185)을 도시한다. 도시된 네트워크 접속은 예시적인 것이며, 컴퓨터들간의 통신 링크를 구축하는 그 외의 수단이 사용될 수 있다.

비주얼 트리 계층구조를 처리하기 위한 소프트웨어 환경

도 3은, 비주얼 트리들이 처리될 수 있는 일반적인 계층형 아키텍처(200)를 표현한다. 도 3에 표현된 바와 같이, 프로그램 코드(202)(예를 들어, 애플리케이션 프로그램 또는 오퍼레이팅 시스템 컴포넌트 등)는, 본 발명의 일 양상에 따라, 이미징(204)을 통하는 것, 벡터 그래픽 엘리먼트들(206)을 통하는 것, 및/또는 비주얼 API(application programming interface) 계층(212)에 직접적으로 배치되어 있는 함수/방법 호출들을 통하는 것을 포함하는 하나 이상의 다양한 방법들로 그래픽 데이터를 출력하도록 개발될 수 있다. 일반적으로, 이미징(204)은 프로그램 코드(202)에, 이미지들 예를 들어, 비트맵들을 로딩, 편집, 및 보존하는 메커니즘을 제공한다. 후술하는 바와 같이, 이미지들은 시스템의 다른 부분들에 의해 사용될 수 있으며, 프리미티브 드로잉 코드(primitive drawing code)를 사용하여 이미지를 직접적으로 그리는 방법도 있다. 벡터 그래픽 엘리먼트들(206)은, (후술하는) 나머지 오브젝트 모델과 일치하는, 그래픽을 그리기 위한 다른 방법을 제공한다. 벡터 그래픽 엘리먼트들(206)은 마크업 언어를 통해 생성될 수 있는데, 엘리먼트/속성 시스템(208) 및 프리젠터 시스템(210)은 마크업 언어를 해석하여 비주얼 API 계층(212)으로의 적절한 호출들을 행한다.

그래픽 계층 아키텍처(200)는, 캐싱 데이터 구조(216)를 포함하거나 또는 캐싱 데이터 구조(216)와 관련되어 있는 고급의 합성 및 애니메이션 엔진(214)을 포함한다. 캐싱 데이터 구조(216)는, 후술하는 바와 같이, 정의된 오브젝트 모델에 따라 관리되는 계층-정렬된 오브젝트들을 포함하는 화면 그래프(scene graph)를 포함한다. 일반적으로, 비주얼 API 계층(212)은, 오브젝트들을 생성하고 오브젝트들에 데이터를 제공하기 위해 오브젝트들을 개방하고 폐쇄하는 능력 등을 포함하여, 프로그램 코드(202)(및 프리젠터 시스템(210))에 캐싱 데이터 구조(216)로의 인터페이스를 제공한다. 다시 말해, 고급의 합성 및 애니메이션 엔진(214)은, 개발자들이 그래픽 정보를 디스플레이하기 위한 그래픽 및 매체에 관한 의도들을 표현할 수 있고, 플랫폼이 프로그램 코드에 대한 하드웨어 사용을 최적화할 수 있는 충분한 정보를 하부 플랫폼에 제공할 수 있는 일체화된 매체 API 계층(212)을 노출시킨다. 예를 들어, 하부 플랫폼은 캐싱, 리소스 협상(resource negotiation), 및 매체 통합을 책임질 것이다.

고급의 합성 및 애니메이션 엔진(214)은 명령어 스트림 및 가능한 그외의 데이터(예를 들어, 비트맵들로의 포인터들)를 고속의 저급 합성 및 애니메이션 엔진(218)으로 전달한다. 여기에서 사용되는 바와 같이, "고급" 및 "저급"이라는 용어들은, 일반적으로, 고급인 컴포넌트들에 비해 소프트웨어 컴포넌트가 저급일수록, 그 컴포넌트가 하드웨어에 근접하다는 것을 의미하는, 그외의 컴퓨팅 상황들에서 사용되는 것들과 유사하다. 따라서, 예를 들어, 고급의 합성 및 애니메이션 엔진(214)으로부터 송신된 그래픽 정보는, 그 정보가 하드웨어(222)를 포함하는 그래픽 서브 시스템(222)으로 그래픽 데이터를 송신하는데 사용되는 저급의 합성 및 애니메이션 엔진(218)에서 수신될 수 있다.

고급의 합성 및 애니메이션 엔진(214)은 프로그램 코드(202)와 함께 프로그램 코드(202)에 의해 제공되는 그래픽 화면을 표현하기 위한 화면 그래프를 구축한다. 예를 들어, 그려질 각각의 항목은, 시스템이 화면 그래프 데이터 구조(216)에 캐싱할 수 있는 드로잉 명령어들을 사용하여 로딩될 수 있다. 후술하는 바와 같이, 이러한 데이터 구조(216) 및 그려질 것을 특정하는 다수의 다양한 방법들이 존재한다. 또한, 고급의 합성 및 애니메이션 엔진(214)은 타이밍 및 애니메이션 시스템들(220)과 통합되어 선언적(또는 그외의) 애니메이션 제어(예를 들어, 애니메이션 구간들) 및 타이밍 제어를 제공한다. 애니메이션 시스템으로 인해 애니메이트 값들(animate values)은, 예를 들어, 엘리먼트 속성 레벨(208), 비주얼 API 계층(212) 내부, 및 나머지 리소스들 중 임의의 것을 포함하는, 본질적으로 시스템의 어느 곳으로든 전달될 수 있다. 타이밍 시스템은 엘리먼트 및 비주얼 레벨들에서 노출된다.

저급의 합성 및 애니메이션 엔진(218)은, 그 다음에 그래픽 서브 시스템(222)으로 제공될 화면의 합성, 애니메이팅, 및 렌더링을 관리한다. 저급 엔진(218)은 다수 애플리케이션들의 화면들을 위한 렌더링들을 합성하고, 렌더링 컴포넌트들을 사용해, 스크린으로의 실제 그래픽 렌더링을 구현한다. 그러나, 가끔은 일부 렌더링이 보다 높은 레벨에서 발생하는 것이 필요하거나 및/또는 유용할 수 있다. 예를 들어, 보다 낮은 계층들이 다수 애플리케이션들로부터의 요청들을 서비스하는 동안, 보다 높은 계층들은 매 애플리케이션 기반으로 개시됨으로써, 이미징 메커니즘들(204)에 의해 시간 소모적이거나 애플리케이션-특정인 렌더링을 보다 높은 레벨들에서 수행하고 비트맵에 대한 참조들은 보다 낮은 계층들로 전달할 수 있다.

도 4 및 도 5는, 각각, 비주얼(visual)이라고 하는 기본 오브젝트를 포함하는 예시적 화면 그래프들(300 및 400)을 나타낸다. 일반적으로, 비주얼은 사용자에게 시각적인 표면(visual surface)을 표현하는 오브젝트를 포함하며 디스플레이상의 시각적 표현을 가진다. 도 4에 표현된 바와 같이, 최상(또는 루트) 비주얼(302)은 비주얼 관리자 오브젝트(304)에 접속되고, 비주얼 관리자 오브젝트(304) 또한 프로그램 코드를 위한 그래픽 데이터가 출력되는 윈도우(HWnd)(306) 또는 유사 유닛과 (예를 들어, 핸들을 통해) 관련이 있다. 비주얼 관리자(304)는 해당 윈도우(306)에 대한 최상 비주얼(및 그 비주얼의 임의 자식들)의 드로잉을 관리한다. 그리기 위해, 비주얼 관리자(304)는 디스패처(dispatcher)(308)에 의해 스케줄링된대로 화면 그래프를 처리(예를 들어, 순회 또는 전송)하고, 저급 컴포넌트(218)(도 3)로의 그래픽 명령어들 및 그외의 데이터를 그에 대응되는 Window(306)에 제공한다. 화면 그래프 프로세싱은 통상적으로, 저급 컴포넌트(308) 및/또는 그래픽 서브 시스템(222)의 리프레시 속도보다 상대적으로 느린 속도로 디스패처(308)에 의해 스케줄링된다. 도 4는 최상(루트) 비주얼(302) 아래에 계층적으로 정렬되어 있는 다수의 자식 비주얼들(310 내지 315)을 나타내는데, 그들 중 일부는, 각각, 예를 들어, 드로잉 프리미티브(drawing primitives) 및 그외의 비주얼들을 포함하는 명령어 리스트들(instruction lists)(318 및 319) 각각과 관련되어 있는 드로잉 컨텍스트들(316, 317)에 의해 채워져 있는 것으로(그들의 순간 속성을 나타내는 빗금친 박스들로 도시됨) 표현되어 있다. 또한, 비주얼들은, 다음의 예시적 비주얼 클래스에 나타낸 바와 같이, 그외의 속성 정보를 포함할 수도 있다:

알 수 있는 바와 같이, 비주얼들은 변환(transform), 클립(clip), 불투명도(opacity), 및 겟(get) 방법에 의해 설정 및/또는 판독될 수 있는 가능한 그외의 속성들을 제공하는 것에 의해 서비스들을 제공한다. 또한, 비주얼은, 비주얼이 히트(hit) 테스팅에 참여하는 방법을 제어하는 플래그들을 가진다. 쇼(Show) 속성은 비주얼을 나타내거나/숨기는데 사용되어, 예를 들어, 거짓인 경우에는 비주얼이 보이지 않거나, 그렇지 않은 경우에는 비주얼이 보인다.

변환 속성에 의해 설정되는 변환은 비주얼의 서브-그래프를 위한 좌표계를 정의한다. 변환 전의 좌표계를 변환 전(pre-transform) 좌표계라 하고, 변환 후의 좌표계를 변환 후(post-transform) 좌표계라 하는데, 다시 말해, 변환을 가진 비주얼은 변환 노드를 부모로서 가진 비주얼과 등가이다. 위에서 상호 참조하는 "VISUAL AND SCENE GRAPH INTERFACE"라는 명칭의 관련 특허 출원에, 비주얼 트리 및 합성 시스템의 좀더 완전한 설명이 포함되어 있다.

Model 3D API 프로세싱

도 6은, 이 경우에서는 오토바이인, 3D 화면의 2차원 뷰를 렌더링하기 위한 Model3D API로 구성된 예시적 3D 화면의 트리 계층구조를 나타낸다. 트리는 Model3D API에서의 다양한 구조적 데이터 오브젝트들의 사용을 도시한다. 오토바이를 위한 트리의 추상 또는 루트 노드는 오브젝트(602)이다. 추상 오브젝트는 광(light) 오브젝트(604), 바디 그룹(body group) 오브젝트(606), 휠 그룹(휠 그룹) 오브젝트(608), 및 Instruments Visual Model3D 오브젝트(610)의 4개 자식들을 가진다.

바디 그룹 오브젝트는, 오토바이의 바디를 구성하는 3개 자식들, 즉 프레임 프리미티브 오브젝트(612), 엔진 프리미티브 오브젝트(614), 및 가스 탱크 프리미티브 오브젝트(616)를 가진다. 이들 프리미티브 오브젝트들 각각은 오브젝트에 대해 명명된 오토바이 바디 엘리먼트들을 그릴 것이다. 휠 그룹 오브젝트(608)는 전면 휠 그룹 오브젝트(618) 및 후면 휠 그룹 오브젝트(620)를 수집한다. 휠 프리미티브(wheel primitive) 오브젝트(624)는 휠의 3D 모델을 그린다. 전면 휠 그룹 오브젝트(618)는, 휠 프리미티브 오브젝트(624)에 의해 그려질 휠을 전면 휠로 변환하는 3D Transform(619)을 가진다. 마찬가지로, 후면 휠 그룹 오브젝트(620)는, 휠 프리미티브 오브젝트(624)에 의해 그려질 휠을 후면 휠로 변환하는 3D Transform(621)을 가진다. 그외에, 휠 그룹 오브젝트(608)에 포함된 3D Transform(622)이 있다. 변환 오브젝트(622)는, 예를 들어, 전면 프리미티브 오브젝트(618) 및 후면 프리미티브 오브젝트(620)의 실행을 애니메이션 효과를 위해 휠을 회전시키도록 변환할 수 있다.

Model3D 오브젝트들의 이러한 예시적 트리는 도 7에 도시되어 있는 논리적 연산들의 연산 흐름에 의해 처리될 수 있다. 본 발명의 실시예들에 대한 논리적 연산들은 (1) 컴퓨팅 시스템상에서 실행되는 컴퓨터 구현 동작들 또는 프로그램 모듈들의 시퀀스로서 및/또는 (2) 컴퓨팅 시스템 내에서 상호 접속되어 있는 머신 논리 회로들 또는 회로 모듈들로서 구현된다. 구현은, 본 발명을 구현하는 컴퓨팅 시스템의 성능 요구사항들에 따른 선택의 문제이다. 따라서, 여기에 설명되어 있는 본 발명의 실시예들을 구성하는 논리적 연산들은 연산들, 구조적 장치들, 동작들, 또는 모듈들로서 다양하게 언급될 수 있다. 당업자라면, 이러한 연산들, 구조적 장치들, 동작들, 및 모듈들이, 여기에 첨부되어 있는 청구항들에 상술되어 있는 본 발명의 정신 및 범위를 벗어나지 않으면서, 소프트웨어, 펌웨어, 특수 목적의 디지털 로직, 및 이들의 임의의 조합으로 구현될 수 있다는 것을 알 수 있다.

도 7에서, 연산 흐름은 카메라 뷰 연산(702)을 설정하는 것으로 시작된다. 카메라 위치는 Visual3D 오브젝트(22)(도 1)에 의해 제공된다. 순회 연산(704)은, 오브젝트에 도달할 때까지, 트리의 브랜치를 이동해 내려간다. 통상적으로, 트리는 아래로 그리고 왼쪽에서 오른쪽으로 순회된다. 그룹 테스트 연산(706)은, 오브젝트가 그룹 오브젝트인지 아니면 리프 오브젝트인지를 검출한다. 오브젝트가 그룹 오브젝트이면, 연산 흐름은 분기되어 그룹 오브젝트 연산(708)을 처리한다. 연산(708)은 오브젝트에 포함되어 있는 임의의 그룹 연산을 처리할 것이다. Transform 3D 연산들이 그룹 연산들의 예들이다. 더 많은 오브젝트들이 있는지의 테스트 연산(710)은, 트리에 추가 오브젝트들이 존재하는지의 여부를 검출하며 적어도 다른 오브젝트가 존재하면 흐름은 순회 연산(704)으로 복귀된다.

다음 오브젝트가 리프 오브젝트이면, 연산 흐름은 그룹 테스트 연산(706)에서 광 오브젝트 테스트 연산(712)으로 분기한다. 리프 오브젝트가 광 오브젝트이면, 연산 흐름은 광 오브젝트 테스트 연산(712)으로부터 예로 분기하여 조명 연산(714)을 설정한다. 이 연산(714)은 광 오브젝트를 처리하여 3D 화면을 위한 조명을 설정한다. 그 다음, 이 연산은 더 많은 리프 오브젝트들 테스트 연산(716)으로 진행한다. 리프 오브젝트가 광 오브젝트가 아니면, 연산 흐름은 프리미티브/비주얼 모델 오브젝트 테스트 연산(718)으로 전달된다. 리프 오브젝트가 프리미티브 오브젝트이면, 연산 흐름은 프리미티브 드로잉 연산(720)으로 분기하고, 그 다음에는 더 많은 리프 오브젝트들 테스트 연산(716)으로 분기한다. 프리미티브 드로잉 연산(720)은 프리미티브 오브젝트에 의해 특정된 3D 모델을 그릴 것이다. 리프 오브젝트가 Visual Model3D 오브젝트이면, 연산 흐름은 비주얼 모델 드로잉 연산(722)으로 분기하고, 그 다음에는 더 많은 리프 오브젝트들 테스트 연산(716)으로 분기한다. 비주얼 모델 드로잉 연산(722)은 Visual Model 3D 오브젝트에 의해 특정된 비주얼 모델을 그릴 것이다.

더 많은 리프 오브젝트들 테스트 연산(716)은, 그룹에 더 많은 리프 오브젝트들이 존재한다면, 연산 흐름은 리프 순회 연산(724)으로 분기한다. 순회 연산(724)은 동일한 그룹 오브젝트하의 다음 자식으로 트리를 순회시킨다. 광 오브젝트 테스트 연산(712) 및 프리미티브/비주얼 모델 테스트 연산(718)은, 다음 리프가 광 오브젝트, 프리미티브 오브젝트, 또는 비주얼 모델 오브젝트인지를 검출한다. 검출된 리프 오브젝트는 위에서 설명한 바와 같이 반복하여 처리된다. 동일한 그룹 오브젝트의 자식들인 모든 리프 오브젝트들이 처리된 후에, 연산 흐름은 테스트 연산(716)으로부터의 아니오를 통해 더 많은 오브젝트들 테스트 연산(710)으로 분기한다. 처리할 더 많은 오브젝트들이 존재하면, 연산 흐름은 순회 연산(704)으로 복귀한다. 그렇지 않으면, 모델 3D 트리는 처리 완료되었으며, 연산 흐름은 복귀(726)를 통해 다시 3D 화면의 프로세싱의 호출자에게로 전달된다.

도 6의 3D 화면 트리의 예에서, 도달된 제1 오브젝트는 광 오브젝트이다. 이하의 Model3D API 정의들에 정의되어 있는 바와 같이, 광 오브젝트는 3D 화면을 조명하는 광의 유형을 특정한다. 제1 리프 노트인 광 오브젝트에 도달될 때, 그룹 오브젝트 테스트 연산(706)은, 오브젝트가 리프 오브젝트라는 것을 검출하며, 연산 흐름은 광 오브젝트 테스트 연산(708)으로 분기한다. 테스트 연산(708)에 의해 광 오브젝트(604)가 검출되고, 설정된 조명 연산(714)이 광 오브젝트에 의해 수행되어 3D 화면의 조명이 설정된다. 그 다음, 흐름은 더 많은 리프 오브젝트들 테스트 연산(716) 및 더 많은 오브젝트들 테스트 연산(710)을 통해 순회 연산(704)으로 복귀한다.

순회 연산(704)은 도 6의 트리를 아래로 순회하여 바디 그룹 오브젝트(606)로 순회한다. 그룹 테스트 연산은 이제, 바디 그룹을 위한 그룹 오브젝트(606)에서의 임의의 연산들을 수행하기 위한 그룹 프로세스 연산(708)으로 분기한다. 그 다음, 흐름은 순회 연산(704)으로 다시 복귀하며, 순회 연산은 바디 그룹 오브젝트(606)로부터의 브랜치를 프레임 프리미티브 오브젝트(602)로 이동시킬 것이다. 프레임 프리미티브 오브젝트(602)는, 연산 흐름이 테스트 연산들(706, 712, 및 718)을 통해 분기한 후, 상술한 바와 같이 프리미티브 드로잉 연산(720)에 의해 처리될 것이다. 엔진 프리미티브 오브젝트(614) 및 가스 탱크 프리미티브 오브젝트(616)는, 더 많은 리프 오브젝트들 테스트(716), 후속 리프 오브젝트로의 순회 연산(724), 및 테스트 연산들(712 및 718)을 통해 연산 흐름이 다시 순환함에 따라, 차례로 처리될 것이다. 바디 그룹 오브젝트 노드(606)로부터의 모든 리프들이 처리되었을 때, 순회 연산(704)은 트리를 휠 그룹 오브젝트(608)로 순회시킬 것이다.

휠 그룹 오브젝트 및 그 자식들의 프로세싱은, 휠 그룹 오브젝트(608)가 Transform3D 오브젝트(622)를 포함한다는 점을 제외하면, 바디 그룹 오브젝트 및 그 자식들의 프로세싱과 동일하다. Transform3D 오브젝트는 오토바이 이미지의 휠들을 애니메이션화하는데 사용될 것이다. 휠 그룹 오브젝트(608)를 처리할 경우, 연산 흐름은, Transform3D 오브젝트(622)의 검출시에, 그룹 오브젝트들 테스트 연산(706)으로부터 그룹 프로세스 연산(708)로 분기할 것이다. 그룹 프로세스 연산(708)은 오브젝트(622)의 변환 연산들을 실행시켜 오토바이의 휠들을 회전시킬 것이다.

처리될 도 6의 예시적인 3D 화면에서의 마지막 목적은 Instruments Visual Model3D 오브젝트(610)이다. 트리의 휠 그룹 브랜치가 처리된 후, 순회 연산(704)은 트리를 기구 오브젝트(610)로 순회시킬 것이다. 도 7의 연산 흐름에서, Instruments Visual Model3D 오브젝트(610)를 검출했을 때, 흐름은, 테스트 연산들(706, 712, 및 718)을 통해 비주얼 모델 드로잉 연산(722)으로 전달된다. 비주얼 모델 드로잉 연산(722)은 오브젝트(610)에 의해 특정된 비주얼 모델을 그린다. 이로써, 도 7의 연산들에 의한 도 6의 3D 화면 트리에 대한 프로세싱이 완결된다.

Model 3D API 정의들

Model 3D 오브젝트들을 위해 다음의 API들이 정의된다.

도 1의 오브젝트(22)와 같은 Visual3D 오브젝트는 실질적으로 이하의 것들이다:

ㆍ 광들을 포함하는 한 세트의 3D(렌더링 명령어들/화면 그래프/메타파일),

ㆍ 그 화면의 2D 프로젝션을 정의하기 위한 카메라,

ㆍ 프로젝션을 매핑하기 위한 로컬 좌표 공간에서의 직사각형 2D 뷰포트, 및

ㆍ 안티에일리어싱(antialiasing) 스위치들, 포그(fog) 스위치들 등과 같은, 그외의 주변 파라미터들일 뿐이다.

3D로의 렌더링

2D와 마찬가지로, 렌더링은, 겟 호출들이 이루어지는 DrawingContext를 통해 발생한다. 예를 들어, 2D에서는 다음과 같다.

2D와의 일관성을 위한, 3D의 유사 모델은 다음과 같다.

이러한 렌더링 모델은 ("명령어들"이 단순히 보존되는) 3D 비주얼의 보류 모드(retained mode) 및 (렌더링이 직접적으로 발생하며 카메라가 앞줄에 설치되어야 하는) 3D 비주얼의 즉시 모드(immediate mode) 양자에 대해 양호하게 작용한다. 실제로, 보류 모드의 경우에서, 내부적으로 발생하는 것은 3D 모델링 계층구조가 구축되어 보류되는 것이다. 다른 방법으로, 즉시 모드의 경우에서는, 이러한 일이 발생하지 않으며, 명령어들은 직접적으로 발행되고, (예를 들어, 변환을 위한) 콘텍스트 스택이 유지되고 있다.

샘플 코드

3D Visual API를 사용하는 프로그래밍의 묘미를 보여주는 일례가 있다.

이 예는 단지, 드로잉 컨텍스트를 렌더링에 이용하며, 프리미티브들 및 광들을 그것에 렌더링하고, 카메라를 설정하고, 비주얼을 제어의 비주얼 자식들에게 추가하는 Visual3D를 생성했다.

모델링 API들

상기의 것은, 드로잉 "명령어들"이 콘텍스트로 발행되는 "명령적 렌더링(imperative rendering)" 스타일의 이용을 나타낸다. 이것은 선언적 이용(declarative usage)이 아니며, 엘리먼트/마크업 섹션에 이르렀을 때, 이러한 명령적 접근이 선언적 마크업에는 적절하지 않다는 것을 알게 될 것이다.

따라서, 2D에 존재하는 Brushes, Pens, Geometry, Paths 등과 같은 3D "리소스들"을 구축하고 사용하는 선언적 방법이 존재한다.

그 목적을 위해, 사용자들이 3D 명령어 스트림으로 진행하는 것을 구성할 수 있게 하는 다수의 유형들이 도입되며, 구성된 오브젝트는 콘텍스트를 사용하는 대신에 Visual3D로 설정될 수 있다.

예를 들어, 상기 Drawing3DContext-기반의 샘플 코드는 다음과 같이 재기입될 수 있다.

여기에서는 정말로 모델을 구축한 다음 그것을 Visual3D로 할당한다. PushTransform/Pop 쌍들은, 자체가 그 아래에 변환 및 모델들을 가진 Model3DGroup의 구성으로 대체된다.

게다가, 이러한 모델링 접근과 명령적 콘텍스트-기반 접근 모두가 제공하는 요점은 혼란시키려는 것이 아니라, 오히려 이하의 사항들에 대한 해결책을 제공하려는 것이다.

ㆍ 엘리먼트-레벨의 선언적 마크업

ㆍ 비주얼 열거

ㆍ 화면 그래프 효과들

ㆍ 비주얼 컨텐츠의 수정 용이성

모델링 클래스 계층구조

도 1은 모델링 클래스의 계층구조를 도시한다. 모델링 클래스 트리의 루트는 Model3D인데, 이는 Visual3D에 첨부될 수 있는 3차원 모델을 표현한다. 궁극적으로, 광들, 메시들, (파일, 리소스, 메모리 등으로부터 유래할 수 있는) .X 파일 스트림들, 모델들의 그룹들, 및 3D-배치형 2D 비주얼들 모두가 모델들이다. 따라서, 다음의 계층구조를 갖는다.

Model3D 클래스 자체는 다음의 연산들을 지원한다.

ㆍ 3D 바운딩 박스를 취하기

ㆍ Model3D의 변환을 취하여 설정하기

ㆍ 음영 모드와 같은, "노드" 레벨의 다른 속성들을 취하여 설정하기

ㆍ hitTestObject를 취하여 설정하기

비주얼 API 규격들

먼저, 각각의 유형에 대해 명시적으로 열거되어 있지는 않지만, 이들 유형들 모두는 (여기에서는 Vector3D에 대해 표시되어 있지만, 다른 모두에 대해서도 적용될 수 있는) 다음의 방법들을 가진다.

또한, (직접적으로 또는 간접적으로) Changeable로부터 유도되는 모든 유형은 그 안에 "public new MyType Copy()" 방법을 가져야 할 것이다.

프리미티브 유형들

이들 프리미티브 유형들은 단순히 이 섹션에 설명되어 있는 다른 유형들을 지원하기 위해 존재한다.

Point3D

Point3D는 2D Point 유형의 System.Windows.Point에 직접적으로 대응된다.

TypeConverter 규격

Vector3D

Vector3D는 2D Vector 유형의 System.Windows.Vector에 직접적으로 대응된다.

TypeConverter 규격

Point4D

Point4D는 3D 포인트에 네번째 w 컴포넌트가 부가된 것으로, 논-어파인(non-affine) Matrix3D 변환을 통해 변환하는데 사용된다. 1의 'w' 컴포넌트는 Point3D로 변환되고 0의 'w' 컴포넌트는 Vector3D로 변환되기 때문에, Vector4D는 존재하지 않는다.

TypeConverter 규격

사원수(Quaternion)

사원수들은 3차원에서의 회전을 표현하는 명백한 3D 실체들이다. 이들의 힘은 사원수들간을 보간하여(그리고 그에 따라 애니메이션화하여) 부드러우면서 신뢰할 수 있는 보간을 실현할 수 있다는 것에 있다. 특정한 보간 메커니즘은 SLERP(Spherical Linear Interpolation)으로 공지되어 있다.

사원수들은 그들의 컴포넌트들(x,y,z,w)의 직접적인 구체화로부터 구성되거나, 또는 축/각도 표현으로서 구성될 수 있다. 제1 표현은, 소정 연산들이 적용되지 않는(예를 들어, 축 및 각도를 추출하는 연산) 비정규화 사원수들을 초래할 수 있다.

사원수의 컴포넌트들은, 사원수이 구성되고 나면 설정될 수 없는데, 그 이유는, 그렇게 하면 잠재적 모호성이 존재하기 때문이다. (예를 들어, 비정규화 사원수에 대해 각도를 설정하는 것은 무엇을 의미하는가?)

TypeConverter 규격

Matrix3D

Matrix3D는 System.Windows.Matrix에 대응되는 3D이다. Matrix와 마찬가지로, 대부분의 API들은 Matrix3D를 취하기 보다는, 심오한 방식으로 애니메이션을 지원하는 Transform3D를 취한다.

3D 계산을 위한 행렬들은 4×4 행렬로서 표현된다. MIL은 행-벡터 구문(row-vector syntax)을 사용한다.

행렬에 포인트가 곱해지면, 행렬은 그 포인트를 새로운 좌표계에서 이전의 좌표계로 변환한다.

변환들은 임의 수준으로 내포될 수 있다. 새로운 변환이 적용될 때마다, 그것은 현재의 변환 행렬에 그것을 먼저 곱하는 것(pre-multiplying)과 같다.

TypeConverter 규격

Transform3D 클래스 계층구조

2D 변환과 마찬가지로, Transform3D는 3D 변환의 특정 유형들을 표현하는 구체적인 서브 클래스들을 갖는 추상적 기본 클래스이다.

Transform3D의 특정한 서브 클래스들 또한 애니메이션이 유래하는 곳이다.

Transform3D의 전반적 계층구조는 다음과 같으며 도 8에 도시되어 있다.

Transform3D

루트인 Transform3D 오브젝트(802)는 Transform의 특정 클래스들을 구성하는 몇가지 흥미로운 정적 방법들(static methods)을 가진다. 이것은 Matrix3D 표현을 노출시키지 않으며, 그것은 이 Transform이 그것보다 광범위할 수 있기 때문이다.

Point3D/Vector3D를 취하는 Transform() 방법들은, 변환이 어파인(affine)이 아니라면 예외를 증가시킬 것이다.

Transform3DCollection

Transform3D Collection 오브젝트(804)는, 상기 Create 방법들과 동일한 방법으로 변경된 Add 방법들을 사용해, Visual 2D의 TransformCollection을 정확하게 모방할 것이다.

AffineTransform3D

Affine Transform3D 오브젝트(806)는 단순히, 변환(Translate), 스큐(Skew), 회전(Rotate), 스케일링(Scale)으로부터 구체적인 모든 어파인 3D 변환들이 유도되는 기본 클래스이고, Matrix3D로의 판독 액세스를 노출시킨다.

TranslateTransform3D 오브젝트 (808)

ScaleTransform3D 오브젝트 (812)

RotateTransform3D

Rotate Transform3D 오브젝트(812)는, 주위로 회전하는 축 개념(및 그에 따른 사원수들의 사용)을 도입하는 것에 기인한, 2D 회전으로부터의 단순 매핑 이상의 것이다.

여기에서는 사원수 속성만이 애니메이션화될 수 있다. 일반적으로, 축/각도의 애니메이션화는 양호하게 동작하지 않는 경향이 있다. 사원수의 양호한 애니메이션화를 위해, 사원수의 기본 값으로부터 축과 각도를 추출할 수 있다. 고정 축에 대해 각도를 단순 애니메이션화 하기를 원한다면, 이것을 특정하는 쉬운 방법은 그 위치들을 표현하는 2개의 사원수들을 구축하고 그들 사이에서 애니메이션화하는 것이다.

MatrixTransform3D

MatrixTransform3D 오브젝트(814)는 Matrix3D로부터 직접적으로 Transform3D를 구축한다.

Transform3D TypeConverter

Transform3D 유형 속성이 마크업에서 특정될 때, 속성 시스템은 Transform TypeConverter를 사용하여 스트링 표현을 적절한 Transform 유도형 오브젝트로 변환한다. 이러한 구문을 사용하여 애니메이션화된 속성들을 설명할 수 있는 방법은 없지만, 복잡한 속성 구문이 애니메이션 서술들에 사용될 수 있다.

구문

구문은 2D Transform의 모델링이다. <>은 연산 파라미터들을 표현한다.

문법

Visual3D

도 1의 Visual3D 오브젝트(22)는 Visual2D로부터 유도되며, 따라서, 그것의 속성들 모두는 다음을 포함하게 된다.

ㆍ 불투명도

ㆍ 2D의 기하 클립(Geometric Clip)

ㆍ 2D 혼합 모드

ㆍ 히트 테스팅 API

ㆍ 2D 제약들 질의(Bounds query)

ㆍ 비주얼 트리로의 참여

불투명도, 클립, 혼합 모드, 및 제약들 모두는 3D 화면의 2D 프로젝션에 적용된다는 점을 유의한다.

화면

뷰포트 박스는, Camera/Model들의 조합에 의해 결정된 프로젝션이 2D의 로컬 좌표 공간으로 매핑되는 장소를 확립한다.

Drawing3DContext

Drawing3DContext는 2D DrawingContext와 상당히 유사하며, RenderOpen/RenderAppend를 통해 Visual3D의 Model3DCollection으로부터 액세스될 수 있다. 이것은 내부적으로 명령어들을 포함하긴 하지만, 즉시-모드 렌더링 콘텍스트처럼 느껴진다.

이들 Drawing3DContext 연산들의 의미에 관한 구체적인 세부사항을 위해서는, Drawing3DContext가 정말로 편리한 Modeling API 섹션을 참고한다. 예를 들어, DrawImportedPrimitive(ImportedPrimitive3DSource primitiveSource, objectHitTestToken)은 간단하게 ImportedPrimitive3D를 생성하고, 그것을 (콘텍스트에 관한 Push/Pop 방법들에 의해 차례로 조작되는) 현재 누적 중인 Model3D에 추가한다.

DrawModel()은 "콘텍스트" 세계와 "모델링" 세계 사이의 또 하나의 교차점으로, Model3D가 콘텍스트로 그려질 수 있게 한다.

Drawing3DContext로부터의 명시적인 "되읽기(readback)"가 존재하지 않는다. 이것은 단지 그것을 지지하는 Model3DGroup을 가지며, 항상 그 집합을 열거할 수 있기 때문이다.

Modeling API

이것은, 계승된 멤버들(inherited members)을 나타내지 않는, 이들 클래스를 위한 공용이며 보호된 API(public and protected API)이다.

Model3D

도 1의 Model3D 오브젝트는, 그로부터 모든 것이 구축되는 추상 모델 오브젝트이다.

Model3DGroup

도 1의 Model3DGroup 오브젝트(18)는, 모델들의 조합을 구성하는 것으로, 그들을 하나의 유닛으로 취급하여, 그들을 선택적으로 변환하거나 또는 다른 속성들을 그들에게 적용한다.

Model3DGroup 또한, Drawing3DContext를 리턴하는 RenderOpen/Append를 가진다는 점을 유의한다. 이러한 콘텍스트의 사용은 Model3DCollection 자체를 변경시킨다. RenderOpen()과 RenderAppend() 사이의 차이점은 RenderOpen()이 그 집합을 먼저 소거시킨다는 점이다.

한번에 하나의 Drawing3DContext만이 Model3DGroup상에 개방될 수 있으며, 그것이 개방될 때, 애플리케이션들은 그러한 Model3DGroup의 컨텐츠에 (판독 또는 기입을 위해) 직접적으로 액세스할 수 없다는 점을 유의한다.

광 계층구조

광 오브젝트들은 Model3D 오브젝트들이다. 이들은, 주변(Ambient), 포지셔널(Positional), 방향성(Directional), 및 스폿(Spot) 광들을 포함한다. 이들은 Direct3D 라이팅 세트를 통해 바로 모델링되지만, 모델링 계층구조의 일부인 추가적인 속성을 가지므로, 좌표 공간 변환에 종속된다.

모든 광들에 대해 주변 컬러, 확산 컬러, 및 정반사 컬러가 제공된다.

광 계층구조는 다음과 같으며 도 9에 도시되어 있다.

기본적인 광 오브젝트(902) 클래스는, 단순히 이하의 것을 갖는 추상 클래스이다.

AmbientLight

주변 광 오브젝트(904)는 모델들을, 그들의 형태에 관계없이, 균일하게 조명한다.

DirectionalLight

방향성 광 오브젝트(906)로부터의 방향 광들은 공간적 위치를 갖지 않으며 그들의 광을, 그것을 정의하는 벡터에 의해 특정된 특정 방향을 따라 프로젝션한다.

방향이 정규화될 필요는 없지만, 0이 아닌 크기(non-zero magnitude)를 가져야 한다.

PointLight

포인트 광 오브젝트들(908)로부터의 포지셔널 광들은 공간적인 위치를 가지며 그들의 광을 모든 방향으로 프로젝션한다. 광의 감소(falloff)는 감쇠 및 범위 속성들에 의해 제어된다.

SpotLight

SpotLight는 위치, 범위, 및 감쇠를 가지므로 PointLight로부터 유도되지만, 또한 방향과 광의 "콘(cone)"을 제어하기 위한 파라미터들이 추가된다. "콘"을 제어하기 위해, (벗어나는 것은 어떤 것도 조명되지 않는) outerConeAngle 및 (내부의 모든 것이 완전 조명되는) innerConeAngle이 특정되어야 한다. 내부 콘의 외측과 외부 콘 사이의 조명은 선형적으로 감소한다. (여기에서 가능할 수 있는 혼돈 원인은 여기에서 진행되는 2개의 감소들이 존재한다는 것인데, 하나는 내부 콘과 외부 콘 가장자리간의 "각도" 감소이고, 다른 것은 광의 위치에 비례하며, 감쇠와 범위에 의해 영향을 받는 거리 감소이다.)

각도는 도 단위로(in degrees) 특정되어 있다.

Primitive3D

도 1의 Primitive3D 오브젝트들(12)은, 트리에 렌더링을 초래하는 리프 노드들이다. 구체적인 클래스들은 명시적으로 특정된 메시들 뿐만 아니라 수입된 프리미티브들(.x 파일들)을 발생시킨다.

MeshPrimitive3D

MeshPrimitive3D는 메시 및 재료를 사용하는 모델링을 위한 것이다.

MeshPrimitive3D는 리프 기하이고, 자체가 Mesh는 아니지만 Mesh를 포함한다. 이것은, Mesh가, 메시 데이터를 반복하지 않으면서, 상이한 재료들을 가지며 상이한 히트 테스팅에 종속되는 다수의 MeshPrimitive3D들 사이에서 공유될 수 있다는 것을 의미한다.

ImportedPrimitive3D

ImportedPrimitive3D는 발생되어 적절한 내부 형태로 변경된 (잠재적으로 재료 및 애니메이션을 갖는) 외부적으로 획득된 프리미티브를 표현한다. 이것은 Avalon에 의해 고정 모델(rigid model)로서 취급된다. 이것의 정규적인 예는 .X File이고, XFile들을 명시적으로 불러오는 ImportedPromitive3DSource의 서브 클래스가 존재한다.

ImportedPrimitive3D를 위한 TypeConverter

.x 파일들은 화면에 포함되어 있으므로, 이를 표현하기 위한 간단한 TypeConverter 포맷은 다음과 같아야 한다.

VisualModel3D

VisualModel3D는 임의의 Visual(정의에 의해, 2D)을 취하며, 그것을 화면에 배치한다. 렌더링될 때, 그것은 스크린 정렬될 것이며, 그 사이즈는 영향을 받지 않겠지만, 카메라로부터의 특정한 z-평면에 존재할 것이다. Visual은 대화식(interactive)을 유지할 것이다.

VisualModel3D를 렌더링하는 것은 먼저 CenterPoint를 실제 좌표들로 변환한다. 그 다음, 변환된 CenterPoint의 z에 비주얼의 중심이 위치하는 스크린 정렬 방식으로 Visual을 픽셀 버퍼로 렌더링한다. 카메라 이동하에서, VisualModel3D는 항상 동량의 스크린 면적을 차지할 것이고, 항상 정면을 향하고 있을 것이며, 광 등에 의해 영향을 받지 않을 것이다. 이러한 카메라 이동 동안의 나머지 화면에 대한 비주얼의 고정된 포인트는 비주얼의 중심일 것인데, 그 이유는 이동은 그 포인트에 기초해 발생하기 때문이다.

제공된 Visual은 완전 대화식이고, 그것을 둘러싸는 Visual3D에 효과적으로 "어버이 구실을 한다"(이것은 Visual이 하나의 부모만을 가질 수 있는 것처럼, 주어진 Visual이 임의의 VisualModel3D에서 한번만 사용될 수 있다는 것을 의미한다).

Mesh3D

Mesh3D 프리미티브는, 프로그램적으로 구성될 수 있는 (인덱스형 및 비인덱스형 규격 모두를 허용하는) 직접적인 삼각형 프리미티브이다. 이것은 위치, 정규화, 컬러, 및 텍스처 정보를 지원하는데, 마지막 3개는 선택적이다. 또한, 메시는, 그것이 삼각형으로, 직선으로, 또는 점으로 디스플레이될 것인지의 여부를 선택할 수 있게 한다. 또한, 메시는 인덱스들을 해석하기 위한 3개의 토폴로지들, TriangleList, TriangleStrip, 및 TriangleFan을 지원한다.

Mesh3D에 의해 직접적으로 지원되지 않는 정점 포맷들 및 그외의 프리미티브 구성을 위해, .x 파일이 구성되고 불러질 수 있다.

MeshPrimitiveType은 다음과 같이 정의된다.

Mesh 데이터의 해석

Mesh3D의 매 정점 데이터는 Positions, Normals, Colors, 및 TextureCoordinates로 분할된다. 이들 중에서, Positions만이 필요하다. 다른 것들 중 어느 하나가 제공된다면, 이들은 Positions 컬렉션과 정확하게 동일한 길이를 가져야 하며, 그렇지 않으면, 예외가 증가될 것이다.

Normals는, 제공된다면, 정규화되어 있는 것으로 가정된다. 정상치가 필요한 경우라면, 이들이 공급되어야 한다.

TriangleIndices 컬렉션은, 메시를 구성하는 삼각형들에 대한 정보를 매 정점마다 결정하기 위해 정점 데이터로 인덱싱되는 멤버들을 가진다. 이 컬렉션은, MeshPrimitiveType의 설정에 기초하여 해석된다. 이들 해석은 Direct3D에서의 해석과 정확하게 동일하다. TriangleList를 위해, TriangleIndices 컬렉션의 매 3개 엘리먼트들마다 새로운 삼각형을 정의한다. TriangleFan의 경우, 인덱스 0, 1, 2는 제1 삼각형을 결정하고, 그 다음, 각각의 후속 인덱스 i는 정점들 0, i, i-1에 의해 주어지는 새로운 삼각형을 결정한다. TriangleStrip의 경우, 인덱스 0, 1, 2는 제1 삼각형을 결정하고, 각각의 후속 인덱스 i는 정점들 i-2, i-1, 및 i에 의해 주어지는 새로운 삼각형을 결정한다. LineList, LineStrip, 및 PointList도 유사한 해석들을 갖지만, 이 렌더링은 삼각형이 아니라 선 및 포인트 차원에서의 렌더링이다.

TriangleIndices가 널(null)이면, Mesh는 비인덱스형 프리미티브(non-indexed primitive)로서 구현되는데, 이것은 길이 n의 Positions 컬렉션에 대해 0, 1, ..., n-2, n-1의 값을 보유하는 TriangleIndices와 등가이다.

Mesh의 구성 및 데이터 복사 방지

Mesh의 구성시에, 본 구현은 이러한 메시를 표현하는 최적화된 D3D 구조를 생성한다. 이 시점에서, 실제의 Collection 데이터 구조들은 데이터 복사를 방지하기 위해 Mesh 구현에 의해 이용되지 않을 수도 있다. (예를 들어, Visual3D들의 모델 계층구조를 순회하는) 어떠한 다른 메커니즘을 통해 액세스된다면, 메시의 후속적인 되읽기는 원래 데이터를 포함하기 보다는 그것에 보유되어 있는 D3D 정보로부터 데이터를 재구성할 것이다.

Mesh의 가변성

메시는 가변적인 것(Changeable)으로부터 유도되므로, 변경될 수 있다. 본 구현은 세트들을 정점 및 인덱스 데이터로 분류할 필요가 있으며 이러한 변화들을 D3D 데이터 구조들로 전달해야 한다.

Mesh를 위한 TypeConverter들

다른 유형들과 마찬가지로, XAML의 복잡한 속성 구문을 사용하여 Mesh3D를 정의하는 컬렉션들을 특정할 수 있다. 그러나, 규격을 보다 간단명료화하기 위해 TypeConverter들이 제공된다.

메시에 정의된 각 컬렉션은, 파싱되어 컬렉션을 생성하는데 사용될 숫자들의 단일 스트링을 취할 수 있다. 예를 들어, 위치들 및 컬러들만을 가진 인덱스형 삼각형 스트립을 표현하는 Mesh는 다음과 같이 특정될 수 있다.

물론, 이들 중 어떤 것은 복잡한 속성 구문으로 훨씬 더 장황하게 표현될 수 있다.

재료(Material)

Primitive3D를 구성하는 방법들은 그들의 외양을 정의하기 위해 Material을 취한다. Material은, BrushMaterial, VisualMaterial, 및 AdvancedMaterial과 같은 3개의 구체적 서브 클래스들을 가진 추상적 기본 클래스이다. BrushMaterial 및 VisualMaterial 모두는 BasicMaterial이라고 하는 다른 추상적 클래스의 서브 클래스들이다. 따라서, 다음과 같다.

ㆍ BrushMaterial은 하나의 Brush만을 취하며, (픽셀마다 또는 스칼라로) 투명성을 실현하는 것, (애니메이션화된 것일지라도) 텍스처 변환을 갖는 것, 비디오 텍스처들, 자동적으로 생성된 암시적 밉맵들(implicit auto-generated mipmaps) 등을 사용하는 것을 포함하는, 광범위한 효과들을 위해 사용될 수 있다. 구체적으로, 고체의 컬러들, 이미지들, 변화도들, 또는 심지어 다른 Visual의 텍스처링을 위해서는, SolidColorBrush, ImageBrush, GradientBrush, 또는 VisualBrush를 사용하여 그들의 BrushMaterial을 생성하기만 하면 된다.

ㆍ VisualMaterial은 구체적으로 Visual에서 재료를 구성하도록 설계된다. 이 재료는, 입력이, 그것이 포함되어 있는 3D 세계로부터 Visual로 전달된다는 의미에서 대화식일 것이다. 이것과 VisualBrush를 가진 BrushMaterial 사이의 차이점이 궁금할 수도 있을 것이다. 차이점은 BrushMaterial은 비대화식이라는 것이다.

ㆍ AdvancedMaterial 클래스는, 단순히 BrushMaterial 또는 VisualMaterial을 사용하는 것보다는 훨씬 더 복잡하지만, 훨씬 큰 유연성(flexibility)을 제공한다. 그러나, 비-3D-Einstein(non-3D-Einstein)은 AdvancedMaterial에 대해 알 필요가 없으며 단순히 BrushMaterial/VisualMaterial만을 사용하여 그들이 실현하고자 하는 것을 대부분 실현할 수 있다.

Brush에 기초하는 것에 의해, 재료들은 상당한 유연성 및 "개념의 경제성(economy of concept)"를 갖게 된다. 구체적으로,

ㆍ 비디오 텍스처, 변화도 텍스처 등과 같은 것들을 반영하는 개별적인 텍스처 계층구조가 필요하지 않은데, 그 이유는 이들 모두는 Brush들로서 특정될 수 있기 때문이다.

ㆍ Brush들은 이미 알파-마스크 및 스칼라 불투명도 값들 모두를 인캡슐레이팅하고 있으므로, 이들 모두가 텍스처링에 이용될 수 있다.

ㆍ Brush들은 이미, 텍스처링의 경우에, 메시의 uv 좌표들을 텍스처로 매핑하기 위한 텍스처 변환으로 해석될, 그들과 관련된 2D Transform을 갖고 있다.

ㆍ Brush들은, 나중에, 나무 무늬 쉐이더(wood grain shader)와 같은 스톡 절차적 쉐이더들(stock procedural shaders)을 부착하기에 적합한 장소이다. 그 다음, 이것은 2D에서는 필(fill) 또는 펜으로서, 그리고 3D에서는 텍스처로서 사용될 수 있다. 절차적 쉐이더들을 위한 3D 공간에서는 특정한 API 지원이 제공될 필요가 없다.

유의사항: Texture변환 속성은, BrushMaterial 또는 VisualMaterial의 정의 내에 존재할 수 있는 어떤 변환과도 차별된다. 이것은 문제의 Material로부터 (그 범위가 [0,0] 내지 [1,1]인) 텍스처 좌표 공간으로의 변환을 특정한다. Material 내의 변환은 TextureTransform과 조합되어 (텍스처 좌표의) 1×1 Material이 Mesh 전체에 매핑되는 방법을 설명한다.

쉐이더들

많은 것이 파라미터화 되어 있는 한 세트의 "스톡" 쉐이더들은 API로 다음과 같이 액세스될 수 있다.

1) 2D 세계에서 의미가 있는 쉐이더들의 경우, 이들은 Brush의 구체적인 서브 클래스들로서 노출될 것이며, 이들의 파라미터화는 클래스상의 구성자들을 통해 또는 클래스상의 속성들로서 표현된다. 그 다음, 이들은 2D 오브젝트들에 적용될 수 있다.

2) 3D에서만 의미가 있는 쉐이더들의 경우, 이들은 Material 또는 BasicMaterial의 구체적인 서브 클래스들로서 노출되는데, 이들 또한 그들의 구성자를 통해 파라미터화될 수 있다.

그 다음, 이러한 노출로 인해 쉐이더들은 3D(및 적절한 2D) 메시들에 적용될 수 있다.

BrushMaterial

상술한 바와 같이, BrushMaterial은 단지 Brush를 인캡슐레이트할 뿐이다. Primitive3D에 적용된 BrushMaterial은 텍스처로서 취급된다. 텍스처들은 직접적으로 매핑될 것인데, 다시 말해, 매핑되고 있는 프리미티브상의 2D u,v 좌표들은, 텍스처 변환에 의해 변경된, Texture상의 대응되는 x,y 좌표들로 직접적으로 인덱싱될 것이다. Avalon의 모든 2D와 마찬가지로, 텍스처의 좌표계는 아래쪽을 포인팅하는 포지티브 y를 가진 좌측 상부의 (0,0)에서부터 진행한다.

Brush에 사용되는 VisualBrush는 입력을 수용하지는 않지만, 그에 관한 임의의 애니메이션 또는 그것에 발생하는 임의의 구조적 변화들에 따라 업데이트될 것이다. Visual을 Material로 사용하면서도 여전히 입력을 수신하기 위해서는, 다음과 같이 VisualMaterial을 사용한다.

VisualMaterial

상술한 바와 같이, VisualMaterial은 대화식 Visual을 인캡슐레이트한다. 이것은, Visual이 자신의 텍스처 형태로 라이브 상태를 유지한다는 점에서 Visual에 사용되는 BrushMaterial과의 차이점이다. 그 다음, Visual은, 사실상, 루트 Visual3D에 대해 어느 정도 어버이 노릇을 하게 된다는 점을 유의한다. 하나 이상의 Material에 하나의 UIElement를 사용하거나, 또는 하나 이상의 장소에 VisualMaterial을 사용하는 것은 불법이다.

AdvancedMaterial

BrushMaterial들/VisualMaterial들 및 BumpMap들이 AdvancedMaterial들을 정의하는데 사용된다.

EnvironmentMap들은, 큐브-매핑을 가능하게 할 수 있는 특정 포맷일 것으로 기대되는 텍스처들이다. 구체적으로, 큐브 맵의 6개 면들은 (Brush상의 3×2 눈금과 같이) Texture와 관련되어 있는 Brush의 주지 섹션들로 표현되어야 할 것이다.

주변(Ambient), 확산(Diffuse), 및 정반사(Specular) 속성들은, 이들이 AdvancedMaterial들 자체로서 특정되지 않기 때문에, 일반적인 Material이 아니라 BasicMaterial을 취한다. 환경 맵들이 BrushMaterial들이라는 것도 유의한다.

BumpMap 정의

Bump 맵들은, 텍스처들처럼, 프리미티브들상의 텍스처 좌표들을 통해 3D 프리미티브들로 매핑되는 눈금들(grids)이다. 그러나, 보간된 데이터는, 프리미티브의 "울퉁불퉁한(bumpy)" 외관을 초래하는, 면의 정상치들에 대한 섭동들(perturbations)로 해석된다. 이를 실현하기 위해, 범프 맵들은 정상 섭동과 같은 정보 및 잠재적인 그외의 정보를 전달한다. 이들은 컬러 또는 투명성 정보를 전달하지는 않는다. 이 때문에, Brush를 범프 맵으로 사용하는 것은 부적절하다.

따라서, 특정 픽셀 포맷의 ImageSource가 될 새로운 BumpMap 클래스를 도입한다.

Material을 위한 TypeConverter

Material은, Brush의 스트링 규격을 BrushMaterial로 자동 승격시키는 간단한 TypeConverter를 제안한다.

이것은 규격들이 다음과 같이 되게 한다.

"Ambient" 파라미터들

이 섹션은, 기하 계층구조의 임의 레벨들에 포함될 수 없는, 모델의 "주변" 파라미터들을 논의한다.

Fog

포그는, Visual3D상의 Fog 속성을 설정하는 것에 의해 화면에 추가될 수 있다. 이용 가능한 Fog는 "화소 포그"이다. 포그는, 다음에 나타낸 바와 같은 추상 클래스 및 계층구조로서 표현된다.

fogDensity는 0 내지 1의 범위이고, 포그 밀도의 정규화된 표현이다.

fogStart 및 fogEnd는 장치 공간 [0,1]에 특정된 z-깊이들로서, 포그가 시작되고 끝나는 장소를 표현한다.

Camera

도 1의 카메라 오브젝트(32)는, 3D 모델이 2D 비주얼상에 프로젝션되는 메커니즘이다. Camera 자체는, ProjectionCamera 및 MatrixCamera의 2개 서브 클래스들을 가진 추상형이다. ProjectionCamera 자체는, PerspectiveCamera 및 OrthogonalCamera의 2개 서브 클래스들을 가진 추상 클래스이다. PerspectiveCamera는, Camera를 구성하기 위한 Position, LookAtPoint, 및 FieldOfView와 같은 주지의 파라미터들을 취한다. OrthogonalCamera는, FieldOfView 대신에 Width를 취한다는 점을 제외하면 PerspectiveCamera와 유사하다. MatrixCamera는 World-To-Device 변환을 정의하는데 사용된 Matrix3D를 취한다.

Visual3D에서, Camera는 Model3D로의 뷰를 제공하는데 사용되고, 결과의 프로젝션은 Visual3D상에 확립된 2D ViewPort로 매핑된다.

Visual3D의 2D 바운딩 박스(bounding box)는 단순히, 자신의 정점, 축-정렬형 헐(hull)로 래핑되고, 비주얼상에 확립된 클립에 클리핑되어 있는, 3D 모델의 프로젝션된 3D 박스일 것이다.

ProjectionCamera

도 1의 Projection카메라 오브젝트(39)는, PerspectiveCamera 및 OrthogonalCamera 모두가 유도되는 추상적 부모이다. 이것은, MIL(media integration layer)이 지원하는 ProjectionCamera의 2가지 유형들에 공통되는 위치, 룩앳 방향(lookat direction), 및 업 방향(up direction)과 같은 속성들을 인캡슐레이트한다.

PerspectiveCamera

도 1의 Perspective카메라 오브젝트(36)는, Position, LookAtPoint, 및 FieldOfView와 같은 주지의 파라미터들로부터 퍼스펙티브 프로젝션 카메라가 구성되는 수단이다. 다음의 도면은 PerspectiveCamera의 관련 양상들에 대한 양호한 표시를 제공한다.

몇가지 유의사항들:

ㆍ PerspectiveCamera는 ProjectionCamera로부터 위치, 룩앳 방향, 업 벡터 속성들을 계승한다.

ㆍ FieldOfView는 시야의 수평 시야 범위를 표현하며, (다른 모든 MIL 각도들처럼) 도로 특정된다.

ㆍ Near 및 Far PlaneDistance들은 카메라의 위치로부터 LookDirection 포인트에 의해 정의된 벡터 방향으로의 3D 세계-좌표 거리들을 표현한다. NearPlaneDistance의 디폴트는 0이고 FarPlaneDistance의 디폴트는 무한대이다.

ㆍ 실제 프로젝션시에, Near/FarPlaneDistance들이 각각 여전히 0/무한대이면, 모델을 조사하고 그것의 바운딩 볼륨이 카메라 프로젝션을 따라 프로젝션된다. 그 다음, 얻어진 바운딩 볼륨을 조사하여, 근접면 거리는 카메라 위치에 가장 근접한 LookDirection에 수직인 바운딩 볼륨의 면으로 설정된다. 원근면에 대해서도 동일하지만, 가장 멀리 떨어져 있는 면을 사용한다. 이로 인해, 최적화된 z-버퍼 해상도를 발생시키며 전체 모델을 디스플레이할 수 있다.

PerspectiveCamera의 파라미터들에 의해 정의된 "프로젝션 면"은 Visual3D상의 ViewPort 사각형으로 매핑되며, 3-공간으로부터 2-공간으로의 최종적인 전이를 표현한다.

OrthogonalCamera

도 1의 Orthogonal카메라 오브젝트(37)는 세계으로부터 물체 공간으로의 직교 프로젝션을 특정한다. PerspectiveCamera와 마찬가지로, OrthogonalCamera 또는 직교 카메라는 위치, 룩앳 방향, 및 업 방향을 특정한다. 그러나, PerspectiveCamera와는 달리, OrthogonalCamera는, 퍼스펙티브 단축을 포함하지 않는 프로젝션을 묘사한다. 물리적으로, OrthogonalCamera는, 그 면들이 평행인 뷰잉 박스를 묘사한다(이 경우, PerspectiveCamera는, 그 면들이 궁극적으로 카메라 포인트에서 만나는 뷰잉 프러스트럼(viewing frustrum)을 묘사한다).

몇가지 유의사항들:

ㆍ OrthogonalCamera는 ProjectionCamera로부터 위치, 룩앳 방향, 및 업 벡터 속성들을 계승한다.

ㆍ Width는 OrthogonalCamera 뷰잉 박스의 폭을 표현하며, 월드 유닛(world units)으로 특정된다.

ㆍ Near 및 Far PlaneDistance들은 PerspectiveCamera에서와 동일한 방식으로 동작한다.

MatrixCamera

도 1의 Matrix카메라 오브젝트(38)는 Camera의 서브 클래스이고 Matrix를 프로젝션 변환으로서 직접적으로 특정하기 위해 제공된다. 이것은, 자신만의 고유한 프로젝션 행렬 계산 메커니즘을 가진 애플리케이션들에 유용하다. 이것은 분명히 시스템의 개선된 사용을 표현한다.

몇가지 유의사항들:

ㆍ ViewMatrix는 MatrixCamera에 대한 위치, 룩앳 방향, 및 업 벡터를 표현한다. 이것은, 빌보딩(billboarding) 때문에 Model3D 계층구조의 최상위 변환과 상이할 수 있다. ProjectionMatrix 변환은 화면을 카메라 공간으로부터 물체 공간으로 변환한다.

ㆍ MinimumZ 및 MaximumZ 속성들은, MatrixCamera의 프로젝션 행렬에 의해 이 값들이 함축되기 때문에, 제거되었다. 프로젝션 행렬은 좌표계를 카메라 공간으로부터, X 및 Y의 범위는 [-1,1]이고 Z의 범위는 [0,1]인 정규화된 큐브로 변환한다. 카메라 공간에서의 최소 및 최대 z 좌표들은, 프로젝션 행렬이 z 좌표를 변환하는 방법에 의해 정의된다.

얻어진 프로젝션은 Visual3D상의 ViewPort 사각형으로 매핑되고, 3-공간으로부터 2-공간으로의 최종적인 전이를 표현한다는 점을 유의한다.

XAML 마크업 예들

다음은 전체적인 Model3D 계층구조의 XAML 규격을 나타내는 좀더 완전한 마크업들이다. 구문 중 일부는 일반적인, 간단한 x-파일 불러오기(importation) 및 합성을 이용하여 변경될 수 있다.

이 예는 간단하게, 수입된 2개의 .x 파일들, 그들 중 하나에 대한 (z-축 주위로 45도) 회전 변환, 및 0,1,0에 위에서 하나의 화이트 포인트 광을 설치하는 것으로 Model을 생성한다.

이제, 이 마크업은 어떤 경우에도 파일, 스트림, 리소스일 것이다. 클라이언트 프로그램은 해당 XAML의 로딩을 호출하여, 적절하다고 판단되는 애플리케이션에 의해 사용될 완전한 Model3DGroup을 차례로 구성할 것이다.

명시적 Mesh 선언

이 예는, 복잡한 속성의 XAML 구문을 사용하여, 명시적으로 선언된 MeshPrimitive3D를 제공한다. 메시는 LinearGradient를 사용하여 옐로우에서 레드로 텍스처링될 것이다.

이 화면에도 광이 존재한다.

.x 파일들에 대한 애니메이션들

이 예는 먼저 .x 파일을 취한 다음 XAML-특정 애니메이션에 추가한다. 이러한 특정 예는, x 파일을 5초에 걸쳐 1×에서 2.5×로 스케일링하는 균일 스케일을 추가하고, 반전하며, 무한 반복한다. 또한, 가속/감속을 사용하여 자신의 스케일을 슬로우-인/슬로우-아웃(slow-in/slow-out)한다.

VisualMaterial 규격

이 예는 .x 파일을 불러오고 라이브 UI를 재료로서 적용한다.

Viewport3D를 위한 API

Viewport3D를 위한 API 규격은 다음과 같다.

이것은 본 발명의 본 실시예에서의 Model 3D API 정의들을 완결한다.

컴퓨터의 구조적 사양들에 특징적인 언어들과 방법적인 동작들로, 그리고 컴퓨터 판독가능한 매체에 의해 본 발명을 설명하였지만, 첨부된 청구항들에 정의된 본 발명이, 설명된 특징적인 구조들, 동작들, 또는 매체에 한정될 필요는 없다는 것을 알 수 있다. 따라서, 특징적인 구조적 사양들, 동작들, 및 매체는 청구된 발명을 구현하는 예시적 실시예들로서 개시되어 있다.

상술한 다양한 실시예들은 단지 예시를 위해 제시된 것으로 본 발명을 한정하는 것으로 받아들여서는 안된다. 당업자들은, 여기에서 도시하고 설명한 예시적 실시예들 및 애플리케이션들을 따르지 않으면서, 그리고 다음의 청구항들에 기술되어 있는 본 발명의 진정한 정신 및 범위를 벗어나지 않으면서, 본 발명에 대해 다양한 변경들 및 변화들이 행해질 수 있다는 것을 쉽게 이해할 수 있다.

Claims (15)

1. 3차원(3D) 모델들을 렌더링하기 위한 트리 계층구조의 컴퓨터 프로그램 오브젝트들에 적용되는 컴퓨터 데이터 구조로서,

   3D 화면을 렌더링하기 위한 오브젝트 트리 계층구조;

   상기 3D 화면을 위한 오브젝트들을 수집하는 상기 트리 계층구조의 루트 오브젝트;

   다른 그룹 오브젝트들 및 리프 오브젝트들(leaf objects)을 수집하고, 그룹 오브젝트의 수립된 오브젝트들에 작용하는 변환들을 갖는 상기 트리 계층구조의 하나 이상의 그룹 오브젝트들; 및

   상기 트리 계층구조의 리프 오브젝트들

   을 포함하고,

   상기 리프 오브젝트들은,

   상기 3D 화면에서의 3D 모델 렌더링시에 사용될 조명을 정의하는 상기 트리 계층구조의 광 오브젝트; 및

   상기 3D 화면에 3D 모델을 그리는 연산들을 정의하는 하나 이상의 드로잉 3D 오브젝트들을 포함하는 데이터 구조.
2. 제1항에 있어서,

   상기 3D 화면을 2D 이미지로서 보기 위한, 3D 공간에서의 카메라 시점 위치 를 정의하는 카메라 데이터를 더 포함하는 데이터 구조.
3. 제2항에 있어서,

   상기 3D 화면의 2D 이미지를 바라보는 2D 윈도우의 경계들을 정의하는 뷰포트(viewport) 데이터를 더 포함하는 데이터 구조.
4. 제1항에 있어서,

   상기 3D 화면의 상기 3D 모델을 변환하기 위해, 상기 트리 계층구조의 상기 드로잉 오브젝트들에 대한 상기 드로잉 연산들을 변환하는 그룹 오브젝트를 더 포함하는 데이터 구조.
5. 제1항에 있어서,

   상기 드로잉 오브젝트는,

   상기 3D 화면에 2D 이미지를 생성하기 위한 상기 드로잉 연산들을 실행하는 하나 이상의 비주얼 모델 오브젝트들을 더 포함하는 데이터 구조.
6. 합성 시스템에 의해 렌더링된 3D 모델들의 2D 뷰를 드로잉하기 위해 컴퓨터 프로그램 오브젝트들의 계층구조를 처리하는 방법으로서,

   상기 트리의 그룹 오브젝트들 및 리프 오브젝트들을 처리하기 위해 오브젝트들의 3D 화면 트리 계층구조의 브랜치들을 순회하는 단계;

   처리되지 않은 다음 오브젝트가 그룹 오브젝트인지 아니면 리프 오브젝트인지를 검출하는 단계;

   리프 오브젝트가 검출되면, 상기 리프 오브젝트가 광 오브젝트인지 아니면 드로잉 3D 오브젝트인지를 검출하는 단계;

   상기 리프 오브젝트가 광 오브젝트라면, 드로잉 3D 오브젝트에 의해 사용될 조명을 설정하는 단계; 및

   드로잉 3D 오브젝트가 검출되면, 상기 광 오브젝트에 의해 제공되는 상기 조명에 의해 조명되는 대로 3D 모델을 드로잉하는 단계

   를 포함하는 방법.
7. 제6항에 있어서,

   카메라 시점을 설정하는 단계를 더 포함하고,

   상기 드로잉 단계는 상기 카메라 시점에 기초해 상기 3D 모델을 그리는 방법.
8. 제6항에 있어서,

   상기 3D 화면 트리의 리프 오브젝트들을 리프 오브젝트들의 그룹으로 수집하는 단계; 및

   상기 리프 오브젝트들의 그룹에 대해 그룹 연산을 수행하는 단계를 더 포함하는 방법.
9. 제8항에 있어서,

   상기 그룹 연산은 상기 그룹의 상기 드로잉 오브젝트들에 의한 상기 드로잉 연산들을 변환하기 위한 하나 이상의 변환 연산들인 방법.
10. 제6항에 있어서,

    상기 드로잉 오브젝트는,

    상기 3D 화면에 3D 모델을 그리는 프리미티브 3D 드로잉 오브젝트를 포함하는 방법.
11. 제6항에 있어서,

    상기 드로잉 오브젝트는,

    상기 3D 화면에 2D 이미지를 그리는 모델 3D 드로잉 오브젝트를 포함하는 방법.
12. 컴퓨팅 시스템에서, 모델 3D 오브젝트들에 의해 정의된 3D 모델들의 3D 화면을 생성하는 애플리케이션 프로그램 인터페이스로서,

    상기 3D 화면의 3D 모델들을 그리는 명령어들을 정의하는 하나 이상의 드로잉 오브젝트들; 및

    상기 3D 화면의 상기 3D 모델들에 대한 조명을 정의하는 광 오브젝트

    를 포함하는 애플리케이션 프로그램 인터페이스.
13. 제12항에 있어서,

    그룹의 상기 드로잉 오브젝트들에 의해 그려진 상기 모델들의 조합인 모델을 드로잉하기 위해, 하나 이상의 드로잉 오브젝트들을 그룹으로 수집하는 그룹 오브젝트를 더 포함하는 애플리케이션 프로그램 인터페이스.
14. 제13항에 있어서,

    상기 그룹 오브젝트는 상기 그룹의 상기 드로잉 오브젝트들에 대해 작용하는 하나 이상의 그룹 연산들을 포함하는 애플리케이션 프로그램 인터페이스.
15. 제14항에 있어서,

    상기 그룹 연산은, 상기 그룹의 하나 이상의 드로잉 오브젝트들에 대한 상기 드로잉 연산들에 작용하는 변환을 포함하는 애플리케이션 프로그램 인터페이스.

Images