MINI`s History

from Or........../MINI 2009.09.29 11:53

작고 귀여운 외모를 가졌지만, 폭발적인 성능과 파워풀인 핸들링으로 전세계에서 사랑받고 있는 미니(Mini). 미니의 역사는 그야말로

‘고생 끝에 낙’이란 말로 표현된다. 석유파동 와중에 생산된 미니는 초기 엄청난 성공을 거뒀지만, 모그룹의 부실로 인해 여기저기 팔려다녔기 때문이다.

영국 최대 자동차그룹이었던 오스틴사(社)에서 탄생한 미니가 재규어그룹을 거쳐 BMW그룹의 식구가 되기까지, 미니의 오프로드 히스토리를 달려봤다.

◆ 석유파동 이후 오스틴사(社)에서 개발

미니를 최초로 개발한 회사는 국내 자동차매니아들 사이에서 생소한 ‘오스틴’이라는 영국의 메이커다. 이 회사는 1905년 영국 롱브릿지의 허버트 오스틴이라는 사람에 의해 설립됐다. 다양한 모델의 자동차를 선보여, 영국에서는 자동차산업의 선구자란 평가를 받았던 회사다.

1956년 이집트가 수에즈운하를 국유화하면서 영국은 석유 수입에 차질을 빚게 됐다. 연료가 부족하니 당연히 연비가 좋은 차량들을 생산하려 노력했는데, 이런 과정에서 태어난 것이 바로 ‘미니(첫 모델명:세븐미니)’다. 이 차량은 모리스사(社)의 ‘미니 마이너’란 이름으로도 판매됐다.

당시 미니는 소형차였지만, 112km의 속도를 낼 수 있었으며, 앞바퀴굴림차란 특징 때문에 튜닝매니아들로부터 주목을 받았다. 이런 가운데 레이싱카 제작자인 존 쿠퍼(John Cooper)가 1961년 튜닝한 미니를 선보이면서 ‘작지만 강한 차’로 인식되기 시작했다. 이렇게 개량된 미니는 이후 ‘쿠퍼’란 이름이 붙으면서 ‘미니 쿠퍼’란 이름으로도 알려졌다.

미니 쿠퍼는 개량된 이후 1964년, 65년 67년 몬테카롤로 랠리에서 유수 메이커들을 물리치고 세 번의 우승을 차지하면서 레이싱카로의 명성도 쌓았다. 이후 1963년에는 1071cc급의 쿠퍼S가 생산되기도 했다.

그러나 미니를 탄생시킨 오스틴사는 1985년에는 통산 천만대 생산을 돌파하면서 전성기를 여는가 했지만, 1989년 영국의 로버사에 인수되면서 간판을 내렸다.

◆ 로버사(社) 거쳐 BMW에 안착

로버사에 인수된 미니는 이후 별다른 개발이나 프로젝트가 진행되지 않으면서 찬밥 신세를 받았다. 오스틴사를 인수한 로버사가 고급형 브랜드로의 진출을 꾀하면서 소형차였던 미니에까지 신경을 쓰지 않았기 때문이다. 여기에 당시 로버사에는 재규어를 비롯한 랜드로버라는 걸출한 브랜드가 있었기 때문에 미니에게는 소홀하게 대할 수밖에 없었다.

그러나 1994년 로버사를 독일의 BMW그룹이 인수하면서 사정이 달라진다. 당시 BMW그룹은 로버사를 인수하면서 MG로버를 저가형 자동차브랜드로 다시 되돌리고, 랜드로버와 재규어에는 차세대 라인업을 만들어준다. 미니 역시 원래 디자인에 BMW만의 DNA를 주입하면서 비슷하면서도 전혀 다른 미니를 선보인다.

그러나 BMW가 내놓은 로버의 신차들이 시장에서 외면당하면서 BMW그룹마저 자금난에 봉착하는 상황이 벌어진다. 이에 BMW는 결국 로버사를 매각하기로 결심, 로버사의 자동차브랜드를 3종류로 나눠 매각한다. 재규어와 랜드로버가 속한 프리미엄 브랜드는 미국 포드사에 매각됐고, MG와 로버사는 영국의 피닉스캐피탈이라는 회사에 인수됐다. 하지만 미니는 BMW그룹에 남겨졌다.

이렇게 BMW그룹에 잔류하게 된 미니는 올해 탄생 50주년을 맞고 있다. 이를 기념해 ‘미니 존 쿠퍼 왁스 WC500’을 출시하기도 했다.

영국의 소형차로 태어나 독일 BMW그룹의 주요 라인업으로 활약하고 있는 미니. 깜찍하고 작지만, 폭발적인 성능을 자랑하는 미니의 질주는 국적을 가리지 않고 계속될 것이다.     

<<사진설명>>

1.1960년 오스틴사 시절의 미니 판매 포스터(아래는 오스틴의 엠블럼)

2. 미니를 레이싱카로 개조했던 존 쿠퍼(오른쪽사진은 미니 쿠퍼S와 함께한 존 쿠퍼) /

3.몬테카를로 랠리 출전당시의 미니(위)와 모리스에서 '미니 마이너'란 이름으로 나왔던 미니 /

4.로버사 시절의 미니(위:Miss Mini 수상자와 함께 찍혀있다)와 미니 클럽맨 

5.2006년 프랑크푸르트 모터쇼에 등장했던 미니 클럽맨

6.(시계방향으로) 미니 탄생 50주년 기념 미니클럽맨 존쿠퍼스타일 - 2004년 컨셉트카로 제작된 미니XXL - 2008년 제작된 미니 크로스오버(CUV) - 2009년형 미니 쿠퍼S 카브리오 >

-----펌글 스포츠서울닷컴-----

'Or.......... > MINI' 카테고리의 다른 글

A MINI Addiction  (0) 2012.05.08
MINI`s History  (0) 2009.09.29
MINI & Strida  (0) 2009.08.27
MINI - Lamp Replacement Guide  (0) 2009.08.27
Stoptech MINI  (0) 2009.08.27

훔..얼만에 업데이트를 하는건지..ㅡㅡㅋ

언 7개월 만에 업데이트를 하는 eIRIS 입니다..

요새 나름대로 너무 바쁘고 진로에 대해서 고민에 빠져서 못하다가 요새 들어 집중력, 노력 버프를 받고 열심히 나름대로 만들고 있습니다.

 

그래서! 엔진개발에 엄청난 가속도를 붙이기 위해 Tool을 같이 만들기로 했습니다.

일단 현재 프레임 웍까지는 구성했습니다. 다른 Tool과 차별을 두기 위해 ... 이쁜 UI를 위해 ㅡㅡㅋ (제 나름대로 생각입니다용..)

 

아무튼 Tool 프레임 웍까지 만들었습니다. 하나씩 만들어 놓고 eIRIS 엔진 붙이고, Rendering 붙이고, Terrain 관련 붙이고... 등등 해야할 것 같습니다. ^-^  (아무튼 지켜봐주시와용~)

두번째 올리는 진행상황. 뭐 요새 업무에 시달려서 열심히 빡시게 못했지만 나름대로 시간을 만들어 짬짬히 작업했습니다.

 

현재 살짝쿵 몇개의 프로젝트가 추가가 되고 Sample Rendring도 만들고 했습니다.

다음 아래는 전체의 eIRIS 프로젝트입니다.

 

다음은 가장 DX의 Sample인 airplane2.x파일을 매쉬 렌더링 한겁니다. (위에 sphere는 라이팅입니다. )

 

 

그래서~!!!

현재까지 진행된 사항은 Lighting, Material, Mesh...등이 진행되었구요. 모든 리소스는 Resource Manager에서 관리를 하고, Rendering에 관련된 모든 아이들은 Scene Manager라는 아이가 관리를 합니다. ^-^

요즘 진행하고 있는 사항은 Config파일로부터 Setting하는 작업과 effect를 넣을 예정입니다.

 

p.s. 아~ 빡세~ GUI는 언제 하지..ㅡㅡ;;

 

오랫만에 쓰는 eIRIS에 대한 이야기 ... ㅡㅡㅋ

뭐 만들고 있는거냐? 아님 놀고 있는거냐? 라고 생각하시는 분들을 위해 살짝쿵 준비했습니다.

 

현재 eIRIS 엔진에 대한 진행상황..

기본적인 틀은 다 구성 했습니다. 추후 Document 작업을 한 후 공개하겠지만 대략적으로 설명하겠습니다.

eIRIS : 베이스 입니다. 사용자는 eIRIS 포인터를 생성해서 사용하시면 됍니다.

eIRISCommon : eIRIS엔진에 필요한 공통 헤더들입니다.

eIRISDataStructure : eIRIS엔진에 쓰여지는 DataStructure을 가지고 있는 아이입니다. ㅡㅡㅋ

eIRISGraphics : 중요한 아이죠~!! 핵심인데.. 엄청나게 개발중에 있습니다. 현재 Camera, Scene manager, Resource Manager등이 개발돼어있습니다. 그리고 DirectX 9 을 기본으로 개발하고 있습니다. Resource Manager에선 Mesh, Texture 등이 개발 진행중이 있으며 Mesh는 .X (DirectX File)Load까지 개발 돼어있습니다.

eIRISMath : eIRIS에 전반적으로 사용하게 될 수학에 관련된 모든 자료를 가지고 있습니다. 현재 Vector, Matrix, Simple Math등에 대한 함수 구현은 돼어있는 상태입니다.

eIRISSample : eIRIS 엔진에 대한 Test프로젝트 입니다. (Debug도 하구요..)

 

자세한 eIRIS엔진에 대한 사항은 추후 다이어그램과 클래스 계층도를 그려서 올리도록 하지요

어느 정도까지 렌더링까지 돼면 문서작업을 하려고 합니다. ^0^ 열심히 할테니 잘 봐주시와요~

Prologue

 

  언 2007년 10월 쯔음.. 세상에 하나쯤 필요 할듯 말듯한 3D Engine이 있어야겠다는 신념하에 개발을 시작 하였습니다. (뭐~ 세상사~ 있으면 좋고 없으면 말고~ ㅡㅡㅋ) 일단! 제가 가진 얄팍한 그래픽스 지식과 컴퓨터 프로그래밍 지식을 몽땅 총 동원하여 개발을 할 것입니다. (솔직히 제가 쓰기위한 엔진을 만들려고 생각했던 것... 성능이나 코드나 뭐 등등 공개 여부는 추후~! - 왜냐? ㅜ.ㅜ 솔직히 공개수준이 안될 듯 하여..) 다음으로 개발 할 3D Engine에 대해 대략적인 개요를 알려드리겠습니다.

 

Project : eIRIS

Platform : Windows XP

Graphic API : DirectX 9, DirectX 10, OpenGL

 

eIRIS 는 사용자가 간단하게 설정만으로 3D 환경을 만들 수 있는 컨셉을 가지고 있습니다. DirectX나 OpenGL 초기화 과정을 심플한 함수를 통해서 설정을 할 수 있다는 거죠. 또한 FX나 쉐이더를 이용한 이펙트 부분을 서브 프로젝트로 들어가는 것이 아니라 eIRIS 를 통해서 컨트롤 할 수 있도록 할 것 입니다. (요 부분이 eIRIS 강점으로 부각 시킬 예정입니다.)

그리고 추후 어느 정도 개발이 되면 물리엔진 부분도 들어 갈 것 입니다. 다른 PhyicsX 나 등 다른 물리엔진은 따로 Setting을 Application에서 해줘야 하는 단점(?)이 있습니다. eIRIS에서는 바로 사용자가 원할 때 Setting을 해서 물리 엔진을 이용하도록 개발 할 것입니다. (Rendering 과 물리엔진 부분을 한번에 처리 하도록 개발 할 예정입니다. 또한 nVidia의 SLI나 ATI의 CrossFire 등을 이용하여 하나의 GPU에선 물리연산을 하나의 GPU에선 Rendering을 담당하도록 개발 예정에 있습니다. - 퍼포먼스를 위해서...)

 

* 아주 간단하게 eIRIS에 대한 설명과 제가 세운 계획을 적어놨습니다. 하나씩 개발하면서 어떤 부분에 있어서 문제가 생기는지.. 어떤 부분이 개발 되었는지를 블로그를 통해서 올리겠습니다.

 

Differences between Direct3D 9 and Direct3D 10:

The following page provides a basic outline of key differences between Direct3D 9 and Direct3D 10. This documentation is preliminary and incomplete; it serves as a prelude to a comprehensive Direct3D 9 to Direct3D 10 porting and cross-platform development guide which will be provided in a future release of the DirectX SDK. The outline below provides some initial insight to assist developers with Direct3D 9 experience to explore and relate to Direct3D 10.

 

Overview of the Major Structural Changes in Direct3D 10

The general API usage for Direct3D 10 is in its basic structure not unlike previous versions of Direct3D. The process of rendering using the Direct3D 10 device is structurally similar to Direct3D 9 where you follow the flow of a pipeline:

Set a vertex stream source,
Set input layout (Vertex Stream Decl in Direct3D 9 speak),
Declare primitive topology,
Set textures,
Set state objects,
Set shaders,
Draw

Where the Draw command is the call that ties the operations of the Set calls together and the ordering of Sets is arbitrary so long as they occur before the Draw. The major differences in the Direct3D 10 API design are as follows:

  • Removal of Fixed Function
  • Removal of CAPS bits - Direct3D 10's base feature set is guaranteed
  • Stricter management of
    • resource access,
    • device state,
    • shader constants,
    • shader linkage (inputs and outputs to shaders) between stages
  • API entry point names changed to reflect the virtualization of GPU memory (Map() instead of Lock()).
  • Provision of a Debug Layer which may be added to the device at creation time
  • Primitive Topology broken out from the Draw Call, this is now an explicit device state
  • Constant buffer slots on the device instead of explicit constants
  • Shader authoring is done entirely in HLSL. The HLSL compiler now resides in the primary Direct3D 10 DLL.
  • New programmable stage - the Geometry Shader (GS)
  • Shorter stage names in the API
    • VS - Vertex Shader, GS - Geometry Shader, PS - Pixel Shader
  • Removal of Begin Scene / End Scene
  • Common 2D, focus and adapter-management functionality refactored into a new component: DXGI

We will discuss many of the items listed above in more detail during the rest of this document.

Removal of Fixed Function

It is sometimes surprising that even in a Direct3D 9 engine that fully exploits the programmable pipeline, there remains a number of areas that depend on the Fixed Function (FF) pipeline. The most common areas are usually related to screen space aligned rendering for UI. It is for this reason that you are likely to need to build a FF emulation shader or set of shaders which provide the necessary replacement behaviors.

This documentation contains a whitepaper containing replacement shader sources for the most common FF behaviors.

Fixed Function EMU Sample

Note that some Fixed Function pixel behavior including Alpha Test has been moved into shaders.

Device Object Creation Time Validation

The Direct3D 10 pipeline has been redesigned from the ground up in hardware and software with a primary intention of reducing the amount of CPU overhead (at Draw time) to a minimum. To reduce costs, all types of device data have been assigned an object with explicit creation methods provided by the device itself. This design point enables strict data validation to occur at object creation time and not during the Draw call as it often does with Direct3D 9.

Engine Abstractions / Separation

Applications, including Games, that wish to support both Direct3D 9 and Direct3D 10 at the same time need to have the rendering layers abstracted from the rest of the code base. There are many ways to achieve this but key to all of them is the design of the abstraction layer for the lower level Direct3D device. All systems should communicate to the hardware through the common layer which is designed to provide GPU resource and low level type management.

Direct Removal of Direct3D 9 Dependencies

When porting large, previously tested code bases, it is important to minimize the amount of code changes to those which are absolutely necessary to preserve previously tested behaviors in the code. Best practices include clearly documenting where items change using comments. It's often useful to have a commenting standard for this work which enables quick navigation through the code base and provides measures to determine the amount of code still needing updating.

The following is an example list of standard single line / start block comments which could be used for this work.

// D3D10 REMOVED
Use this where lines / blocks of code are removed
// D3D10 NEEDS UPDATE

It helps to added additional notes to the NEED UPDATE comment that suggests what work / new API should be used for later visits to the code for behavior conversion.

Heavy use of assert(false) should also be used where \\ D3D10 NEEDS UPDATE occurs to ensure you do not unknowingly run errant code

// D3D10 CHANGED
Areas where major changes have occurred should be kept for future reference but commented out
// D3D10 END
End code block qualifier

For multiple lines of source you should use the C style /* */ comments too but add the relevant start / end comments around these areas.

Tricks for Quickly Resolving Application Build Issues

Overriding Direct3D 9 Types

It may be useful to insert a high level header file containing type definitions / overrides for Direct3D 9 base types which are no longer supported by the Direct3D 10 headers. This will help you minimize the amount of changes in the code and interfaces where there is a direct mapping from a Direct3D 9 type to the newly defined Direct3D 10 type. This approach is also useful for keeping code behaviors together in one source file. In this case, it is a good idea to define version neutral / generally named types which describe common constructs used for rendering yet span both Direct3D 9 and Direct3D 10 APIs. For example:

#if defined(D3D9) typedef IDirect3DIndexBuffer9 IDirect3DIndexBuffer; typedef IDirect3DVertexBuffer9 IDirect3DVertexBuffer; #else //D3D10 typedef ID3D10Buffer IDirect3DIndexBuffer; typedef ID3D10Buffer IDirect3DVertexBuffer #endif 

Other Direct3D 10 specific examples of this include:

typedef ID3D10TextureCube IDirect3DCubeTexture; typedef ID3D10Texture3D IDirect3DVolumeTexture; typedef D3D10_VIEWPORT D3DVIEWPORT; typedef ID3D10VertexShader IDirect3DVertexShader; typedef ID3D10PixelShader IDirect3DPixelShader; 

Resolving Link Issues

We advise that you should develop Direct3D 10 and Windows Vista applications using the latest version of Microsoft Visual Studio (version 8 at the time of writing). However, it is possible to build a Windows Vista application which depends on Direct3D 10 using the earlier 2003 version of Visual Studio. Direct3D 10 is a Windows Vista platform component which has dependencies (as with the Server 2003 SP1 platform SDK) on the following lib: BufferOverflowU.lib is needed to solve any buffer_security check linker issues.

Simulating Device CAPs

Many applications including games contain areas of code which depend on device CAPS data being available. This can be worked around by overriding enumeration and forcing device CAPS to sensible values, you should aim to re-visit the areas where there are dependencies on CAPS later for full removal of CAPS where possible.

Driving the Direct3D 10 API

The next section of this article focuses on specific areas for driving the Direct3D 10 API and notes ways to deal with the changes in behavior that Direct3D 10 brings.

Resource Creation

The Direct3D 10 API has designed resources as generic buffer types which have specific bind flags according to the planned usage. This design point was chosen to facilitate near ubiquitous access of resources in the Pipeline for scenarios such as rendering to a vertex buffer then instantly drawing the results without interrupting the CPU. The following example demonstrates allocation of vertex buffers and index buffer where you can see that the resource description only differs by the GPU resource bind flags.

The Direct3D 10 API has provided texture helper methods for explicitly creating texture type resources but as you can imagine, these are really helper functions.

CreateTexture2D()
CreateTextureCube()
CreateTexture3D()

When targeting Direct3D 10, you are likely to want to allocate more items during resource creation time than you are used to with Direct3D 9. This will become most apparent with the creation of Render Target buffers and Textures where you need to also create a view for accessing the buffer and setting the resource on the device.

Tutorial 1: Direct3D 10 Basics

Views

A view is a specifically typed, interface to data stored in a pixel buffer. A resource can have several views allocated on it at once and this feature is highlighted in the Single Pass Render to Cubemap sample contained in this SDK.

Programmers Guide page on Resource Access

CubeMap Sample

Static versus Dynamic Resource Access

For best performance, applications should partition their data use in terms of the static vs dynamic nature of the data. Direct3D 10 has been designed to take advantage of this approach and as such, the access rules for resources have been tightened up over Direct3D 9. For static resources you should ideally create it as IMMUTABLE and populate the resource with its data during creation time.

Direct3D 10 Effects

Use of the Direct3D 10 Effects system is outside the scope of this article. The system has been written to take full advantage of the architectural benefits that Direct3D 10 provides. See the following section more detail on its use:

[ Link unavailable at this time ]

HLSL without Effects

The Direct3D 10 Shader pipeline may be driven without the use of the Direct3D 10 Effects system. Note that in this instance, all constant buffer, shader, sampler and texture binding must be managed by the application itself. See the sample link and following sections of this document for more detail:

Direct3D 10 without Effects sample

Shader Compilation

The Direct3D 10 HLSL compiler brings enhancements to the HLSL language definition and therefore has the ability to operate in 2 modes. For complete support of Direct3D 9 style intrinsics and semantics, compilation should be invoked using the COMPATIBILITY MODE flag which can be specified on a per compile basis.

More information about compatibility mode can be found here:HLSL Compatibility mode

The Direct3D 10 shader model 4.0 specific HLSL language semantics and intrinsics can be found at the link referenced below. Major changes in syntax from Direct3D 9 HLSL to take the most notice of are in the area of texture access. The new syntax is the only form supported by the compiler outside of compatibility mode.

[ Link unavailable at this time ]

Creation of Shader Resources

The creation of compiled shader instances outside of the Direct3D 10 Effects system is done in a very similar manner to Direct3D 9 however, in Direct3D 10, it is important to keep the Shader Input signature around for later use. The signature is returned by default as part of the shader blob but may be extracted to reduce the memory requirements if needed.

[ Link unavailable at this time ]

Shader Reflection Layer Interface

The shader reflection layer is the interface by which information about the shader requirements may be obtained. This is particularly useful when creating Input Assembly linkages (see below) where you may need to traverse the shader input requirements to ensure you are supplying the correct input structure to the shader. You can create an instance of the reflection layer interface at the same time as creating an instance of a compiled shader.

Input Assembler Layouts - Vertex Shader / Input Stream Linkage

The Input Assembler (IA) replaces the Direct3D 9 style Vertex Stream Declaration and its description structure is very similar in form. The main difference that the IA brings is that the IA layout object created must directly map to a specific format of shader input signature. The mapping object created to link the input stream to shader may be used across any number of shaders where the shader input signature matches that of the shader used to create the Input Layout.

To best drive the pipeline with static data, you should consider the permutations of input stream format to possible shader input signatures and create the IA layout object instances as early as is possible and reuse them where possible.

Impact of Shader Dead Code Removal

The following section details a significant difference between Direct3D 9 and Direct3D 10 that is likely to require careful handling in your engine code. Shaders which contain conditional expressions often have certain code paths removed as part of the compilation process. In Direct3D 9, any input elements that match the associated code removed are also from their shader input structure. This no longer occurs in Direct3D 10 as the intention is to allow the same Input Signature to be used across all possible permutations of the shader code without invoking the rather costly change of Input Layout. This has an impact on the engine when handling large shaders and creating Input Layouts. Elements which are removed by dead code optimizations in the compiler must still be declared in the Input Structure. The following example demonstrates this situation:

Vertex Shader Input Structure Example

typedef struct { float4 pos: SV_Position; float2 uv1 : Texcoord1; float2 uv2 : Texcoord2; * } VS_INPUT; 

* Direct3D 9 dead code removal would remove the declaration in the shader due to conditional dead code removal

float4x4 g_WorldViewProjMtx; bool g_bLightMapped = false; VS_INPUT main(VS_INPUT i) { VS_INPUT o; o.pos = mul( i.pos, g_ WorldViewProjMtx); o.uv1 = i.uv1; if ( g_bLightMap ) { o.uv2 = i.uv2; } } 

In the above example, under Direct3D 9, the uv2 element would be removed due to dead code optimizations in the compiler. Under Direct3D 10, the dead code will still be removed but the shader Input Assembler layout requires the definition of the input data to exist. The shader reflection layer provides the means to handle this situation in a generic manner whereby you can traverse the Shader Input requirements and ensure that you provide a full description of the Input Stream to shader signature mapping. The following code snippet demonstrates use of the reflection layer to determine shader requirements during Input Assembler layout specification:

// This example helper function checks the Shader Signature to see if // it expects a particular semantic // The HardwareShader_t input structure contains a pointer to a // previously acquired shader reflection layer as follows: // // typedef struct HardwareShader_s // { // ID3D10Blob *pShaderBlobwithSignature; // ID3D10ShaderReflection *IReflect; // // // DEBUG - helps to keep the shader filename around for debugging // #ifdef _DEBUG // char filename[MAX_PATH]; // #endif // // } HardwareShader_t; // bool CheckShaderSignatureExpectations(const HardwareShader_t *pShader, const LPCSTR pSemantic) { D3D10_SHADER_DESC shaderDesc; D3D10_SIGNATURE_PARAMETER_DESC paramDesc; Assert(pShader); Assert(pSemantic); Assert(pShader->IReflect); pShader->IReflect->GetDesc(&shaderDesc); for (UINT k=0; k<shaderDesc.InputParameters; k++) { pShader->IReflect->GetInputParameterDesc( k, &paramDesc); if (wcscmp( pSemantic, paramDesc.SemanticName)==0) return true; } return false; } 

State Object Creation

When porting engine code, it may help to initially use a default set of state objects and disable all Direct3D 9 device render state / texture state setting. This will cause rendering artifacts but is the quickest way to get things up and running. You can later construct a state object management system which can use a compound key to enable maximum reuse of the number of state objects being used.

Porting Content

Texture Formats

The format names for Direct3D 9s DXT* texture formats have been changed and are now part of the DXGI headers. The DXGI component is responsible for allocating and managing buffer data Direct3D 10 provides wrapper functions for ease of use purposes. As such DXGI has the responsibility of defining the supported color format types in Direct3D 10. Mapping of Direct3D 9 format names are listed in the following chart:

Link to Chart which should be added as another page in the docs:

Direct3D 9 Texture/Vertex/Index Format Equivalent Direct3D 10 Format.
D3DFMT_UNKNOWN DXGI_FORMAT_UNKNOWN
D3DFMT_R8G8B8 Not available
D3DFMT_A8R8G8B8 Not available
D3DFMT_X8R8G8B8 Not available
D3DFMT_R5G6B5 Not available
D3DFMT_X1R5G5B5 Not available
D3DFMT_A1R5G5B5 Not available
D3DFMT_A4R4G4B4 Not available
D3DFMT_R3G3B2 Not available
D3DFMT_A8 DXGI_FORMAT_A8_UNORM
D3DFMT_A8R3G3B2 Not available
D3DFMT_X4R4G4B4 Not available
D3DFMT_A2B10G10R10 DXGI_FORMAT_R10G10B10A2
D3DFMT_A8B8G8R8 DXGI_FORMAT_R8G8B8A8_UNORM & DXGI_FORMAT_R8G8B8A8_UNORM_SRGB
D3DFMT_X8B8G8R8 Not available
D3DFMT_G16R16 DXGI_FORMAT_R16G16_UNORM
D3DFMT_A2R10G10B10 Not available
D3DFMT_A16B16G16R16 DXGI_FORMAT_R16G16B16A16_UNORM
D3DFMT_A8P8 Not available
D3DFMT_P8 Not available
D3DFMT_L8 DXGI_FORMAT_R8_UNORM Note: Use .r swizzle in shader to duplicate red to other components to get D3D9 behavior.
D3DFMT_A8L8 Not available
D3DFMT_A4L4 Not available
D3DFMT_V8U8 DXGI_FORMAT_R8G8_SNORM
D3DFMT_L6V5U5 Not available
D3DFMT_X8L8V8U8 Not available
D3DFMT_Q8W8V8U8 DXGI_FORMAT_R8G8B8A8_SNORM
D3DFMT_V16U16 DXGI_FORMAT_R16G16_SNORM
D3DFMT_W11V11U10 Not available
D3DFMT_A2W10V10U10 Not available
D3DFMT_UYVY Not available
D3DFMT_R8G8_B8G8 DXGI_FORMAT_G8R8_G8B8_UNORM (in DX9 the data was scaled up by 255.0f, but this can be handled in shader code).
D3DFMT_YUY2 Not available
D3DFMT_G8R8_G8B8 DXGI_FORMAT_R8G8_B8G8_UNORM (in DX9 the data was scaled up by 255.0f, but this can be handled in shader code).
D3DFMT_DXT1 DXGI_FORMAT_BC1_UNORM & DXGI_FORMAT_BC1_UNORM_SRGB
D3DFMT_DXT2 DXGI_FORMAT_BC1_UNORM & DXGI_FORMAT_BC1_UNORM_SRGB Note: DXT1 and DXT2 are the same from an API/hardware perspective... only difference was premultiplied alpha, which can be tracked by an application and doesn't need a separate format.
D3DFMT_DXT3 DXGI_FORMAT_BC2_UNORM & DXGI_FORMAT_BC2_UNORM_SRGB
D3DFMT_DXT4 DXGI_FORMAT_BC2_UNORM & DXGI_FORMAT_BC2_UNORM_SRGB Note: DXT3 and DXT4 are the same from an API/hardware perspective... only difference was premultiplied alpha, which can be tracked by an application and doesn't need a separate format.
D3DFMT_DXT5 DXGI_FORMAT_BC3_UNORM & DXGI_FORMAT_BC3_UNORM_SRGB
D3DFMT_D16 & D3DFMT_D16_LOCKABLE DXGI_FORMAT_D16_UNORM
D3DFMT_D32 Not available
D3DFMT_D15S1 Not available
D3DFMT_D24S8 Not available
D3DFMT_D24X8 Not available
D3DFMT_D24X4S4 Not available
D3DFMT_D16 DXGI_FORMAT_D16_UNORM
D3DFMT_D32F_LOCKABLE DXGI_FORMAT_D32_FLOAT
D3DFMT_D24FS8 Not available
D3DFMT_S1D15 Not available
D3DFMT_S8D24 DXGI_FORMAT_D24_UNORM_S8_UINT
D3DFMT_X8D24 Not available
D3DFMT_X4S4D24 Not available
D3DFMT_L16 DXGI_FORMAT_R16_UNORM Note: Use .r swizzle in shader to duplicate red to other components to get D3D9 behavior.
D3DFMT_INDEX16 DXGI_FORMAT_R16_UINT
D3DFMT_INDEX32 DXGI_FORMAT_R32_UINT
D3DFMT_Q16W16V16U16 DXGI_FORMAT_R16G16B16A16_SNORM
D3DFMT_MULTI2_ARGB8 Not available
D3DFMT_R16F DXGI_FORMAT_R16_FLOAT
D3DFMT_G16R16F DXGI_FORMAT_R16G16_FLOAT
D3DFMT_A16B16G16R16F DXGI_FORMAT_R16G16B16A16_FLOAT
D3DFMT_R32F DXGI_FORMAT_R32_FLOAT
D3DFMT_G32R32F DXGI_FORMAT_R32G32_FLOAT
D3DFMT_A32B32G32R32F DXGI_FORMAT_R32G32B32A32_FLOAT
D3DFMT_CxV8U8 Not available
D3DDECLTYPE_FLOAT1 DXGI_FORMAT_R32_FLOAT
D3DDECLTYPE_FLOAT2 DXGI_FORMAT_R32G32_FLOAT
D3DDECLTYPE_FLOAT3 DXGI_FORMAT_R32G32B32_FLOAT
D3DDECLTYPE_FLOAT4 DXGI_FORMAT_R32G32B32A32_FLOAT
D3DDECLTYPED3DCOLOR Not available
D3DDECLTYPE_UBYTE4 DXGI_FORMAT_R8G8B8A8_UINT Note: Shader gets UINT values, but if Direct3D 9 style integral floats are needed (0.0f, 1.0f... 255.f), UINT can just be converted to float32 in shader.
D3DDECLTYPE_SHORT2 DXGI_FORMAT_R16G16_SINT Note: Shader gets SINT values, but if Direct3D 9 style integral floats are needed, SINT can just be converted to float32 in shader.
D3DDECLTYPE_SHORT4 DXGI_FORMAT_R16G16B16A16_SINT Note: Shader gets SINT values, but if Direct3D 9 style integral floats are needed, SINT can just be converted to float32 in shader.
D3DDECLTYPE_UBYTE4N DXGI_FORMAT_R8G8B8A8_UNORM
D3DDECLTYPE_SHORT2N DXGI_FORMAT_R16G16_SNORM
D3DDECLTYPE_SHORT4N DXGI_FORMAT_R16G16B16A16_SNORM
D3DDECLTYPE_USHORT2N DXGI_FORMAT_R16G16_UNORM
D3DDECLTYPE_USHORT4N DXGI_FORMAT_R16G16B16A16_UNORM
D3DDECLTYPE_UDEC3 Not available
D3DDECLTYPE_DEC3N Not available
D3DDECLTYPE_FLOAT16_2 DXGI_FORMAT_R16G16_FLOAT
D3DDECLTYPE_FLOAT16_4 DXGI_FORMAT_R16G16B16A16_FLOAT

For uncompressed formats, DXGI has limited the support for arbitrary pixel format patterns; all uncompressed formats must be of type RGBA. This may require swizzling of existing assets pixel formats which we advise that you compute as an offline pre-process pass where possible.

Porting Shaders

Direct3D 10 Shaders are Authored in HLSL

Direct3D 10 limits the use of assembly language to that of debugging purposes only, therefore any hand written assembly shaders used in Direct3D 9 will need to be converted to HLSL.

Shader Signatures and linkage

We have already discussed the requirements for Input Assembly linkages to Vertex shader input signatures earlier in this document (see above). Note that the Direct3D 10 runtimes have also tightened the requirements for stage to stage linkage between shaders. This change will affect shader sources where the binding between stages may not have been fully described under Direct3D 9. For example:

VS_OUTPUT PS_INPUT float4 pos : SV_POSITION; float4 pos : SV_POSITION; float4 uv1 : TEXCOORD1; float4 uv1 : TEXCOORD1; float4x3 tangentSp : TEXCOORD2; float4 tangent : TEXCOORD2; * float4 Color : TEXCOORD6; float4 color : TEXCOORD6; 

* Broken VS - PS Linkage - even though the Pixel Shader may not be interested in the full matrix, the linkage must specify the full float4x3.

Note, the linkage semantics between stages must match exactly however, the target stages inputs may be a prefix of the values being output. In the example above, the pixel shader could have position and texcoord1 as the only inputs, but it could not have the position and texcoord2 as the only inputs due to the ordering constraints.

HLSL Shader Stage linkages

Linkages between shaders may occur at any of the following points in the pipeline:

Input Assembler to Vertex Shader
Vertex to Pixel Shader
Vertex to Geometry Shader
Geometry Shader to Pixel Shader
Geometry Shader to Stream Out

Constant Buffers

For ease of porting content from Direct3D 9 an initial approach to constant management outside of the Effects system might involve the creation of a single constant buffer containing all the required constants. It is important for performance to order constants into buffers by the expected frequency of update. This organization will reduce the amount of redundant constant sets to a minimum.

[ Link unavailable at this time ]

Additional Direct3D 10 Differences to Watch For

Integers as Input

In Direct3D 9, there was no real hardware support for integer data types, however in Direct3D 10 hardware supports explicit integer types. If you have floating point data in your vertex buffer, then you must have a float input. Otherwise the int will be the bit pattern representation of the floating point value. Integer inputs are also not allowed as input to a pixel shader unless the value is marked constinterp which is due to the interpolation for the pixel shader not being an integer interpolation.

Reference Counting Behavior Changes

Unlike previous Direct3D versions, the various Set functions will not hold a reference to the devices objects. This means that the application must ensure that it holds a reference on the object for as long as it would like that object to be bound to the pipeline. When the ref count of the object drops to zero, then the object will be unbound from the pipeline as it is destroyed. This style of reference holding is also known as weak-reference holding, so therefore each bind location on the Device object holds a weak-reference to the interface/ object. Unless explicitly mentioned otherwise, this behavior should be assumed for all Set methods. Whenever destruction of an object causes a bind point to be NULLed out, the Debug Layer will issue a warning. Note, calls to device Get methods such as OMGetRenderTargets() will increase the reference count of objects being returned.

Test Cooperative Level

The functionality of the D3D9 API IDirect3DDevice9::TestCooperativeLevel is analogous to setting the DXGI_PRESENT_TEST flag in the Flags parameter of IDXGISwapChain::Present.

'Or.......... > Work' 카테고리의 다른 글

Scaleform - GFx [Product]  (0) 2010.08.26
Scalform - GFx [Prologue]  (1) 2010.08.09
Overview of the Major Structural Changes in Direct3D 10  (0) 2009.08.27
Scene Graph Rendering  (0) 2009.08.27
kd-tree Introduction  (0) 2009.08.27
Grass Rendering  (0) 2009.08.27

원문 : http://www.nd.edu/~chuang1/summer03Images/scenegraph01.pdf

 

Scene Graph Rendering

 

 

Dirk Reiners

OpenSG Forum

dirk@opensg.org

 

이 수업에서 이 부분은 렌더링을 위한 씬그래프 시스템에 대해서 설명할 것이다. 씬그래프는 응용프로그램 개발을 단순화하고 이용 가능한 그래픽 하드웨어를 최적의 환경으로 사용할 수 있도록 도와줄 수 있다.

 

이 문서는 당신이 3D 컴퓨터 그래픽스에 대한 몇몇 기본 지식들을 가지고 있다고 가정한다. 만약 폴리곤, 방향성 광원(directional light source), 그리고 텍스처가 당신에게 아무런 의미도 없다면 당신은 이 수업을 따라가는데 문제를 느끼게 될 것이다. 이상적인 수준은 OpenGL을 사용하는 프로그램을 작성한 적이 있거나, "OpenGL Programming Guide"[1] 나 "Computer Graphics"[2]를 읽어본 수준이다.(역주 : D3D 라도 상관없을 듯)

 

첫 번째 섹션은 씬그래프의 기본 구조 및 표준 OpenGL 프로그램과의 차이에 대해서 설명한다. 주변에는 오픈 소스 및 상업용의 씬그래프가 많이 널려 있기 때문에 섹션 2는 가장 일반적으로 사용되는 것에 대한 짧은 개관을 제공한다. 나머지 장에서는 대부분의 씬그래프에 적용되는 일반 개념 및 특정 예제로서 OpenSG 의 사용에 대해 설명한다. 그 다음의 두 섹션은 일반적인 노드 구조체에 대해서 설명하고 그래프를 순회(traverse)하는 방법에 대해서 설명한다. 가장 중요한 단말 노드인 기하도형은 섹션 5에 설명되어 있다. 디스플레이된 기하도형, 변환 상태 및 재질 등을 지정하는 다른 것들은 섹션 6에서 다룬다. 몇 개의 다른 씬 그래프 지정 기능은 섹션 7에 설명되어 있듯이 다른 노드 유형 내부에 감춰져 있다. 씬 그래프의 메모리 공간을 최소화하기 위해 데이터는 여러 가지 방식으로 공유될 수 있는데, 섹션 8은 세부사항을 제공한다. 섹션 9 는 멀티스레딩에서의 중요한 부분 및 씬 그래프가 그것을 지원하기 위해서 어떤 것이 수행되는 지에 대해 다룬다. 섹션 10은 모든 부분에서 예제로서 사용되었던 OpenSG 에 대해서 약간 다룬다. 마지막 섹션은 씬 그래프의 장단점 및 씬그래프를 사용하기 좋은 상황에 대해서 다룬다(힌트 : 그런 상황이 그렇게 많지는 않다).

 

1. 씬그래프란 무엇인가?

 

OpenGL 과 같은 저수준 그래픽 라이브러리들은 immediate 모드 기반이다. 모든 프레임에 대해서 응용프로그램이 그래픽 하드웨어로 모든 데이터를 전송하는 것이 필수적이다. 통신 모델은 "이 폴리곤과 이것, 그리고 이것을 취하고 렌더링 해주세요"라는 것과 같다.

 

씬그래프는 retained 모드 기반이다. 데이터는 한 번만 전달되고 필요할 때만 갱신된다. 통신 모델은 "이것은 내 데이터이며 이제 이미지와 저것 그리고 저것을 렌더링해 주세요"라는 것과 같다.

 

씬그래프가 관리하는 데이터는 그래프로서 구조화된다. 노드는 직접 링크에 의해 서로 연결되며, 루트 노드는 씬 데이터의 시작점을 정의하는데 사용된다. 렌더링을 위해서 이 그래프는 루트로부터 순회를 시작한다. 씬그래프는 보통 acyclic(역주 : 비환식) 그래프이다. 즉 한 노드에서 루트로 가는 과정에 있는 그래프 내의 다른 상위 노드들 사이의 연결이 존재하지 않는다(원문 :  i.e. there are no links from a node to any of its predecessors in the graph on the way to the root.). 이것은 루프를 생성하고 결국 순회를 무한 루프로 이끈다.

씬그래프와 수학적 그래프의 차이는 씬그래프들은 여러 가지 다양한 요소들을 포함하고 있다는 것이다. 즉 노드들은 서로 다른 유형이다. 인테리어와 단말 노드 사이에 눈에 띄는 차이가 있다. 단말 노드는 가시적인 기하도형을 담고 있으며, 인테리어 노드는 그래프를 논리적 그룹(fig. 1 참조)으로 구조화한다.


 
여러 종류의 인테리어 노드가 존재하지만 가장 기본적인 형태는 단일 그룹이다. 다른 인테리어 유형은 섹션 6과 7 에서 설명되며 많지는 않지만 다른 유형의 단말 노드로 존재하기도 한다. 그렇지만 가장 중요한 단말 노드는 기하도형이다(섹션 5를 참조).
 
2. 어떤 씬그래프가 있는가?
 
씬그래프는 오랫동안 존재해 왔다. 다음 리스트는 완벽하지 않지만 가장 잘 알려진 것들이다 :
 
    - OpenSG (http://www.opensg.org)[3]
    - Open Inventor (http://oss.sgi.com/projects/inventor)[5]
    - PLIB (http://plib.sf.net)
    - SGL (http://sgl.sf.net)
    - OpenRM (http://openrm.sf.net)
    - Open Scene Graph (http://www.openscenegraph.org)
    - Performer (http://www.sgi.com/products/performer)[4]
 
이들 모두는 C++로 작성되어 있으며 Inventor 와 Performer는 C 인터페이스도 가지고 있다. SourceForge(www.sf.net)에서 "scene graph" 라고 검색하면 다른 많은 시스템들을 찾을 수 있다. 그러나 대부분은 더 이상 개발되지 않는 것들이다.
 
이들 중 세 가지(Performer, Open Scene Graph, OpenSG) 는 VR Juggler 바인딩을 가지고 있으며, 결국 VR 응용프로그램을 위한 좋은 후보이다. Performer 는 오픈 소스가 아니고 상업 제품임에 주의하라.
 
3. 노드 구조
 
씬그래프의 모든 노드는 몇 가지 공통적인 속성을 가지고 있다.
 
하나는 경계 볼륨이다. 노드의 경계 볼륨은 단순한 볼륨인데, 보통 축 정렬 경계상자(AABB) 나 구이다. 그것들은 현재의 노드의 하위에 있는 모든 노드들의 내용을 둘러 싼다. 그것은 씬그래프에 의해 노드의 가시성을 검사하기 위해서 사용된다. 만약 노드의 경계 볼륨이 가시 영역 바깥쪽에 있다면, 그 아래의 모든 노드들은 비가시화될 것이며 OpenGL 로 넘길 필요가 없을 것이다. 대규모의 씬에서 이것은 렌더링 속도에 있어 큰 영향을 끼친다.
 
여기에서 다른 씬그래프들은 조직화에 있어 약간의 다른 차이를 보인다. OpenSG 는 자식이 단말 노드로 사용되지 않더라도 모든 노드 내부에 자식의 리스트를 유지한다. 왜냐하면 그것은 구조를 단일화하고 순회를 단순화하기 때문이다. 또한 그것은 부모 노드의 포인터를 유지한다. 부모 및 그것들의 중요성에 대해서 세부적으로 알고자 한다면 섹션 8을 참조하라.
 
OpenSG의 특징은 노드가 Node 자체와 Core, 이 두 개로 분할된다는 것이다. Node 는 경계 볼륨, 부모에 대한 포인터, 자식 노드들에 대한 포인터 등과 같은 일반 정보를 모두 유지한다. Core 는 다른 유형의 노드들과 구분하기 위해서 사용된다(예제 그래프를 위해서는 fig.2 를 참조).

가장 단순한 Core 는 Group 인데, 이는 별다른 정보를 가지고 있지 않고 단지 그래프를 구조화하기 위해서만 사용된다.

4. 순회
 
씬그래프나 일반목적의 그래프 상에서의 기본 연산은 그래프의 순회이다. 루트 노드에서 시작해서 모든 노드가 방문될 때까지 노드들 사이의 링크를 따라간다. 대부분의 씬그래프 순회는 깊이 우선이다. 즉 같은 수준의 노드로 가기 이전에 자신의 모든 자식 노드를 순회한다(fig. 3 참조).
 

어떤 순회는 씬그래프 시스템에 의해 미리 정의되지만, 응용프로그램이 씬그래프를 순회하는 것도 가능하다. 어떤 유틸리티 함수는 그것을 매우 단순화할 수도 있다.

 

4-1 Actions

 

순회를 캡슐화하는 클래스들은 OpenSG 에서는 Actions 라고 불린다. 순회를 위해서 루트 노드와 함께 호출되는 것이 action 오브젝트이다. 다른 시스템들은 노드 메서드를 사용하지만, 기본 전제는 항상 루트 노드로부터 순회를 시작하는 것이다. 노드의 종류에 따라 다른 연산이 실행되고, 자식들은 순회로부터 선택되거나 배제된다.

다른 시스템에서는 다른 종류의 순회를 할 수 있다. 가장 중요한 것은 Rendering 순회이지만, 대부분의 시스템은 Intersect (역주 : 마우스 선택이나 충돌과 같은 검사를 위한) 순회도 포함하고 있다.
 
4-1-1. Render Action
 
(다른 시스템에서는 Draw 라 불리기도 하는)RenderAction 의 역할은 씬그래프의 데이터를 저수준 그래픽 라이브러리 명령어로 변경해, 결국 그래프를 이미지로 변경하는 것이다.
 
여기서 흥미로운 부분은 씬그래프가 수행할 수 있는 최적화이다. 왜냐하면 그것은 전체 씬에 대한 고차원의 지식을 가지고 있기 때문이다. 단순히 뷰어의 FOV(field of view, 시야각) 내에 존재하는지 여부를 통해 노드나 전체 하위 트리의 가시성 테스트할 수도 있지만, 더 복잡한 검사도 가능하다. 그러나 단순한 테스트라 하더라도 씬에 대해 고려해야할 많은 데이터를 이미 제거했기 때문에 비용이 적어진다.(원문 : It can test nodes or whole subtrees for visibility, in the simplest case just for inclusion in the field of view of the viewer, but more complex tests are possible. Even the simple test however will already remove a large part of the data from consideration for most scenes.)
 
씬그래프는 전체 씬을 렌더링하기 위해 저수준 라이브러리의 상태를 만드는데 필요한 변경을 최적화하고 최소화할 수도 있다. 이것은 파이프라인을 따라가는 시스템에 대해 렌더링 효율을 괄목할 만큼 증가시켜줄 수 있다.
 
렌더링은 씬그래프 시스템에서 대부분의 노력이 배치된 곳이며, 가장 효율적인 그래픽 하드웨어 용법을 만드는 방식에 대한 경험을 포함하고 있다. 그래서 결국 높은 렌더링 효율을 기대할 수 있는 것이다.
 
4-1-2. Intersect Action
 
다른 일반적인 action 은 IntersectAction 이다. 이것은 그래프의 기하도형이 레이(ray, 종종 레이 집합)에 충돌하는지 검사하며 결국 씬 내의 기하 오브젝트에 대한 충돌 테스트를 허용하게 된다. 이들은 오브젝트 픽킹 및 선택 혹은 땅바닥 기하도형으로부터 일정한 거리를 유지하기 위한 단순한 충돌 검사에 사용될 수 있다.
 
다시 말하지만 씬그래프에 내장된 고수준 데이터는 세부적인 기하도형과 함께 다뤄지기 이전에 씬의 많은 부분을 테스트함으로써 최적화될 수 있다.  결국 씬그래프는 수작업 검사보다 더 효율적일 수 있지만 그것을 프로그래밍하기 위해서는 응용프로그램 작성자가 괴로워진다고 말할 수 잇다.
씬그래프가 항상 광선추적(ray-tracing) 렌더러를 대체하는 데 있어 유용지는 않을 것이다. 그럼에도 이것은 더욱 특수화된 많은 요소들을 포함하고 있는 경향이 있기 때문에 광선 추적을 위한 더 효율적인 자료 구조가 될 수 있다.
 
4-2 단순 순회
 
응용프로그램은 종종 씬그래프가 제공하지 않는, 예를 들어 특정 상태를 만족하거나 만족하지 않는 오브젝트를 검색하는 것과 같은 특별한 기능을 구현하기 위해서 씬그래프를 순회할 필요성을 가지게 된다.
 
물론 응용프로그램은 자체적으로 전체 순회를 구현하거나 씬그래프에 의해 구현되어 있는 기본 action 중 하나로부터 상속받을 수도 있다. 그러나 대부분의 응용프로그램의 순회는 매우 간단하며 복잡한 순회를 위해 필요한 하위 구조 전체를 필요로 하지는 않는다.
 
이런 경우를 위해 OpenSG 를 포함하는 일부 시스템은 그래프를 순회하고, 만나게 되는 모든 노드를 사용자 제공 함수나 메서드로 넘겨 작업하고, 순회를 계속할지 말지를 결정하기 위한 단순한 방법을 제공한다. OpenSG 에서는 이 함수가 traverse() 라 불리며, 여러 상황에서 몇 가지 다양한 방식으로 이용할 수 있다.
 
세부적인 것은 이 문서의 뒷 부분으로 넘기도록 한다. 세부적인 것을 원한다면 OpenSG traverse tutorial 을 참조하라(섹션 10에 튜토리얼을 얻는 방법이 나와 있다).

5. 기하도형
 
씬그래프에서 가장 중요한 노드 유형은 기하도형인데, 이것은 최종적으로 렌더링되는 기하 데이터를 저장하고 있기 때문이다. OpenGL 에서 기하도형은 glBegin() 의 첫 번째 호출과 glEnd() 의 마지막 호출 사이에서 오브젝트에 대해 발생 가능한 모든 것들을 유지하고 있다. OpenGL 은 매우 유연하기 때문에, 그 데이터를 지정하기 위한 여러 가지 가능한 방식이 존재한다.
 
공통 인터페이스 스타일이 제공되며 그것은 모든 현재 씬그래프에 의해서 약간 다양하게 사용된다. 그것은 이 데이터를 분리된(개별) 배열에 나누어 저장하는데 기반하며, OpenGL VertexArray 인터페이스와 매우 유사하다.
 
5-1. 정점 속성
 
OpenGL 에서 한 프리미티브의 각 정점은 여러 개의 속성을 가질 수 있다. 물론 가장 중요한 것은 정점의 위치이다. 다른 공통적인 것은 법선인데, 이는 조명 계산, 색상, 텍스처 좌표를 위해서 사용된다. 씬그래프는 개별 배열을 이들 속성을 위해서 사용한다. 이 배열들이 관리되는 방식은 씬그래프마다 다르다. 가장 간단한 경우 씬그래프 자체는 단지 데이터에 대한 포인터만을 저장하고, 응용프로그램이 데이터를 다룰 책임이 있다. 다른 선택은 데이터를 기하도형 자체에 저장하는 것인데, 일반적으로 STL 벡터나 이와 유사항 동적 크기 배열 형식에 저장한다.
 
이러한 접근의 장점은 그 데이터의 유형이 고정된다는 것이다. OpenGL은 그것이 받아들일 수 있는 종류의 데이터에 대해서 매우 유연하며, 다른 응용프로그램들은 다른 필요성을 가진다. 개별 유형의 기하도형을 다른 매개변수 유형을 위해 생성하는 것이 가능하다. 그러나 다른 속성 유형을 위한 다른 차원(1 ~ 4)의 조합이나 다른 데이터형(unsigned/signed, byte/short/int/float/double)의 조합은 현실적이지 않은 완벽함을 위해 수 백개의 클래스를 생성하게 하는 상황을 만들게 될 것이다.
 
OpenSG 는 속성을 Properties 라는 자신만의 자료 구조에 넣음으로써 그 문제를 해결한다. Geometry Core 자체는 단지 이러한 Properties 에 대한 참조만을 유지한다. 모든 종류의 속성을 위해서 Properties 추상 기저 클래스가 존재하며, 여러 유형의 구체적인 버전이 존재한다. 이러한 방식으로 단일 Geometry Core 유형은 모든 다양한 자료형에 접근할 수 있다.

 
5-2. 프리미티브
 
정점들 자체는 기하도형을 정의하기에는 충분하지 않으며, 그것들은 올바른 방식으로 연결되어야 한다. OpenGL 은 정점들을 연결하기 위한 여러 개의 다양한 방식을 가지고 있다. 그것들을 단순한 점이나 삼각형, 쿼드 및 폴리곤을 통해 연결된 라인으로 그리는 것으로부터 삼각형 스트립이나 팬과 같은 연결된 프리미티브로 그리는 것까지 아주 다양하다. 이들 역시 씬그래프에 의해 매핑될 필요가 있다.

이것은 여러 가지 방식으로 수행될 수 있다. 하나는 여러 가지 프리미티브 유형을 위한 여러가지 기하도형을 가지고 있으며, 단지 하나의 기하도형 당 하나의 프리미티브만을 허용하는 것이다. 어떤 시스템들은 Geometry 를 각각이 자신만의 프리미티브 유형을 가질 수 있는 여러 개의 소규모 기하도형으로 분할함으로써 부하를 줄이려고 시도하기도 한다.
기하도형은 프리미티브 유형이 모두 같더라도 반드시 한 개 이상의 프리미티브 인스턴스를 유지해야만 한다. 일부 유형들(예를 들어 점, 라인, 삼각형)에 대해서는 단일 정점 카운트면 충분하다. 왜냐하면 그것들은 이미 고정된 개수의 정점에 의해 정의된 여러 개의 기하 프리미티브를 포함하기 때문이다. 다른 유형들(예를 들어 폴리곤, 스트립, 팬)은 프리미티브 인스턴스마다 개별 length 를 필요로 한다. 이들 length 는 보통 정점 속성과 같이 기하도형의 속성으로서 저장된다.
 
OpenSG 는 사용할 프리미티브 유형의 리스트를 유지하는 types 속성도 추가함으로써 혼합 프리미티브 유형을 허용한다. 이 types 속성 내의 모든 요소는 lengths 속성 내의 요소들과 관련이 있는데, length 를 모든 프리미티브 유형 인스턴스에 할당함으로써 그것을 정의하게 된다(fig. 4 를 참조). 이것은 여러 개의 프리미티브를 허용함으로써 최대의 유연성을 제공하며, 동질성과 함께 이질성 또한 제공한다.
 
5-3. 인덱싱
 
5-3-1. 단일 인덱싱
 
막혀있는 서피스, 정점들은 종종 여러 번 사용된다. 쿼드를 구성하는 단순한 그리드에서, 거의 모든 정점들은 네 개의 프리미티브에 의해서 사용될 것이다. 이 정점들을 네 번 저장하는 것은 스트림에 필요한 메모리를 많이 증가시키고, 결국 허용될 수 없게 된다.
 
그래서 인덱싱 레이어가 프리미티브와 정점들 사이에 삽입된다. 정점들을 property 에 주어진 순서대로 사용하는 대신데, 사용될 정점들이 중복되지 않도록 지정하기 위해서 인덱스가 사용된다. 2 혹은 4 바이트인 인덱스는 일반적으로 32 에서 120 바이트를 사용하는 정점보다 적은 양의 데이터를 사용하기 때문에, 이것은 메모리 소비를 꽤 줄여 준다(fig. 5 참조).
 
그러나 인덱싱은 부가적인 오버헤드를 야기한다. 즉 그것은 필요할 때만 사용되야 한다. 일부 씬그래프는 가하도형 노드 유형의 형태에서 차이를 보인다. OpenSG 는 단지 IndexProperty 의 유무 여부만을 검사한다.

 

5-3-2. 다중 인덱스

 

지금까지 속성은 모두 서로 연결되어 있었다. 즉 만약 colors, normals 가 존재한다면, 각 정점 위치에 대해 색상과 법선이 존재했다. 이것은 너무 많을 수도 있고 동시에 부족할 수도 있다.

 

만약 색상이 단지 제한된 하위집합만을 취한다면, 몇 십개의 색상만이 필요할 것이다. 즉 모든 정점들을 위해 개별 색상을 보유하는 것은 필요 이상의 메모리를 소비하게 되는 것이다. 한편으로 단일 정점 위치는 서로 다른 법선을 필요로 할 수 있다. 보통의 경우 면은 그것이 정점 기반으로만 수행된다고 해도 픽셀당 조명 계산의 느낌을 부여하기 위해서 smooth-shaded 처리가 된다. 만약 각진 모서리를 원한다면, 단일 정점은 서로 다른 법선을 사용해야만 한다.

 

다중 인덱싱은 가장 단순한 형태는 정점당 속성과 면당 속성 사이의 차이이다. 면당 속성은 정점과 연결되어 있지 않고 면과 연결되어 있다. 그것들은 보통 인덱싱되지 않는다. 그것들은 대부분의 경우 위에 주어진 법선 문제를 해결하지만, 색상 예제에서 주어진 반대 문제는 해결할 수 없다. 더욱 유연한 해결책은 모든 속성에 대해서 개별 인덱스를 소유하는 것이다.

 

OpenSG 는 다른 접근을 사용한다 : 삽입 인덱스(interleaved indices).  정점 당 인덱스 속성으로부터 단일 값을 취하는 대신에, 다중 값이 사용될 수 있다. 어떠한 인덱스가 어떠한 속성을 위해 사용되어야 하는지를 정의하기 위해서 인덱스 매핑이 사용된다. 인덱스 맵의 모든 요소는 모든 속성 조합을 지정할 수 있는 비트필드(bitfield)이다(역주 : 비트 조합이라는 의미인듯). 이것은 다른 속성을 위해 인덱스를 공유하거나, 각각을 위해 개별 인덱스를 소유하는 것을 가능하게 한다(fig. 6 참조).

 

다중 인덱싱에 있어서 한 가지 문제는 그것이 발생시키는 퍼포먼스 오버헤드이다. 그것은 OpenGL 의 정점 배열에 직접 매핑되지 못하며, 명시적인 호출을 사용해서 현실화되어야만 하는데, 그것은 특히 PC 플랫폼에서 퍼포먼스를 낭비한다. 정적 모델을 위해 이 비용은 그것들을 디스플레이 리스트에 배치함으로써 초기화 단계 안으로 상쇄될 수 있다. 동적 모델을 위해 이 비용은 모델이 렌더링될 때마다 지불되어야 하며, 결국 다중 인덱싱을 사용하기 위한 시도를 할 때는 조심해야 한다.
 
5-4. 접근
 
여러 가지 다양한 기하도형 데이터를 사용하면 접근이 복잡해 질 수 있다. 특히 OpenSG는 다양한 프리미티브 및 데이터형을 지원하는 단일 노드 유형만을 가지고 있다. 기하도형 데이터에 대한 접근을 단순화하기 위한 두 가지 메커니즘이 있다.
 
이 속성은 다른 데이터형을 감추는 일반 인터페이스를 소유한다. 그를 위해 모든 유형의 속성들은 모든 유형의 데이터가 변환될 수 있고 접근 가능한 일반(generic) 데이터형을 소유한다. 예를 들어 법선을 위한 Vec3f 혹은 위치를 위한 Pnt3f. 이 변환은 일부 데이터를 소실할 수 있다. 예를 들어 4D 좌표를 변환하는 것은 4 번째 좌표를 잃어버리도록 만들 것이다. 또한 그것은 퍼포먼스 패널티를 일으킨다. 왜냐하면 가상 함수를 통해서 접근하기 때문이고, 데이터가 복사/변환되어야만 할 것이기 때문이다. 결국 데이터형이 알려져 있고 수 많은 요소들이 접근될 필요가 있다면, 대신 형지정(type-specific) 접근을 사용하는 것을 추천한다.
 
두 번째 메커니즘은 서로 다른 프리미티브 유형 및 인덱싱에 대한 걱정을 극복하는데 도움을 준다 : 반복자(iterators).
 
OpenSG 는 세 가지 유형의 기하도형 반복자를 가지고 있다 : 프리미티브, 면, 삼각형. Geometry 는 STL 컨테이너와 같이 자신을 통해 반복하는데 적당한 반복자를 생성하기 위한 begin 및 end 메서드를 가지고 있다. 그것들은 모두 인덱스 참조해제(dereferencing) 에 대해 주의를 기울였고, 프리미티브의 값에 대한 직접 접근을 허용한다. 그것들은 Geometry 에 대한 접근을 허용하는데, 마치 기하도형의 모든 데이터가 서로 다른 배열에 개별적으로 저장된 것이 아니라, 개별 프리미티브를 위한 특정 자료형의 조합인것처럼 취급한다.
 
서로 다른 반복자 유형 사이의 차이점은 반복자가 어떠한 요소를 반복하고자 고려하고 있는지에 달려 있다. PrimitiveIterator 는 단지 types 속성을 통해서 단계를 진행한다. 즉 삼각형이 삼각형 반복 요소를 스트립(strip)하는 예만을 고려한다. FaceIterator 는 더욱 선택적이며 모든 점과 라인을 무시한다. 그것은 반복시마다 모든 잔존 프리미티브를 3 개나 4 개의 정점 폴리곤으로 분할한다. TriangleIterator 도 이와 유사하지만, 단지 삼각형만을 반환한다.
 
반복자는 임의의 기하도형을 사용해 작업하는 것을 매우 쉽게 만들어 주며, 어떠한 유형 및 인덱스가 사용되어야 하는지에 대해 신경쓰지 않게 해 준다.

 
6. 상태 제어
 
기하도형을 정의하는 것은 그래픽적 씬을 생성하는데 있어서 절반이며, 서피스, 조명, 변환 속성을 정의하는 것이 나머지 절반이다.

6-1. 변환
 
이 문맥에서 변환은 씬 내의 오브젝트를 움직이는 데 사용되는 기하 변환에만 국한되며, 카메라 조작과 관련된 변환에 대해서는 이 수업 노트의 다른 장에서 다룬다.
변환은 완전한 오브젝트에 적용되며, 오브젝트의 일부에 대해서 적용될 수 없다. 또한 변환은 씬그래프의 전체 하위트리에 유용하게 적용되어 혼합 오브젝트나 다중 오브젝트들을 주위로 이동시킬 수 있다. 그래서 이것들은 씬 그래프의 상태 계층을 위한 주요한 예제가 될 것이다.
변환은 행렬을 저장하거나 변환을 정의하는데 필요한 요소들을 저장하는 개별 노드 유형으로서 구체화된다(예를 들어 스케일, 방향, 이동). 변환은 트리의 아래에 있는 모든 것들에 영향을 미치며, 그것은 다른 변환을 포함한다.
 
변환은 축적된다. 즉 새로운 변환은 그것의 상위에 있는 것의 변환을 대체하지 않고 그것을 추가한다. 이것은 로컬 좌표계에서 변환을 정의하는 것을 허용하면서, 전체 시스템을 변환할 수 있도록 해 준다. 그리고 그것들은 계층적 변환 체인을 정의하는 것을 허용한다. 계층적 변환의 사용에 대한 주요 예제는 행성과 달을 가지는 행성계이다.
 
행성계에서 달은 자신의 행성 주변을 회전한다. 동시에 행성은 태양 주변을 회전한다. 절대 좌표로 달의 이동을 지정하는 것은 복잡한 처리가 될 것이다. 그것들을 자신의 행성에 상대적으로 지정하고, 동시에 행성-달 덩어리를 태양 주변으로 움직이는 것이 간단하다.

 
6-2. 광원
 
광원은 씬그래프의 문맥에서 흥미로운 문제를 제시한다. 씬그래프에서 광원노드의 위치는 두 개로 정의될 수 있다. 하나는 광원의 위치와 방향이다. 이것은 자동차에 붙어 있는 헤드라이트와 같은 오브젝트에 광원을 붙이는데 유용하다. 변환 계층을 위해 광원은 자동적으로 자동차의 이동을 따라갈 것이다. 조명에 영향을 받는 것을 정의하기 위해 다른 목적이 존재할 수 있다. 이것은 상태 계층과 관련이 있다. 즉 씬그래프에서 광원 아래에 존재하는 모든 것은 그것에 의해 조명을 받는다.
 
그래프 내에서 광원 위치에 대한 이 두가지 의미는 모순되며, 트리 내의 단일 위치를 사용해서는 해결할 수가 없다. 만약 그래프 내에서 광원의 위치가 한 번에 두 가지 의미를 가진다면, 헤드라이트 시나리오는 불가능할 것이다. 왜냐하면 조명은 단지 그래프 내에서 아래에 있는 것들에만 비칠 것이며, 즉 일반적인 헤드라이트의 행동을 취하지 않고 차의 일부가 아니라 길의 일부가 될 것이다. 그럼에도 불구하고 Inventor 는 이 기법을 사용한다.
 
다른 시스템들은 이 문제를 해결하기 위해서 다른 해법을 사용한다. 하나의 해결책은 모든 광원을 전역으로 정의하는 것이다. 즉 모든 것은 모든 광원에 의해서 조명을 받는다. 이 경우 그래프 내의 위치는 그 조명만의 위치를 잡는데만 사용될 수 있다. 이 해결책은 간단하지만 시스템의 표현력에 제약을 가하게 된다. Performer 는 각 기하도형에 어떠한 광원이 영향을 미치는지를 명시적으로 정의하도록 허용하는 차선책을 사용한다.
OpenSG 는 다른 해결책을 사용한다. 그래프에서 광원의 위치는 상태 계층 요소에 근거해 씬내에서 그것에 의해 영향을 받는 부분을 정의한다. 광원의 위치와 방향은 그래프 내의 다른 요소에  의해서 정의된다. 그 요소는 단지 광원에 의해서 참조되기만 하며 beacon(봉화, 등대?) 이라 불린다.

 
6-3. 재질
 
재질은 기하도형의 서피스 속성을 정의하는데 사용되며, OpenSG 에서는 실제로는 Geometry 노드의 속성이다. 재질의 속성은 대부분 OpenGL 재질 상태로부터 직접 매핑된다. 즉 emissive, ambient, diffuse, specular 색상 및 shininess이다.
 
OpenGL 에 직접적으로 매핑될 수 없지만 올바르게 구현되기 위해 많은 노력을 들인 순결해 보이는 재질은 투명도이다. 투명도와 OpenGL 은 서로 잘 맞지 않는다. 투명한 오브젝트는 다른 모든 오브젝트가 렌더링된 이후에 올바른 블렌딩 함수를 사용해 렌더링될 필요가 있으며, 그것들은 뒤에서 앞의 순서로 그릴 필요가 있다. 완전히 올바르게 그리려면 그것들은 면끼리 비교해 뒤에서 앞으로 그려지며, 겹치는 기하도형에 대해 겹치는 면을 분할하고 정렬해야 한다.
투명도를 위한 전체적이고 완벽한 지원은 매우 소비적이며, 특히 동적인 기하도형의 경우에 더 심하다. 결국 어떠한 씬그래프도 그것을 지원하지 않는다. 그것들에 대한 최선은 오브젝트 간 비교에 의해 투명한 오브젝트를 마지막에 렌더링하고, 뒤에서 앞으로 정렬하는 것을 지원하는 것이다. 즉 오브젝트는 뒤에서 앞으로 렌더링될 것이다(보통 참조 위치에 의해 정렬된다. 예를 들어 경계상자의 중심). 그러나 오브젝트 내부 정렬은 수행되지 않는다.
 
OpenSG 는 SimpleMaterial 과 SimpleTexturedMaterial 클래스를 이를 위해 사용한다. 또한 SimpleTexturedMaterial 은 텍스처 필터링을 정의하기 위한 매개변수와 함께 재질을 위한 텍스처로서의 이미지를 유지한다.

 
7. 다른 노드 유형
 
다른 씬그래프들은 다른 노드 유형의 형성을 위한 부가적인 기능을 제공한다. 이들 중 일부는 매우 ubiquitous 하며, 다른 것들은 적은 시스템에서만 작동한다. 다음은 약간의 일반적인 예들이다.
 
7-1. 스위치
 
Switch 노드는 단순하지만 Group 노드 상에서의 다양성을 위해 유용하다. t selects zero or
one of its children for traversal instead of all of them. 이것은 하위 그래프를 끄거나 모델의 정적 집합을 통해 순환하기 쉬운 방법이다.
 
어떤 시스템은 비트마스크를 사용해 자식 집합을 선택하는 것을 허용한다.
 
7-2. LOD
 
Level of Detail(LOD) 는 다소 단순하지만 대규모 씬에 대한 렌더링을 최적화하는데 효율적인 방법이다. 기본 발상은 멀리 있는 오브젝트들은 가까이 있는 오브젝트보다 덜 세부적으로 렌더링한다는 것이다.
 
이렇게 함으로써 씬그래프는 렌더링되는 오브젝트의 복잡성을 줄일 필요가 있다. 가장 좋고 쉬운 방법은 다른 복잡도를 가지는 여러 가지 버전의 오브젝트를 제공하도록 응용프로그램에 요청하는 것이다. 이들 각각은 어디에서 자신이 사용되어야 하는지를 알기 위해서 보통 관찰자로부터의 거리인 범위를 할당받는다. 이 범위는 다른 버전을 가지고 노드의 자식으로서 LOD 노드에 저장된다.
 
LOD 노드의 작업은 예를 들어 주어진 관찰자의 거리를 위한 올바른 자식을 선택하는 것이다. 일반적으로 그것은 단지 하나의 자식만을 선택하며, 현재 상황에서 가장 적합한 것을 찾는다. 즉 그 중 더 복잡한 것을 디스플레이한다.

 
7-3. 파티클
 
종종 단순하지만 동적으로 이동하는 대규모의 오브젝트들이 필요하다. 그 예는 ball-and-stick 분자 모델에서의 ball인 순환적인 대칭 오브젝트를 위해 사용될 수 있는 관찰자에 정렬된 쿼드 또는 투명 텍스처를 사용하는 연기 시뮬레이션이다. 다른 예는 궤적을 보여주는 화살일 수 있다.
 
Geometry 노드를 매우 간단한 수 천개의 이러한 단순 개체 각각을 위해 생성하는 것은 많은 오버헤드를 발생시킨다. 그것들을 모두 관철자 정렬로 바꾸는 것은 다중의 뷰가 씬 내에서 활성화되어 있다면 응용프로그램으로서는 불가능하다. 즉 씬그래프에서 배제해야 한다.

OpenSG 는 이러한 상황을 특정 Paticles 노드를 사용해 지원하는데, 이는 위치, 색상, 크기를 입력으로 취해 그것들을 매 프레임에 대해 여러 종류의 기하도형으로 변환한다.

 
8. 공유
 
8-1. 노드 기반
 
씬그래프는 씬을 렌더링하기 위한 모든 데이터를 소유할 필요가 있다. 그러나 많은 씬에는 다른 오브젝트의 복사본일 뿐인 오브젝트들이 존재한다. 단순한 예는 자동차의 휠이다. 같은 오브젝트에 대한 정확히 내 개의 복사본이 존재하며, 위치만 다를 뿐이다. 씬그래프를 위해 메모리를 효율적으로 사용하려면, 이들 오브젝트에 의해 사용되는 자료를 공유할 방법이 있어야만 한다.
 
이를 위한 한 방법은 다수의 부모에 대해 오브젝트 추가를 허용하는 것이다. 변환을 사용하여 서로 다른 복사본이 같은 데이터를 공유하면서 독립적으로 배치될 수 있도록 할 수 있다. 이것은 매우 간단한 기법이며, 이는 많은 씬그래프에서 사용된다.
 
그럼에도 불구하고 이것은 몇 가지 문제를 가지고 있다. 오브젝트가 포인터에 의해 더 이상 식별될 수가 없다. 모든 복사본이 같은 오브젝트이기 때문에, 포인터는 복사본의 의미를 알지 못한다. 결국 그래프를 따라 올라갈 때, 예를 들어 오브젝트의 전역 위치를 획득하기 위해 순회 과정 상의 변환을 누적하고자 할 때, 어떠한 방식으로 해야할지 알 수가 없다.
 
또 다른 문제는 이름과 같은 인스턴스 지정 데이터를 연결할 수가 없다는 것이다. 다시 말하는데 이 복사본은 모두 같은 오브젝트이며, 차이가 존재하지 않는다.
 
이것이 OpenSG 가 Node/Core 분할 정책을 사용하는 주요 이유이다. Node 는 단일하며, 그것들은 공유될 수 없다. 모든 Node 는 단지 단일 부모 포인터만을 가진다. Core 는 분할될 수 있으며, 그것들은 다수의 사용자를 가진다(fig. 7 참조).

 
Node 는 매우 작기 때문에 그것들을 복사하는데 있어서 발생하는 메모리 패널티는 문제가 안 된다. Cores 에 포함된 주요 데이터들은 공유될 수 있다. Graph 구조를 노드 내용으로부터 분할하는 것은 공유 제어를 허용하기도 한다. 예를 들어 Switch Core 를 공유하는 것은 단일 Core 상의 값을 설정하는 것을 허용해 씬 내의 여러 Node에 영향을 미칠 수 있다. 같은 원리가 LOD, Transformation, 다른 종류의 Core 에도 적용된다.
 
8-2. 기하도형
 
씬그래프 데이터의 대부분은 기하도형에 포함된다. 완전한 기하도형을 공유하는 것은 위에서 언급했던 노드 기반 공유와 함께 가능하다. 그러나 예를 들어 shaded 모델의 최상위에서 와이어프레임을 그린다거나 다른 색상으로 오브젝트의 일부를 그려서 강조한다거나 할 때 기하도형의 일부만을 공유하는 것이 좋은 상황이 존재한다.
 
어쨌든 기하도형의 데이터는 다른 속성으로 분할되었기 때문에, 개별 속성을 개별적으로 공유하기 위한 단계는 적다. 대부분의 씬그래프 시스템은 여러 가지 방식으로 그것을 허용한다. 왜냐하면 그 데이터는 응용프그램 혹은 OpenSG와 같은 것에 의해서 데이터를 자신만의 자료구조에 파생시키는 것에 의해 관리되기 때문이다.(원문 : As the data of the geometry is split into different properties anyway, it is a small step to sharing the separate properties separately. Most scene graph systems allow that in one way or another, either because the data is managed by the application anyway, or, like OpenSG, by splitting the data off into their own data structures.)
 
(역주 : 이 아래쪽은 중요하지도 않은 것 같고 뭔 소린지 이해가 안 되는 부분도 있고 해석하지 않습니다. 알아서들 보시길...)
 
9. Multi-Threading
 
Multi-threading is an aspect that is growing in importance, given the current trend in
processor designs to go to simultaneous multi-threading (SMT).
A number of scene graphs provide simple multi-threading support, which allows simultaneous
reading or rendering of the scene graph. For many applications this is
quite adequate, but for more demanding applications that use asynchronous simulation
threads needing consistent data and/or manipulate the graph it is not enough.
OpenSG supports these kinds of applications by allowing each structure to have multiple
aspects, i.e. multiple copies of itself. This is done efficiently by only copying the
bulk of the scene graph’s data, the geometry data, when it is needed.
Different aspects can be efficiently synchronized under application control, making
them contain the same data again. To support this in a general and easily extensible
way, OpenSG adds reflectivity to the system. Reflectivity is the ability of the system’s
structures to give out information about themselves, e.g. which fields they contain and
how to access those fields. This ability is used to automatically add synchronization
capabilities to each structure of the system.
It can also be used to write a generic OpenSG loader/writer that can automatically
handle new structures and extensions in the system without having to write any specific
code for it. An extension of this system also allows synchronizing scene graphs across
a cluster of machines. Again, no cluster-specific code needs to be written, the data is
automatically distributed and synchronized.
The difference between this kind of clustering and the kind of clustering the already
introduced systems clusterJuggler and netJuggler lies in the point on the pipeline the
distribution is done. Both netJuggler as well as clusterJuggler distribute the inputs to
all nodes. This approach minimized the amount of data to be sent over the network,
but the full application is running on all nodes and needs to process the input. If that
input processing takes a lot of calculation or depends on large external data this can
be a problem. OpenSG distribution on the other hand distributes after the inputs have
been processed but before OpenGL commands are generated.
This section can only give an idea of what’s done in OpenSG for multi-threading, see
[3] for more information.
 


10 Getting to know OpenSG

OpenSG is one example of the current breed of modern scene graphs. It is developed and distributed under the Open Source principle and is available including source code from www.opensg.org.

It is designed with multi-threading (see sec. 9 for details) and application extensibility in mind, i.e. changes to internal data structures are possible without having to change the library’s source code (and thus without having to reapply changes whenever the library changes).

The development is supported by a number of companies and research institutes (see www.opensg.org/forum for details), guaranteeing sustained development. Further development is also sponsored by the German Government by a research project called OpenSG PLUS (see www.opensg.org/OpenSGPLUS) which funds continuous development of the core as well as a lot of high-level functionality (NURBS rendering, subdivision surfaces, Clustering, Occlusion Culling, Volume Rendering, High-Level Shading to name but a few).

It is developed on Linux, Irix andWindows, with a MacOS X port pretty much working and an HP port in the works. It is hosted on SourceForge (www.sf.net) and uses the SourceForge infrastructure to build a developer community, mainly based on mailing lists and IRC.

The 1.0 version was released in October 2001, the 1.1 developer version will be released in April 2002. But an automatic dailybuild system makes sure that the current CVS always compiles on every platform and allows access to daily snapshots if needed.

Some automated documentation is created from the source code using the doxygen tool, but more useful as an introduction is the Starter Guide (www.opensg.org/starter) and the tutorial examples (available in the tutorials/ directory in the source and distributions).

11. When does it make sense to use a scene graph?
 
This part of the course talked about scene graphs and what they can do for a graphics
application. Of course they cannot solve all the problems, and they are not always the
best solution to every problem.
Their main strength and their main weakness is that they are a retained mode structure.
Having access to all the data making up the scene allows them to optimize the rendering
by only rendering visible objects and sorting them by state to make effective use of the
graphics hardware.
The weakness is that the data structure needs to be consistent with the application’s
data. If that data is very dynamic, especially if the node structure changes for every
frame, keeping the scene graph up-to-date can eat up the profit that it brings. If only the contents of the objects change it’s not as bad, especially if the maximum size of the
dynamic areas is known beforehand, but there is still some overhead involved.
Scene graphs really shine in complex scenes, complex in the sense that they consist of
a large environment that uses many different materials. For situations where there is
a small number of objects, all using the same rendering parameters, and all visible all
the time, a simple application obeying some basic rules (only change state if it is really
different, use vertex arrays with native data types) can reach a very good performance.
Note however that even these applications can get a taste of complexity quickly, as
soon as interaction gets involved and different kinds of markers, information displays
and higher level rendering features are needed, in which case a scene graph becomes a
more viable solution.

Besides being highly efficient rendering engines, scene graphs also tend to accumulate
useful utility functions for handling scene data. The most prominent examples are
loaders for models and images. Writing loaders is a job that nobody likes to do, so
being able to use somebody else’s work can already make using a scene graph worth
it. Similar reasoning applies to the intersection test (see sec. 4.1.2).

A special case is the clustering support given by OpenSG, as it simplifies bringing
an application to a cluster significantly, something which is becoming more and more
important and can turn into a lot of work quickly.

When faced with an already fully developed application that displays a single object
always centered on the screen, switching to a scene graph will only make sense in very
few situations. However, when starting a new project it can never hurt to start using
a scene graph. If the application turns out to be too simple for a scene graph going
back won’t be a big problem. But the amount of useful functionality that a scene graph
provides, especially in it’s domain of loading, processing and rendering scenes, can
become addictive pretty quickly. Try it, you might enjoy it!

References

[1] Mason Woo et.al. OpenGL(R) Programming Guide: The Official Guide to Learning
OpenGL, Version 1.2. Addison-Wesley Pub Co, 1999.

[2] James D. Foley, Andries van Dam, Steven K. Feiner, and John F. Hughes. Computer
Graphics, Principles and Practice, Second Edition. Addison-Wesley, Reading,
Massachusetts, 1990. Overview of research to date.

[3] Dirk Reiners, Gerrit Voss, and Johannes Behr. OpenSG Basic Concepts. In
OpenSG 2002 Symposium, Darmstadt, 01 2002.

[4] John Rohlf and James Helman. Iris performer: A high performance multiprocessing
toolkit for real-time 3d graphics. Proceedings of SIGGRAPH 94, pages
381–395, July 1994. ISBN 0-89791-667-0. Held in Orlando, Florida.


[5] Paul S. Strauss and Rikk Carey. An object-oriented 3D graphics toolkit. In Edwin
E. Catmull, editor, Computer Graphics (SIGGRAPH ’92 Proceedings), volume
26, pages 341–349, July 1992.

'Or.......... > Work' 카테고리의 다른 글

Scalform - GFx [Prologue]  (1) 2010.08.09
Overview of the Major Structural Changes in Direct3D 10  (0) 2009.08.27
Scene Graph Rendering  (0) 2009.08.27
kd-tree Introduction  (0) 2009.08.27
Grass Rendering  (0) 2009.08.27
Water Rendering  (0) 2009.08.27

MINI & Strida

from Or........../MINI 2009.08.27 15:01

'Or.......... > MINI' 카테고리의 다른 글

A MINI Addiction  (0) 2012.05.08
MINI`s History  (0) 2009.09.29
MINI & Strida  (0) 2009.08.27
MINI - Lamp Replacement Guide  (0) 2009.08.27
Stoptech MINI  (0) 2009.08.27
2005 MINI Cooper S (With HID (high intensity discharge) headlamps)

Low beam headlamp
HID-D2S

High beam headlamp
H7
H7SU Silverstar ULTRA for Ultra Night Vision - The Whitest and Brightest Halogen
H7ST Silverstar High Performance Lighting: The Whiter and Brighter Halogen
H7XV XtraVision Halogen - The Brighter Light
H7CB Cool Blue Halogen - The Whiter Light

Parking light
2825LL

Front turn signal
7507
7507AST Silverstar Signal Lighting: Complete the Look: Crisp, Clean, Style
7507LL Long Life Upgrade: Up to twice the life of the standard lamp

Rear turn signal
7506
7506LL Long Life Upgrade: Up to twice the life of the standard lamp

Tail light
7528
7528LL Long Life Upgrade: Up to twice the life of the standard lamp

Stop light
7528
7528LL Long Life Upgrade: Up to twice the life of the standard lamp

High mount stop light
Assembly

Fog/Driving light
H11-55W

License plate
6418
6418LL Long Life Upgrade: Up to twice the life of the standard lamp

Back up light
921
921LL Long Life Upgrade: Up to twice the life of the standard lamp

Front sidemarker
2825LL

Map light
2886X

Dome light
6418
6418LL Long Life Upgrade: Up to twice the life of the standard lamp

Step/Courtesy light
2825
2825LL Long Life Upgrade: Up to twice the life of the standard lamp

'Or.......... > MINI' 카테고리의 다른 글

A MINI Addiction  (0) 2012.05.08
MINI`s History  (0) 2009.09.29
MINI & Strida  (0) 2009.08.27
MINI - Lamp Replacement Guide  (0) 2009.08.27
Stoptech MINI  (0) 2009.08.27

Stoptech MINI

from Or........../MINI 2009.08.27 14:58
Stoptech Big Brake kits have one of the best reputation in the brake industry. Their kit for the MINI Cooper is no exception. It performs incredibly well under stress, helps reduce brake fade and flat out looks awesome.
This complete solution has been custom designed by StopTech for the Mini. Custom Hats and Brackets. Custom-matched caliper pistons. Your brake feel will be correct and linear (not like some kits that DO NOT match your car's braking system!). The StopTech caliper has a Patented bridge.
The two-piece StopTech rotor is slotted and designed with a new Patent Pending ventilation vane design that is simply superior. When your OEM brakes reach 900 degrees they are basically wasted (this WILL happen during high-performance driving or autocross events). All StopTech parts are easily replaced. The brake pads are a standard and extremely popular Porsche size.

Kit Includes:
2-Stoptech 4 Piston ST-40 Calipers (red or Black) with StopTech caliper bridge (Patent Pending).
1-Complete set of performance front brake pads
1-pair: 2 piece floating directional StopTech 328x28 (13"!!) Slotted rotors with exclusive Patent Pending vane cooling design. Available Slotted, Cross Drilled OR Solid.
1- set of front Stainless steel brake lines
1- set Caliper mounting brackets

This kit will NOT fit under the stock 16" or 17"MINI wheels. There are a few aftermarket 17" wheels that fit. The most popular is the Team Dynamics Pro Race 1 wheel in a 45mm offset which is in our wheel section. Please confirm wheel fitment before ordering as this kit cannot be returned once it ships.

Our sources say these 17" wheels will fit over the Stoptech MINI Cooper Big Brake Kit:

OZ Ultraleggeras 17x7 et37 - 3mm spacer needed (minimusprime 5mm spacer)
OZ Superleggera 17"x7" ---- +37mm offset -- 5mm spacer
BBS RV-F 17"x7.5" -- +42mm offset -- no spacer
SSR GT7 17"x7.5" -- +42mm offset -- no spacer
SSR Comp 17"x7.5" -- +42mm offset -- 3mm spacer
Team Dynamics Pro Race 1 17"x7" --- +45mm offset -- no spacer
SSR GT7s 18 x 7.5" +42mm offset - no spacers
SSR type C RS 17x7.5 et42 8mm spacer (to clear strut+brakes)

See template for more info:

http://www.stoptech.com/tech_info/charts/98-138-2430-00.pdf

and fitment directions:
http://www.stoptech.com/tech_info/wheel_fitment.shtml


Fits these MINI models:

http://www.outmotoring.com/mini-cooper/stoptech_mini_cooper_big_brake_kit.html 

'Or.......... > MINI' 카테고리의 다른 글

A MINI Addiction  (0) 2012.05.08
MINI`s History  (0) 2009.09.29
MINI & Strida  (0) 2009.08.27
MINI - Lamp Replacement Guide  (0) 2009.08.27
Stoptech MINI  (0) 2009.08.27

티스토리 툴바