Портал Готика Готика II Готика 3 Аркания Модификации Файлы Форумы РПГ Альманах Дух Готики

 

Results 1 to 12 of 12
  1. Visit Homepage View Forum Posts #1 Reply With Quote
    Knight Commander odin68's Avatar
    Join Date
    Aug 2008
    Posts
    2,729
     
    odin68 is offline

    [PB] Курт Пельцер - программирование / Kurt Pelzer


    Имя
    Курт Пельцер

    Работа в Пиранья Байтс?
    Программирование (Смежные области: движок, игра, скрипт, редактор )

    Возраст
    больше 3250ти лет (во времена Рамзеса II уже был матиматиком и астрологом )

    Образование
    Учеба в Graf Zahl (математика / информатика )

    Кем работал раньше?
    много разного, в особенности, участие в разных проектах в качестве разработчика программного обеспечения

    В каких игровых проектах участвовал?
    в Готиках 1-3 для Пиранья Байтс

    Любимая музыка?
    J.J. Cale и похожие "Причуды из сарая"

    Любимая игра?
    (глубоко вздохнув ) ... Beyond Good & Evil, Mafia, Beneath a Steel Sky, Okami (PS2), LocoRoco (PSP), Rayman, ...

    В чем ты особенно силен?
    Хммм - могу очень громко щелкать языком

    Что ты терпеть не можешь?
    комаров

    Чем ты увлекаешься, какие у тебя хобби?
    Определенно - лениться!

    Что бы ты хотел увидеть однажды в игре?
    Что-нибудь настолько новое, что по настоящему меня удивит

    Боишься ли ты, что когда-нибудь твои идеи для игры могут иссякнуть?
    Нет!

    ИСТОЧНИК

    [Bild: odin_md_akcr.jpg]
    ASUS LGA-1150 Z97-K, Intel Core i7-4770 3.4 GHz, EVGA GTX 980 Ti Hybrid ( 6.0 Gb), 16Gb DDR3, SSD OSZ Vertex 460A (240 Gb) + SSD Samsung SM951 M.2 (256 Gb), Dell Ultrasharp U2515H (2560 x 1440) + BenQ E2400HD (1920x1080)

  2. Visit Homepage View Forum Posts #2 Reply With Quote
    Knight Commander odin68's Avatar
    Join Date
    Aug 2008
    Posts
    2,729
     
    odin68 is offline

    [Bild: odin_md_akcr.jpg]
    ASUS LGA-1150 Z97-K, Intel Core i7-4770 3.4 GHz, EVGA GTX 980 Ti Hybrid ( 6.0 Gb), 16Gb DDR3, SSD OSZ Vertex 460A (240 Gb) + SSD Samsung SM951 M.2 (256 Gb), Dell Ultrasharp U2515H (2560 x 1440) + BenQ E2400HD (1920x1080)
    Last edited by odin68; 22.12.2017 at 12:03.

  3. Visit Homepage View Forum Posts #3 Reply With Quote
    Knight Commander odin68's Avatar
    Join Date
    Aug 2008
    Posts
    2,729
     
    odin68 is offline

    [Bild: odin_md_akcr.jpg]
    ASUS LGA-1150 Z97-K, Intel Core i7-4770 3.4 GHz, EVGA GTX 980 Ti Hybrid ( 6.0 Gb), 16Gb DDR3, SSD OSZ Vertex 460A (240 Gb) + SSD Samsung SM951 M.2 (256 Gb), Dell Ultrasharp U2515H (2560 x 1440) + BenQ E2400HD (1920x1080)

  4. Visit Homepage View Forum Posts #4 Reply With Quote
    Knight Commander odin68's Avatar
    Join Date
    Aug 2008
    Posts
    2,729
     
    odin68 is offline
    PC Games Hardware 06/2004

    Интервью с разработчиками G3 Карстеном Эденфельдом (Carsten Edenfeld), Оливером Хёллером (Oliver Höller) и Куртом Пельцером (Kurt Pelzer) игровому журналу «PC Games Hardware»


    24.05.2004

    Опубликовано в июньском номере журнала «PC Games Hardware».
    Немецкий вариант - http://gothic2network.ngz-network.de...cghardware.php

    Текст на английском:
    Spoiler:(zum lesen bitte Text markieren)
    The german Magazin PC Games Hardware published an interview with Carsten Edenfeld, Oliver Höller and Kurt Pelzer from Piranha Bytes in the edition of 06/2004. With friendly permission of the PC Games' hardware editorial staff we are allowed to publish a large part (75 %) of the interview. Questions concerning the 64-bit technology and SSE/SSE2 whose answers didn't reveal something relevant for the Gothic series have been left out.
    PCGH:
    The Gothic-engine was - as far as we know - a complete proprietary development. Are there any plans to open up this engine and to use a foreign physics-engine in future?
    Carsten:
    That's right. The engine used in Gothic 1/2/Add-on is a complete proprietary development and remittance work respectively. Only a few, smaller additional modules like the Miles-Sound-System have been licensed. The technology used for Gothic 3 has little relation to the previous one indeed. The new engine is a mixture of various licensed modules and SDK's as well as self developed software. To generate an own physics engine that exceeds basic features would be too extensive.
    PCGH:
    The promising Emotions-Engine "EMotion FX" is to be applied in Gothic 3 ...
    Oliver:
    Yes, we licensed this system in order to be able to realize the animations for Gothic 3 which are complex compared with those from Gothic 1/2/Add-on.
    PCGH:
    How far and how resource devouring is this technique?
    Oliver:
    This system provides all modern features you could expect of an external animation system. Two of these features are for example Hardware-Skinning and Normalmap-Support. Generally the resource requirements depend on the size of the animation data. However, we don't expect heavy burdens in reference to performance and resources.
    PCGH:
    How much of the CPU-performance was needed for the artificial intelligence (AI) in Gothic1/2/Add-on?
    Carsten:
    Of course, Gothic is a very AI-intensive game. Just consider the complex social systems as well as the natural behavior of all the individual NPC's. Nevertheless, the CPU-performance which is required for the AI is not that problematic. As the AI system used by us shows an adequate performance eventual bottlenecks could rather be found in other areas of the game.
    PCGH:
    ...in which ones?
    Carsten:
    The methods used in the basis-renderer are out of date for the high number of polygons and the concentration of objects applied nowadays and they limitate the achieveable performance. Dynamic vertex buffers for example are produced in each frame in order to render the polygons sorted for materials.
    PCGH:
    The Gothic-Engine won't benefit from Hyper-Threading...
    Oliver:
    Gothic 3 will certainly benefit from Hyper-Threading because especially the new engine and the new rendering technology will make use of Multi-Threading.
    PCGH:
    Are you cooperating with AMD or Intel?
    Kurt:
    We have been in contact with Intel for some time now but concrete collaboration hasn't started yet. It's likely that close cooperation will begin in the course of the actual development (Gothic 3) but it still stays open to which extent this will happen.
    PCGH:
    Which DirectX-version is the basis for programming?
    Kurt:
    As is generally known Gothic 1/2/Add-on build up on DirectX 7.0. There will be a big jump to the version 9.0b which is currently the basis for our development. Soon the change to version 9.0c will be applied. If there is another update until the release of Gothic 3 we may consider it as well.
    PCGH:
    Will pixel shaders be applied? If yes, in which version?
    Kurt:
    We will use pixel shaders to a large extent in Gothic 3. Depending on the display quality choosen and the hardware available this will be versions 1.1 to 1.4, 2.0 and 3.0. The main field of application for pixel shaders are complex lighting calculations as well as image-postprocessing for subsequent modifications of the visible scenes (e.g.: Glow, Blur, Fog and similar effects).
    PCGH:
    Will you make use of the shader-profile 2.A for FX-cards?
    Kurt:
    At the moment we don't use shaders of version 2.x. If it's worthwhile to support this spezial profile like version 1.4 separately that remains to be seen.
    PCGH:
    Which fallback-modes for lower DirectX-Technology levels are there?
    Kurt:
    Depending on the hardware available and the desired display quality different technology levels will be activated. The lowest fallback-mode will require DirectX-8.0 features, for example Vertex Shader of version 1.1 per Hardware-Processing. So we will support all CPU generations down to the Geforce3-/Radeon-8500-class.
    PCGH:
    Which cooperation is there actually with Nvidia- or Ati-technicians?
    Kurt:
    We are in close contact with both companies. This includes especially support by e-mail and telephone as well as on-site visits.


    Перевод с немецкого: Madrigal
    Редактура: Madrigal, akmych


    PCGH: С тех пор, как AMD анонсировала Athlon 64, - этот процессор у всех на устах. Ровно, как и неоптимизированное программное обеспечение к нему. Будет ли Gothic3 поддерживать 64-битный процессор?

    Oliver Höller:
    Мы, на самом деле, еще не настолько далеко продвинулись в разработке, чтобы смело отвечать на подобного рода вопросы... И, полагаю, что ответить сможем только, когда проект вступит в стадию бета-тестинга.

    PCGH: Всем известно, что Gothic-движок - это плод собственной разработки Piranha Bytes. Есть ли планы лицензировать что-либо на стороне? Скажем, внедрить в игру физический движок от Havok?

    Carsten Edenfeld: Все верно. Готика, Готика 2, а также ее аддон полностью базируются на нашем собственном графическом ядре. Дополнительно мы лицензировали лишь Miles - систему объемного звучания. В третьей части все будет иначе. В графическом плане это будет смесь отдельных лицензированный модулей и SDK с нашей новой продвинутой технологией. Что касается полностью купленного и лицензированного физического движка, то для нас в данный момент это слишком дорого.

    PCGH: В Готике 3 будет использована технология EMotion FX…

    Oliver Höller: Ага, мы ее лицензировали, чтобы обеспечить персонажам более качественную лицевую анимацию, по сравнению с предыдущими частями.

    PCGH: А ты можешь рассказать поподробнее? Самое главное - насколько эта штука требовательна к ресурсам?

    Oliver Höller: Технология располагает всеми возможностями, которые можно ожидать от современной анимационной системы, включая Hardware-Skinning и Normalmap-Support. Количество пожираемых ресурсов при этом напрямую зависит от объема использованной анимации. Тем ни менее, мы не думаем, что использование EMotion FX приведет к излишне высокой нагрузки на процессор.

    PCGH: Какая версия DirectX взята за основу?

    Kurt Pelzer: Как известно, первые две части и аддон базировались на DirectX 7-движке. Готика 3 совершит впечатляющий прыжок с седьмой версии сразу на 9b. Пока это основа нашего программирования. Возможно, вскоре приоритетом станет 9с. Если до релиза нашей игры свет увидит новая версия DirectX, мы, в любом случае, это учтем.

    PCGH: Будут ли в Gothic3 использоваться пиксельные шейдеры. Если да, то какой версии?

    Kurt Pelzer: Шейдеры будут использоваться, причем в очень большом объеме. В зависимости от выбора качества изображения и наличия приемлемой видеокарты, можно будет лицезреть шейдеры версии 1.1, 1.4, 2.0 и даже 3.0 (версию 3.0 поддерживает пока лишь линейка GeForce 6800). Основные функции шейдеров - это, конечно, более сложный расчет освещения, а также пост-расчет эффектов (Glow, Blur, объемный туман и т.д.)

    PCGH: Какое уменьшение качества графики будет использоваться для слабых и старых видеокарт?

    Kurt Pelzer: В зависимости от выбранного качества изображения и от железа, установленного на вашем компьютере - будет определен адекватный технологический уровень графики. Минимальный уровень – это качество 8-ого DirectX, например, шейдеры версии 1.1. Исходя из этого, наша игра будет поддерживать все чипсеты, начиная с последнего поколения и заканчивая GeForce3 (кроме GF4 MX) и Radeon 8500 включительно.

    [Bild: odin_md_akcr.jpg]
    ASUS LGA-1150 Z97-K, Intel Core i7-4770 3.4 GHz, EVGA GTX 980 Ti Hybrid ( 6.0 Gb), 16Gb DDR3, SSD OSZ Vertex 460A (240 Gb) + SSD Samsung SM951 M.2 (256 Gb), Dell Ultrasharp U2515H (2560 x 1440) + BenQ E2400HD (1920x1080)

  5. Visit Homepage View Forum Posts #5 Reply With Quote
    Knight Commander odin68's Avatar
    Join Date
    Aug 2008
    Posts
    2,729
     
    odin68 is offline
    Курт Пельтцер / Kurt Pelzer
    Unternehmer / Senior Software Engineer
    Kurt Pelzer | IT-Consulting & Software-Development Bochum, Германия
    Предприниматель

    Senior Programmer
    Codecult Research & Development GmbH

    по сегодняшний день
    Senior Software Engineer / Contractor
    Piranha Bytes
    Отрасли: Компьютерные игры
    Тип занятости: Партнер

    по сегодняшний день
    Unternehmer / Senior Software Engineer
    Kurt Pelzer | IT-Consulting & Software-Development
    Отрасли: Программное обеспечение
    Тип занятости: Владелец

    Kurt Pelzer turned his passion for software development and visual arts into his occupation - acting as a Software Engineer in the 3D Real-Time Simulation & Game Industry. Kurt works with Piranha Bytes and some other contracting partners in Germany. He has been involved in all stages of development from conceptual and technical design to implementation debugging and testing. Over the past decade Kurt has been credited on successfully released and awarded software projects esp.: Gothic Gothic II + AddOn: The Night of the Raven Gothic 3 Risen Risen 2: Dark Waters. Kurt also helped to start up the new company Nevigo and their development tools & middleware. And in the early 2K years he developed at Codecult Software the well-known Codecreatures Benchmark and an exclusive third-party demo for NVIDIA (used for GeForce 4 Ti launch). In addition to his work as a developer Kurt is an author of technology articles published in the leading software book series for game developers: GPU Gems Game Programming Gems and ShaderX. Kurt’s talent is his most valuable asset. The strong sense of improvement and innovation is his driving force always looking to the future and the opportunities ahead.

    [Bild: odin_md_akcr.jpg]
    ASUS LGA-1150 Z97-K, Intel Core i7-4770 3.4 GHz, EVGA GTX 980 Ti Hybrid ( 6.0 Gb), 16Gb DDR3, SSD OSZ Vertex 460A (240 Gb) + SSD Samsung SM951 M.2 (256 Gb), Dell Ultrasharp U2515H (2560 x 1440) + BenQ E2400HD (1920x1080)
    Last edited by odin68; 25.01.2019 at 01:26.

  6. Visit Homepage View Forum Posts #6 Reply With Quote
    Knight Commander odin68's Avatar
    Join Date
    Aug 2008
    Posts
    2,729
     
    odin68 is offline
    PC Action 11/2001

    "Codecult" (подразделение "Phenomedia") о движке Codecreatures, Piranha Bytes и Готике 2

    [Bild: codecult.jpg]

    Стефан Хергет, Marco Spörl, ?, Томас Фон Трейхель, Деннис Люссбринк, Курт Пельцер, Оливер Хёллер, ?, ?, Роман Кескенти, Стефан Хайнеманн

    [Bild: odin_md_akcr.jpg]
    ASUS LGA-1150 Z97-K, Intel Core i7-4770 3.4 GHz, EVGA GTX 980 Ti Hybrid ( 6.0 Gb), 16Gb DDR3, SSD OSZ Vertex 460A (240 Gb) + SSD Samsung SM951 M.2 (256 Gb), Dell Ultrasharp U2515H (2560 x 1440) + BenQ E2400HD (1920x1080)
    Last edited by odin68; 04.04.2020 at 20:01.

  7. Visit Homepage View Forum Posts #7 Reply With Quote
    Knight Commander odin68's Avatar
    Join Date
    Aug 2008
    Posts
    2,729
     
    odin68 is offline
    mobygames.com

    Game Credits

    Programming/Engineering
    Elex (2017) (Programming)
    Risen 3: Titan Lords (2014) (Programming)
    Risen 2: Dark Waters (2012) (Programming)
    Risen (2009) (Programming)
    Gothic 3 (2006) (Programming)
    Gothic II: Gold Edition (2004) (Programming - Additional Engine Programming)
    Gothic II: Night of the Raven (2003) (Additional Engine Programming)
    Gothic II (2002) (Additional Engine Programming)
    Gothic (2001) (Additional Programming)


    Game Credits (By Year)

    Elex (2017), THQ Nordic GmbH
    Risen 3: Titan Lords (2014), Deep Silver
    Risen 2: Dark Waters (2012), Deep Silver
    Risen (2009), Deep Silver
    Gothic 3 (2006), Deep Silver, JoWooD Productions Software AG
    Gothic II: Gold Edition (2004), JoWooD Productions Software AG
    Gothic II: Night of the Raven (2003), JoWooD Productions Software AG
    Gothic II (2002), JoWooD Productions Software AG
    Gothic (2001), Shoebox


    Developer Biography

    Kurt Pelzer is a Software Engineer & Architect with more than a decade of experience in professional software development for the 3D real-time simulation & game industry. He works with Piranha Bytes and some other customers in Germany. He has been involved in all stages of development from conceptual and technical design, to implementation, debugging and testing. Before stepping into the world of professional simulation & game development, Kurt has studied mathematics & computer science.
    Last updated: Nov 28, 2009
    Contributed by Kurt Pelzer (1) on Nov 28, 2009.

    ИСТОЧНИК

    [Bild: odin_md_akcr.jpg]
    ASUS LGA-1150 Z97-K, Intel Core i7-4770 3.4 GHz, EVGA GTX 980 Ti Hybrid ( 6.0 Gb), 16Gb DDR3, SSD OSZ Vertex 460A (240 Gb) + SSD Samsung SM951 M.2 (256 Gb), Dell Ultrasharp U2515H (2560 x 1440) + BenQ E2400HD (1920x1080)

  8. Visit Homepage View Forum Posts #8 Reply With Quote
    Knight Commander odin68's Avatar
    Join Date
    Aug 2008
    Posts
    2,729
     
    odin68 is offline
    ShaderX2: Shader Programming Tips and Tricks With Directx 9.0

    08/2003

    Section 2 – Rendering Techniques
    стр 207-225

    “Advanced Water Effects”
    by Kurt Pelzer


    [Bild: 01w.jpg]



    "Advanced Water Effects"
    by Kurt Pelzer
    Курт обновил свой пример программы. СКАЧАТЬ обновление (58 кб).


    Section 2 – Rendering Techniques
    стр 240-250

    “Advanced Sky Dome Rendering”
    by Marco Spoerl and Kurt Pelzer


    [Bild: 001.jpg]




    [Bild: epdf.jpg]


    СКАЧАТЬ всю книгу можно ТУТ (15 Мб)

    [Bild: odin_md_akcr.jpg]
    ASUS LGA-1150 Z97-K, Intel Core i7-4770 3.4 GHz, EVGA GTX 980 Ti Hybrid ( 6.0 Gb), 16Gb DDR3, SSD OSZ Vertex 460A (240 Gb) + SSD Samsung SM951 M.2 (256 Gb), Dell Ultrasharp U2515H (2560 x 1440) + BenQ E2400HD (1920x1080)

  9. Visit Homepage View Forum Posts #9 Reply With Quote
    Knight Commander odin68's Avatar
    Join Date
    Aug 2008
    Posts
    2,729
     
    odin68 is offline
    https://developer.nvidia.com 2005

    GPU Gems 2

    [Bild: Cover_150.jpg]

    GPU Gems 2 is now available, right here, online. You can purchase a beautifully printed version of this book, and others in the series, at a 30% discount courtesy of InformIT and Addison-Wesley.

    The CD content, including demos and content, is available on the web and for download.

    Курт Пельцер, Пиранья Байтс

    Курт Пельцер - старший инженер-программист в Piranha Bytes, где он работал над компьютерной игрой Gothic, самой продаваемой Gothic II (удостоенной RPG года в Германии в 2001 и 2002 годах соответственно) и надстройкой Gothic II: Ночь ворона. Ранее он был старшим программистом в Codecult и разработал несколько симуляций в реальном времени и демонстрацию технологий, построенных на 3D-движке Codecult. Курт публиковал статьи в GPU Gems, ShaderX2 и Game Programming Gems 4.

    =========================================

    Chapter 5. Optimizing Resource Management with Multistreaming

    Oliver Hoeller
    Piranha Bytes

    Kurt Pelzer
    Piranha Bytes

    One of the most difficult problems in modern real-time graphics applications is the massive amount of data that must be managed. Complex scenes with complex meshes combined with multiple render passes—as are needed for high-quality shadows and additional reflection and refraction effects, for example—are expensive to render. Finding ways to feed the GPU with optimally formatted data is crucial for successfully rendering complex scenes.

    This chapter addresses this issue and focuses on a flexible model to resolve the problem of handling the gamut of graphics hardware found in current PCs. A PC game must be able to run and run well on the latest high-end GPU all the way down to last year's "value" GPU—and on everything in between. We introduce a solution that handles the massive amount of data and is careful to transmit only the currently needed vertex components for each pass. This system, which has been implemented in the Gothic III engine, combines two powerful techniques: several vertex buffers are combined via multistreaming (a feature introduced with Microsoft DirectX 8.0), and each vertex buffer is controlled by an optimized resource manager. We present both the abstract concept as well as its implementation based on DirectX 9.0c.

    5.1 Overview

    Each vertex in a mesh has multiple components associated with it (position, normal, tangent, texture coordinates, and so on), but all of these entities aren't always necessary when rendering the object. We want an automated system that uses only the currently needed vertex components. To handle the task, we use vertex buffer streams specialized for certain subtasks. Depending on the current rendering pass, subsets of these streams are combined to assemble the vertices.

    We need four basic types of streams, as shown in Figure 5-1. Here are the streams and their subtasks:

    G—Vertex stream for geometry data. Contains vertex position, normal, and vertex color(s).
    T—Vertex stream for texture-mapping data. Holds texture coordinate sets and additional information such as tangent vectors for tangent-space normal maps.
    A—Vertex stream for animation data. Holds animation data such as bone weights and influences.
    I—Vertex stream for instancing data. Contains data for vertex stream frequency instancing.

    [Bild: 05_multistreaming_1.jpg]
    Figure 5-1 Four Types of Vertex Streams

    Subsets of these four streams combine to handle different tasks, as shown in Figure 5-2:

    Render meshes without animation

    Possible stream combinations: G or G + T

    Render meshes with animation

    Possible stream combinations: G + A or G + T + A

    Render instanced meshes (optionally with animation)

    Possible stream combinations: G + I or G + T + I

    (Optional: G + A + I or G + T + A + I)

    Render pure z-pass (optionally with or without instancing, with or without animation)

    Possible stream combinations: G

    (Optional: G + A or G + I or G + A + I)

    [Bild: 05_multistreaming_2.jpg]
    Figure 5-2 Combining Currently Needed Streams

    The next section presents an implementation of this model.

    5.2 Implementation

    Now we show how to implement the abstract concept discussed in Section 5.1. First we examine some multistreaming example code based on DirectX 9.0c. Next we present the resource manager that handles the mesh resources. Finally, we show how to translate generic mesh data into the appropriate hardware structure.

    5.2.1 Multistreaming with DirectX 9.0

    Microsoft DirectX 8.0 introduced the notion of a stream to bind data to input registers. A stream is a uniform array of component data. Each component consists of one or more elements that represent a single entity, such as position, normal, color, texture coordinate set, and so on. With streams, GPUs are able to perform a direct memory access (DMA) from multiple vertex buffers in parallel. The Direct3D caps bit D3DCAPS9.MaxStreams defines how many streams a GPU supports; modern hardware supports up to 16 streams, while older, DirectX 8.0-compliant GPUs are limited to 8 streams. Because multistreaming has some minor performance implications, it's advisable to minimize the number of active streams. Because our implementation uses only 1 to 4 streams, all GPUs with multistreaming support can be targeted, with minimal loss of performance.

    Listing 5-1 shows our multistreaming example code. Using DirectX 9.0 for this task, we need only three simple components:

    - A correct vertex declaration (an array of D3DVERTEXELEMENT9) and the IDirect3DDevice9::CreateVertexDeclaration() method to create a vertex declaration object.
    - The IDirect3DDevice9::SetVertexDeclaration() method to set the vertex declaration object.
    - The IDirect3DDevice9::SetStreamSource() method to bind a vertex buffer to a device data stream, creating an association between the vertex data and one of several data stream ports that feed the primitive processing functions.

    Example 5-1. A Set of Vertex Definitions and a Vertex Declaration

    Code:
     //  // Initializations:  //  // Here is a set of vertex definitions to support two streams.  // Vertex format:  //     stream 0 -> position + normal + color 0 + color 1  //     stream 1 -> 4 texture coordinate pairs    struct VTXSTREAM_0  {    float fPosX, fPosY, fPosZ;    float fNormX, fNormY, fNormZ;    DWORD dwColor0, dwColor1;  };    struct VTXSTREAM_1  {    float fTexU0, fTexV0;    float fTexU1, fTexV1;    float fTexU2, fTexV2;    float fTexU3, fTexV3;  };    // Vertex declaration  D3DVERTEXELEMENT9 m_VtxDcl[] =  {    {0, 0, D3DDECLTYPE_FLOAT3, D3DDECLMETHOD_DEFAULT,     D3DDECLUSAGE_POSITION, 0}, // stream 0, position    {0, 12, D3DDECLTYPE_FLOAT3, D3DDECLMETHOD_DEFAULT,     D3DDECLUSAGE_NORMAL, 0},   // stream 0, normal      {0, 24, D3DDECLTYPE_D3DCOLOR, D3DDECLMETHOD_DEFAULT,     D3DDECLUSAGE_COLOR, 0},    // stream 0, color 0    {0, 28, D3DDECLTYPE_D3DCOLOR, D3DDECLMETHOD_DEFAULT,     D3DDECLUSAGE_COLOR, 1},    // stream 0, color 1      {1, 0, D3DDECLUSAGE_FLOAT2, D3DDECLMETHOD_DEFAULT,     D3DDECLUSAGE_TEXCOORD, 0}, // stream 1, tex coord set 0    {1, 8, D3DDECLUSAGE_FLOAT2, D3DDECLMETHOD_DEFAULT,     D3DDECLUSAGE_TEXCOORD, 1}, // stream 1, tex coord set 1      {1, 16, D3DDECLUSAGE_FLOAT2, D3DDECLMETHOD_DEFAULT,     D3DDECLUSAGE_TEXCOORD, 2}, // stream 1, tex coord set 2    {1, 24, D3DDECLUSAGE_FLOAT2, D3DDECLMETHOD_DEFAULT,     D3DDECLUSAGE_TEXCOORD, 3}  // stream 1, tex coord set 3    }    // Create a vertex declaration object  LPDIRECT3DVERTEXDECLARATION9 m_pVtxDeclObject;  m_pd3dDevice->CreateVertexDeclaration(m_VtxDcl,&m_pVtxDclObj);
    In Listing 5-1, we present a set of vertex definitions and create a vertex declaration object m_pVtxDeclObject that describes the following vertex data layout:

    - Vertex position data are found in stream 0 with a 0-byte offset. The data type is three-component float that expands to (float, float, float, 1).
    - Vertex normal data are found in stream 0 with a 12-byte offset. The data type is three-component float that expands to (float, float, float, 1).
    - Diffuse and specular color are found in stream 0 with offsets of 24 bytes (diffuse) and 28 bytes (specular). The data type is four-component, packed, unsigned bytes mapped to a range of 0 to 1.
    - Texture coordinate data (sets 0 to 3) are found in stream 1 with offsets of 0 bytes (set 0), 8 bytes (set 1), 16 bytes (set 2), and 24 bytes (set 3). The data type is two-component float that expands to (float, float, 0, 1).

    Before calling a draw method, we must set this vertex declaration object together with the vertex buffers bound to the correct device data streams, as shown in Listing 5-2.

    Example 5-2. Binding Vertex Buffers to Streams

    Code:
    //  // Each time we want to render primitives:  //    // Set the vertex declaration object  m_pd3dDevice->SetVertexDeclaration(m_pVtxDclObj);    // Bind vertex buffers to device data streams  m_pd3dDevice->SetStreamSource(0, m_pVtxBuf0, 0, sizeof(VTXSTREAM_0));  m_pd3dDevice->SetStreamSource(1, m_pVtxBuf1, 0, sizeof(VTXSTREAM_1));      // Render ..  m_pd3dDevice->DrawIndexedPrimitive( .. );
    The actual references to the stream data do not occur until a drawing method, such as IDirect3DDevice9:rawIndexedPrimitive(), is called.

    5.2.2 Resource Management

    In the Gothic III engine, we employ the concept of resource management to handle the administration of all data-intensive elements, such as vertex data (mesh information), textures, animation data (key frames and skinning data), sounds, and music. All these data structures use a uniform framework. It provides a simple interface so that other systems of the engine can access it.

    All resources are packed into abstract data objects. We address these data objects by file name or by a globally unique identifier (GUID). The access of data containers is similarly organized like a database access. If you call a query, you get a referenceable data container with all necessary structures of the specified data.

    The resource management system ensures the immediate and simultaneous availability of the data. It is also responsible for converting this proprietary data into the graphics hardware's preferred format.

    As we mentioned, the resource management system makes it possible to store mesh data in specified file locations and to load these mesh objects only as needed. These structures must be stored in an efficient and flexible way, but vertex data layout can vary substantially from mesh to mesh.

    The loaded resources should provide a reference counter, so that the same mesh can be used repeatedly in a scene. Geometry instancing is used to speed up rendering this type of mesh. (See Chapter 3 of this book, "Inside Geometry Instancing.")

    The mesh information is generated by tools such as 3ds max or Maya. For this operation, a suitable importer has to be developed, as shown in Figure 5-3.

    [Bild: 05_multistre_3_new.jpg]
    Figure 5-3 Structure of the Resource Framework

    The Mesh Resource

    One of the database containers provided by the resource management system is a mesh resource, which has all relevant structures, all vertex and index data arrays, and a link to an abstract material object (which is also a referenceable resource).

    Note that the vertex structure wrapped into a resource class (as shown in Figure 5-3) isn't adapted to any specific graphics API (such as DirectX or OpenGL). We can therefore implement the whole resource system independent of the graphics API used.

    These structures consist of simple vertex streams (arrays) containing a single vertex component, such as position (an array of 3D vectors), normals (an array of 3D vectors), color (an array of DWORD values), or up to 16 texture coordinates (an array of 1D, 2D, 3D, or 4D vectors) and other customized data arrays such as weights for hardware skinning.

    To complete this groundwork, we have developed a hardware-independent resource framework with a mesh class and its administrative interface. Furthermore, we have written a specified importer for the corresponding modeling tool.

    5.2.3 Processing Vertices

    The renderer takes over the task of changing the hardware-independent data into a format that is optimal for the graphics hardware.

    First, the mesh resources are loaded into main memory at the start of the application. Alternatively, we use an on-demand approach to load the data into memory when needed, using a separate thread.

    For the renderer, the mesh object is only a temporary container to build up the correct format. The generated hardware-dependent format is used by the application to draw the scene. The reason for this strict separation is the ability to tailor the data optimally for the GPU found in the PC on which the application is currently running. We use only the vertex data that are actually needed.

    This separation becomes useful in the adaptation of needed texture coordinates: On less powerful hardware, many visual effects are turned off because the hardware is incapable of running them, or because the overall rendering load needs to be reduced. Because these effects are not rendered, the texture coordinates used by these effects need not be passed to the graphics hardware. They can simply be removed. So we reduce memory consumption and save processor power and bandwidth.

    For this task, we provide a submodule, which we have named Vertexprocessor, that translates the generic mesh data into the specified hardware structure. The following steps are necessary for the data to be prepared for multistreaming:

    - When a mesh resource is requested, Vertexprocessor loads this data into memory if the object isn't already available, or increments the reference counter of the mesh object if it is already loaded.
    - The stored vertex format of the mesh object is determined. This can happen via the embedded FVF flag or with the implementation used in the resource class (hardware independent).
    - The Vertexprocessor divides the single generic vertex arrays into the four hardware-specific vertex streams (that is, streams G, T, A, and I, discussed in Section 5.1). The vertex arrays are accessed by the MeshResource:etVertexStreamArray() method, as shown in Figure 5-4, which translates or copies the arrays into the specific component of one of the four vertex buffers.

    [Bild: 05_multistreaming_4.jpg]
    Figure 5-4 Query of Single Vertex Streams Used by Vertexprocessor

    Geometry Data

    The Vertexprocessor unit for geometry data seeks position, normals, and the two colors (if available) from a mesh object.

    For illustration purposes, Listing 5-3 creates a vertex buffer that contains all this information and uses this specific vertex layout. The buffer should have a cache-friendly size of 32 bytes per entry, so the layout is fixed for this buffer type.

    Example 5-3. Creating a Vertex Buffer

    Code:
     D3DVERTEXELEMENT9 m_VtxDcl[] =  {    {0, 0, D3DDECLTYPE_FLOAT3, D3DDECLMETHOD_DEFAULT,     D3DDECLUSAGE_POSITION, 0}, // stream 0, position    {0, 12, D3DDECLTYPE_FLOAT3, D3DDECLMETHOD_DEFAULT,     D3DDECLUSAGE_NORMAL, 0},   // stream 0, normal      {0, 24, D3DDECLTYPE_D3DCOLOR, D3DDECLMETHOD_DEFAULT,     D3DDECLUSAGE_COLOR, 0},    // stream 0, color 0    {0, 28, D3DDECLTYPE_D3DCOLOR, D3DDECLMETHOD_DEFAULT,     D3DDECLUSAGE_COLOR, 0},    // stream 0, color 1    };    // Here comes the vertex definition.  // Vertex format:  //     stream 0 -> position + normal + color 0 + color 1  struct sVTXStreamGeometry  {    float vecPos[ 3 ];    float vecNorm[ 3 ];    DWORD dwColor0, dwColor1;  };      // Data container Resourcemesh supports GetVertexStreamArray here.  // (See API methods above.)  cResourceMesh* m_pResourceMesh;    // Create the vertex declaration and create a specific vertex buffer.  // For clarity, we calculate the size of the buffer in the number of  // elements and the corresponding FVF flags. In our engine implementation,  // the geometry stream has a size of 32 bytes (cache-friendly), so we  // can easily create the sufficient memory size of the vertex buffer.  CreateVertexDeclaration( m_VtxDcl );  m_pVtxBuf0 = CreateVertexBuffer(NumVertices,                FVF_XYZ | FVF_NORMAL | FVF_DIFFUSE | FVF_SPECULAR);  sVTXStreamGeometry* pBuffer = LockBuffer(m_pVtxBuf0);    for each vertexIndex in m_pResourceMesh  {    pBuffer->m_vecPos =     m_pResourceMesh->GetVertexStreamArray(enum_Position, vertexIndex);    pBuffer->m_vecNorm =     m_pResourceMesh->GetVertexStreamArray(enum_Normal, vertexIndex);    pBuffer->m_dwColor0 =     m_pResourceMesh->GetVertexStreamArray(enum_Diffuse, vertexIndex);    pBuffer->m_dwColor1 =     m_pResourceMesh->GetVertexStreamArray(enum_Specular, vertexIndex);    pBuffer++;  }
    Texture Data

    The Vertexprocessor unit for texture data fetches the available texture coordinate slots from the mesh object and builds up a flexible vertex buffer with all necessary texture coordinates. At most, eight texture coordinate groups (with a 1D, 2D, 3D, or 4D vector per texture coordinate) are possible.

    In addition, one of the slots can be encoded as tangent vectors for tangent-space normal maps; otherwise, it would be necessary to use a separate vertex buffer stream for this information. We omit this in Listing 5-4 for clarity. It is, however, straightforward to add this feature.

    If light maps are available, we should use a separate Vertexprocessor unit (that is, a separate vertex buffer per mesh instance), because every instance must have unique UV pairs for light map textures. Light maps must be individually mapped, and their mapping coordinates depend on their world-space position, and so they can't be instantiated. This can be a big problem for the memory footprint and performance of your application. Consequently, light maps are useful for big meshes, such as terrain in outdoor scenarios or irregular wall meshes in dungeons, but not for small meshes or multi-instantiated objects.

    Example 5-4. A Vertex Buffer Stream for Texture Data

    Code:
       // Data container Resourcemesh supports GetVertexStreamArray here.  // (See API methods above.)  cResourceMesh* m_pResourceMesh;  // This is a template array structure to allocate a flexible amount  // of vtxDcl structures in one block  Array<D3DVERTEXELEMENT9> arrDeclVtx;    // We create a specific vertex buffer for textures. We use the FVF flag  // from Resourcemesh and filter the specific texture flags to create    // the specific buffer.  // For clarity, we use here a function that calculates the size of the  // buffer and the corresponding FVF flags. You can use an alternative  // implementation to calculate the correct size of the vertex buffer.  sVTXStreamTexture* pVtxBuf1 =   CreateVertexBuffer(NumTextureEntries,                      m_pResourceMesh->m_FVFFlag & TextureFlags);  // Lock buffer with unspecific byte pointer  char* pBuffer = LockBuffer( pVtxBuf1 );      // Current buffer position (in bytes) in locked data of vertex buffer  DWORD dwGlobalBufferPosition = 0;  for each textureIndex in m_pResourceMesh  {    DWORD dwCurrentOffset = 0; // Current offset position for vtxDecl      for (int i = 0; i<m_pResourceMesh->GetNumberOfTextureSlots(); i++)    {      // Array template allocates us a new structure at the end of the      // structure block and returns a nonconstant reference of the block.      // All structures allocated before remain unchanged (by realloc).        D3DVERTEXELEMENT9& flexibleElement = arrDeclVtx.InsertNewEnd();        flexibleElement.Stream = 1; // Is at 2nd position after Geometry      flexibleElement.Usage  = D3DDECLUSAGE_TEXCOORD;        // Current size in bytes of texture slots (u,v = 8 bytes)      // r,s,t = 12 bytes, r,s,t,w = 16 bytes      DWORD dwCurrentTextureSlotSize =            m_pResourceMesh->GetTextureCoordinateSizeBySlot( i );        // For specified slot, we look for what size (in bytes) we need        // and add it to our global offset counter dwCurrentOffset      flexibleElement.Offset = dwCurrentOffset;        // Calculate stream position in Resourcemesh for specified      // texture slot      int enumStreamArraySlot =        m_pResourceMesh->GetTextureSlotEnum( i );        // Now copy out the vertex information from the Resourcemesh        // stream into locked buffer      memcpy(&pBuffer[ dwGlobalBufferPosition + dwCurrentOffset ],       m_pResourceMesh->GetVertexStreamArray(enumStreamArraySlot,        textureindex), dwCurrentTextureSlotSize);        dwCurrentOffset += dwCurrentTextureSlotSize;        // Calculate types of vtxDecl (D3DDECLTYPE_FLOAT2 = 8 bytes,      // D3DDECLTYPE_FLOAT3 = 12 bytes, D3DDECLTYPE_FLOAT4 = 16 bytes)      flexibleElement.Type =        CalculateDataSizeType(dwCurrentTextureSlotSize);      }    // Add new position offset to global position in buffer      dwGlobalBufferPosition += dwCurrentOffset;  }
    Animation Data
    The Vertexprocessor unit for animation data builds up weights for animation skinning with bones in hardware. A varying number of weights per bone can be used, so it is not necessary to waste more memory than is really needed. In Gothic III, we use up to six weights per bone for our animation system.

    Index Data
    An index buffer corresponding to the above vertex buffers is also built up. Indices are stored into a mesh object as a separate stream of information. The bit size of index entries (whether 16 or 32 bit) depends on the number of vertices. Having more than 65,535 entries necessitates using DWORDs as index entries. Otherwise, WORD (16-bit) indices suffice. Choosing the smallest possible data type helps reduce an application's memory footprint.

    The Vertexprocessor has the responsibility to create all the previously described vertex buffers in an optimal manner for hardware (typically they are created as Pool_Managed and WriteOnly)(Ashida 2004).

    Rendering the Streams
    Once all the streams are built up properly, they are available for rendering and drawing.

    As an example of using streams separately, we execute the G-stream (that is, the geometry stream) as a separate z-pass, to achieve fast z-rejects in hardware and to use this buffer in conjunction with an occlusion query system implemented in the render system. (See Chapter 6 of this book, "Hardware Occlusion Queries Made Useful," for an example of such a system.)

    It is possible to add the A-stream (the animation stream) in the calculation, but the effort isn't worthwhile in most cases. The number of pixels that differ because of the animation is typically small and thus out of proportion to the additional rendering cost of adding animation.

    Individual streams are activated depending on the view (whether solid rendering or z-pass) by the renderer.

    5.3 Conclusion

    In this chapter, we have shown how current applications can overcome problems caused by the growing amount of geometry data in scenes. We've discussed a flexible model that gives the application more control over the data and drives the detected hardware optimally by combining two powerful techniques:

    - Several vertex buffers are combined via multistreaming.
    - Each vertex buffer is controlled by an optimized resource manager.

    A nice side benefit: we efficiently handle the bandwidth for data, which sometimes can be limited because of data duplication/redundant data transmission across the bus from system memory to the GPU.

    5.4 References

    Ashida, Koji. 2004. "Optimising the Graphics Pipeline." NVIDIA presentation. http://developer.nvidia.com/docs/IO/...onAndTools.pdf

    Cebenoyan, Cem. 2004. "Graphics Pipeline Performance." In GPU Gems, edited by Randima Fernando, pp. 473–486. Addison-Wesley. Available online at http://developer.nvidia.com/object/G...s_Samples.html

    For additional information about programming one or more streams in DirectX, see the Microsoft Web site:

    http://msdn.microsoft.com/directx

    Copyright

    Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and Addison-Wesley was aware of a trademark claim, the designations have been printed with initial capital letters or in all capitals.

    The authors and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein.

    NVIDIA makes no warranty or representation that the techniques described herein are free from any Intellectual Property claims. The reader assumes all risk of any such claims based on his or her use of these techniques.

    The publisher offers excellent discounts on this book when ordered in quantity for bulk purchases or special sales, which may include electronic versions and/or custom covers and content particular to your business, training goals, marketing focus, and branding interests. For more information, please contact:

    U.S. Corporate and Government Sales
    (800) 382-3419
    corpsales@pearsontechgroup.com

    For sales outside of the U.S., please contact:

    International Sales
    international@pearsoned.com

    Visit Addison-Wesley on the Web: www.awprofessional.com

    Library of Congress Cataloging-in-Publication Data

    GPU gems 2 : programming techniques for high-performance graphics and general-purpose
    computation / edited by Matt Pharr ; Randima Fernando, series editor.
    p. cm.
    Includes bibliographical references and index.
    ISBN 0-321-33559-7 (hardcover : alk. paper)
    1. Computer graphics. 2. Real-time programming. I. Pharr, Matt. II. Fernando, Randima.

    T385.G688 2005
    006.66—dc22
    2004030181

    GeForce™ and NVIDIA Quadro® are trademarks or registered trademarks of NVIDIA Corporation.

    Nalu, Timbury, and Clear Sailing images © 2004 NVIDIA Corporation.

    mental images and mental ray are trademarks or registered trademarks of mental images, GmbH.

    Copyright © 2005 by NVIDIA Corporation.

    All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form, or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior consent of the publisher. Printed in the United States of America. Published simultaneously in Canada.

    For information on obtaining permission for use of material from this work, please submit a written request to:

    Pearson Education, Inc.
    Rights and Contracts Department
    One Lake Street
    Upper Saddle River, NJ 07458

    Text printed in the United States on recycled paper at Quebecor World Taunton in Taunton, Massachusetts.

    Second printing, April 2005

    Dedication

    To everyone striving to make today's best computer graphics look primitive tomorrow


    Copyright © 2005 NVIDIA® Corporation. All rights reserved.

    [Bild: odin_md_akcr.jpg]
    ASUS LGA-1150 Z97-K, Intel Core i7-4770 3.4 GHz, EVGA GTX 980 Ti Hybrid ( 6.0 Gb), 16Gb DDR3, SSD OSZ Vertex 460A (240 Gb) + SSD Samsung SM951 M.2 (256 Gb), Dell Ultrasharp U2515H (2560 x 1440) + BenQ E2400HD (1920x1080)

  10. Visit Homepage View Forum Posts #10 Reply With Quote
    Knight Commander odin68's Avatar
    Join Date
    Aug 2008
    Posts
    2,729
     
    odin68 is offline
    thg.ru 02/2002

    PC Graphics Beyond XBOX - <BR>NVIDIA Introduces GeForce4

    Редакция THG, 6 февраля 2002

    Вы читаете страницу 16 из 20

    Screenshots
    As usual, NVIDIA introduces its new products with impressive technology demos. The following shows some screenshots from the CODECULT 3D engine.

    Codecult CODECREATURES Demo

    Codecult comes from German developers, under the aegis of Phenomenia. For the launch of the GeForce4, they present a demo that takes advantage of the capabilites of modern graphics cards.

    [Bild: codecult1.jpg]

    [Bild: codecult2.jpg]

    [Bild: codecult3.jpg]

    The demo runs best with 128 MB cards, since 64 MB boards have to rely on the AGP. We asked the developers for their opinion on the new GeForce4.

    THG: What do you think of the Vertex Shaders in general and the double Vertex Shaders of the GeForce4?

    Kurt Pelzer, Senior Programmer: In principle, anything is useful which increases performance. Programmable Vertex Shaders in particular are a must for the future, and as no modifications to the existing code are required to support the performance advantage of the second VS, it is an ideal extension of the available architecture for any user.

    THG: What's your view on NVIDIA's leaving out the (ATI) Pixel Shader of version 1.4?

    Stefan Herget - Managing Director of Codecult: Thanks to its extremely modular and flexible architecture, the CODECREATURES engine is arbitrarily expandable and supports PS 1.4.
    The game developer can implement special PS effects, therefore it depends on his decision whether version 1.4 or only 1.1 or 1.3 is supported. The library of prefabricated Shader effects provided by us will first be optimized for the common hardware base, and will thus use version 1.1 or 1.3, although the engine already supports 1.4. We will later extend our effect library directly for version 2.0.

    ИСТОЧНИК

    [Bild: odin_md_akcr.jpg]
    ASUS LGA-1150 Z97-K, Intel Core i7-4770 3.4 GHz, EVGA GTX 980 Ti Hybrid ( 6.0 Gb), 16Gb DDR3, SSD OSZ Vertex 460A (240 Gb) + SSD Samsung SM951 M.2 (256 Gb), Dell Ultrasharp U2515H (2560 x 1440) + BenQ E2400HD (1920x1080)

  11. Visit Homepage View Forum Posts #11 Reply With Quote
    Knight Commander odin68's Avatar
    Join Date
    Aug 2008
    Posts
    2,729
     
    odin68 is offline
    codesailor.com

    [Bild: contact.jpg]

    Contact

    Email Address
    kurt.?@gmx.net (replace '?' with 'pelzer')


    Profile

    Short bio
    Kurt Pelzer is a Software Engineer & Architect with more than a decade of experience in professional software development for the 3D real-time simulation & game industry. He works with Piranha Bytes (and some other customers in Europe / US area). Kurt has been involved in all stages of development from conceptual and technical design, to implementation, debugging and testing. Additionally, Kurt is the author of a number of technology articles published in the most popular software book series for game developers, especially: GPU Gems, Game Programming Gems and ShaderX. Before stepping into the world of professional simulation & game development, Kurt has studied mathematics & computer science.

    Services
    Software development for Microsoft Win OS, Apple OS X, Sony PS 4 (Pro), Microsoft XBOX One (X), Nintendo Switch, Nintendo 3DS-Familie, Smartphones / Tablets based on Android and iOS // designing complete software architectures // balancing of final game design // game development => game module design, AI systems (fight, skills, party, dialog, quests), advanced pathfinding, physic support, script support, camera system, cutscene-sequencer // engine development => scene & resource management, fast handling of large world data, processing & render pipeline, animation systems, sound playback & video streaming, data-modelling, network & RPC handling // graphic programming (DirectX & OpenGL / Vulcan, GPU & shader programming) // integration and modification of third-party middleware tools // secure programming => eliminating code vulnerabilities // general software optimizations // programming plugins & scripts for 3DStudio MAX, Maya & Softimage|XSI // setup of multi-platform build systems for continuous integration // building tech-demos (esp.: real-time simulations & cutting-edge 3D graphics) // writing technology articles including demo applications.

    Skills
    More than 15 years of professional C/C++ programming experience in the industry // successful track record of completing assigned projects // experience on more than five released and awarded 3D-titles // highly talented problem solver & eagerness to find simple solutions // strong 3D math skills // can adapt to style guides // strong skills in designing, implementing, debugging and optimizing 3D real-time engines & games // practical experience of refactoring techniques and working with legacy code // has eager for both, learning from others and teaching them // self-motivated, detail and multi-task orientated with strong time management skills // has the ability to focus on priorities and meeting deadline // able to improve software development by extreme programming, test-driven development (unit testing) & scrum (agile project management).


    3D-RT-Engines

    Elex-Engine - 2nd Evolution Step of Genome-Engine
    Dev.-Studio: Piranha Bytes, 2017
    Platforms: PC (Windows OS) & Microsoft XBOX One & Sony PlayStation 4
    About the engine:
    The engine created at Piranha Bytes to build the PC & XBOX One & PlayStation 4 game Elex.

    Risen-Engine - 1st Evolution Step of Genome-Engine
    Dev.-Studio: Piranha Bytes, 2009 & 2012 & 2014 / 2015
    Platforms: PC (Windows OS) & Microsoft XBOX 360 & Sony PlayStation 3 & Sony PlayStation 4
    About the engine:
    The engine created at Piranha Bytes to build the PC & XBOX 360 game Risen, the PC & XBOX 360 & PlayStation 3 game Risen 2: Dark Waters and the PC & XBOX 360 & PlayStation 3 & PlayStation 4 game Risen 3: Titan Lords.
    PenFU-Engine
    Dev.-Studio: 10Tacle Studios Mobile, 2007
    Platform: Sony PSP & Nintendo DS
    About the engine:
    The engine created at 10Tacle Mobile to prototype new games for handheld consoles.

    Genome-Engine
    Dev.-Studio: Piranha Bytes, 2006
    Platform: PC (Windows OS)
    About the engine:
    The engine & editor created at Piranha Bytes to build the PC game Gothic 3.
    Codecreatures Game Development System
    Dev.-Studio: Codecult, 2003
    Platform: PC (Windows OS)
    About the engine:
    Codecreatures was one of the European Consumer Trade Show (ECTS) 2001 highlights!

    ZenGin-Engine
    Dev.-Studio: Piranha Bytes, 2001
    Platform: PC (Windows OS)
    About the engine:
    The engine & editor created at Piranha Bytes to build the PC games Gothic, Gothic 2 & AddOn.


    Contracting Partners

    Some Representative Examples
    NVIDIA Corporation - USA
    Addison Wesley (Pearson Education) - USA
    Jones and Bartlett Publishers (J&B) - USA
    Charles River Media, Inc. - USA
    THOMSON / Thomson Learning - USA
    Piranha Bytes / Pluto 13 GmbH - GERMANY
    Nevigo GmbH - GERMANY
    10Tacle Studios Mobile GmbH - GERMANY
    Wordware Publishing, Inc. - USA
    Codecult Software GmbH / H2 Labs - GERMANY

    Some Statements ...
    M. Papakipos, Director of Architecture, NVIDIA:
    "... amazing. It’s great work, Pelzer. I can’t wait to see what you do 'next' ..."

    K. Wilder, Developer Relations Manager, NVIDIA:
    "Kurt is a brilliant programmer and before Piranha Bytes, he was at Codecult where he was absolutely critical to the success of both the Codecreatures launch demo and to the benchmark - and to the success of the GeForce 4 Ti launch!"

    J.B., Addison-Wesley's External Reviewer:
    "Pelzer provides an excellent course on implementing this difficult but powerful effect in real-time ... drastically improving the quality of outdoor environments ... Overall this is a wonderful, clean and informative article."


    Publications

    Referenced Articles: Three of Kurt's technology articles have been used for reference in the latest edition of the book 'Real-Time Rendering', the bible of graphics programming.

    Game Engine Gems 1
    "Inter-Process Communication Based on Your Own RPC Subsystem" (pp.339-349).
    Released by Jones and Bartlett Publishers (J&B), 2010
    About the book:
    Game Engine Gems brings dozens of brand new articles from leading software engineering professionals together in a single volume. Each "gem" in this book presents a previously unpublished technique related to game engines and real-time virtual simulations, and each one is supported by many years of experience and wisdom possessed by the authors. Specific topics include rendering techniques, shaders, scene organization, visibility determination, collision detection, audio, user interface, input devices, memory management, artificial intelligence, resource organization, and cross-platform considerations.

    ShaderX5
    "Pre-Processing of Complex, Static Scenes for Fast Real-Time Graphics" (pp.107-114).
    Released by Charles River Media / Thomson, 2007
    About the book:
    ShaderX5 Advanced Rendering Techniques is the newest volume in this cutting-edge, indispensable series for game and graphics programmers. This all new volume is packed with articles covering state-of-the-art shader techniques and tools written by programming professionals from around the world. These authors have a wealth of knowledge and experience in the field, and each section is edited by an industry expert to ensure the highest quality and usefulness!

    ShaderX4
    "Indicator Materials" (pp.513-522).
    Released by Charles River Media, Inc., 2006
    About the book:
    ShaderX4: Lighting & Rendering is a new volume in this successful series. All of the articles are brand new and provide graphics and game programmers with innovative, ready-to use techniques and tips for programming cutting-edge shaders. All of the techniques are written by pros and each section is edited by an industry expert. These techniques have evolved from work on movies, games, and animation. By using these techniques, programmers will become more efficient and better prepared to overcome a variety of shader programming challenges.

    GPU Gems 2
    "Optimizing Resource Management with Multistreaming" (pp.75-90).
    Released by Addison-Wesley Professional & NVIDIA, 2005
    About the book:
    Rémi Arnaud (Graphics Architect at Sony Computer Entertainment): "GPU Gems 2 isn’t meant to simply adorn your bookshelf—it’s required reading for anyone trying to keep pace with the rapid evolution of programmable graphics. If you’re serious about graphics, this book will take you to the edge of what the GPU can do."
    Gary McTaggart (Software Engineer at Valve, Creators of Half-Life and Counter-Strike): "The topics covered in GPU Gems 2 are critical to the next generation of game engines."

    GPU Gems
    "Rendering Countless Blades of Waving Grass" (pp.107-121).
    Released by Addison-Wesley Professional & NVIDIA, 2004
    About the book:
    David Kirk (Chief Scientist at NVIDIA): "This collection will allow programmers to benefit from the exciting progress already made, and it will enable tomorrow's developers to stand on the shoulders of giants, the pioneers of programming GPUs. It's up to you to take the next steps of innovation!"
    Tim Sweeney (Lead Programmer of Unreal Engine at Epic Games): "GPU Gems is a cool toolbox of advanced graphics techniques. Novice programmers and graphics gurus alike will find the Gems practical, intriguing and useful."

    Game Programming Gems 4
    "Combined Depth and ID-Based Shadow Buffers" (pp.411-425).
    Released by Charles River Media, Inc., 2004
    About the book:
    Uncover the secrets of the game industry’s best programmers with the newest volume of the Game Programming Gems series.With over 60 all new techniques, Game Programming Gems 4 continues to be the definitive resource for developers. Written by expert game developers who make today’s amazing games, these articles not only provide quick solutions to cutting-edge problems, but they provide insights that you’ll return to again and again. They’ll spark your creativity and inspire your own discoveries.

    ShaderX2
    "Advanced Water Effects" (pp.207-225).
    "Advanced Sky Dome Rendering" (pp.240-250).
    Released by Wordware Publishing, Inc., 2004
    About the book:
    Divided into six sections, this book focuses on a wide array of shader programming topics, including: Rendering techniques & Water simulations.Level: Advanced; Category: Game and graphics programming / DirectX.

    Additional Interviews, Quotes & Testimonials
    Technology reviews, complete interviews, quotes & statements, 2002 - 2017
    ** Making Games (article "Genome Evolution" about engine development at Piranha Bytes), 2017
    ** Cynamite.de (statement about currentgen / nextgen), 2008
    ** NVIDIA GeForce 6800 Launch (GeForce 6 technology review), 2004
    ** PC Games Hardware (interview about the technology behind Gothic), 2004
    ** c’t (interview about DirectX9), 2002
    ** PC Games (quote for the Matrox Parhelia 512), 2002
    ** PC Action (statement about upcoming hardware features), 2002
    ** Tom’s Hardware Guide (NV25 technology review), 2002

    [Bild: odin_md_akcr.jpg]
    ASUS LGA-1150 Z97-K, Intel Core i7-4770 3.4 GHz, EVGA GTX 980 Ti Hybrid ( 6.0 Gb), 16Gb DDR3, SSD OSZ Vertex 460A (240 Gb) + SSD Samsung SM951 M.2 (256 Gb), Dell Ultrasharp U2515H (2560 x 1440) + BenQ E2400HD (1920x1080)

  12. Visit Homepage View Forum Posts #12 Reply With Quote
    Knight Commander odin68's Avatar
    Join Date
    Aug 2008
    Posts
    2,729
     
    odin68 is offline
    makinggames.biz 01/2018

    18.01.2018

    ИСТОЧНИК

    Elex – The Genome Evolution

    автор - Maci Naeem

    [Bild: Editor_mit_Anzeige_des_Navigation_Mesh.jpg]

    Piranha’s very own Genome Engine was first used for Gothic 3, developed further and further over the years, and is now the core of their latest role-playing adventure.

    Genome is the name of the engine which we used for our soon-to-be released game »Elex«. Previously, it was used in »Gothic 3« as well as »Risen 1, 2 and 3«. The development of the Genome Engine started in-house at Piranha Bytes in 2003, prior to the project start of Gothic 3. Parallel to that, the team was working on the »Gothic 2« addon »Night of the Raven« which was still based on the technology used in Gothic and Gothic 2.

    The Genome Engine has undergone fundamental changes in the last 14 years. Most components were revised and extended from project to project, while others were replaced completely. In the current version, there are hardly any components left from those early days.

    Historic development

    In the following, we will first provide a brief description of how our Genome Engine has developed over the course of the past projects, and then talk about two components in more detail.

    Gothic 3

    Developing an engine from scratch and simultaneously working on a game like Gothic 3 using said engine is a huge challenge and caused us quite a few problems. Since parts of the planning and development already took part during the production of the addon »Night of the Raven«, the basic structure was ready at the beginning of the development of Gothic 3, but a lot of important parts of the engine and game were still missing. Apart from the engine, we also developed the editor to fill the world with life and to tell the story of Gothic 3. Another challenge was the game world, which was massive compared to other games at the time, and the resulting memory usage. Due to the programming effort and the huge amount of data that we had to create the project was delayed, which was why Gothic 3 could only be completed under enormous time pressure and with the help of enormous amounts of coffee. The tight schedule and the number and complexity of the modules that we needed to develop unfortunately took their toll: Some systems were immature and prone to bugs, which was reflected in the quality of the final product.

    [Bild: Line_Sweep_Ambient_Obsurance_696x392.jpg]
    Line-Sweep Ambient Obscurance

    Risen

    The technical issues of Gothic 3 raised a lot of criticism, most of it justified, which we took very seriously. Hence, for Risen we decided to focus on stability in the further development of the Genome Engine. During the development of Gothic 3, all programmers were responsible themselves to integrate their modifications in the editor or make them available for new editors. More often than not, this was more work than working on the engine itself and led to an inconsistent functionality of the editor.

    “THAT’S WHY WE NOT ONLY REVISED LARGE PARTS OF THE ENGINE, BUT ALSO FUNDAMENTALLY OUR TOOLS.”


    We replaced some modules like the streaming, event, interaction, movement and physics systems and moved our focus to the stability and maintainability of these systems. We also significantly rebuilt the Genome Engine in terms of graphics: Apart from HDR Rendering and Cascade Shadow, Risen was given a databased post-processing pipeline to be able to implement new effects like Screen Space Ambient Occlusion or better depth cueing. Risen was also the first game of Piranha Bytes to be released on console, which resulted in even more substantial changes to the engine.

    Risen 2

    After we had reached the target we had set ourselves – to release Risen as a stable and largely bug-free game – we were able to move the focus to the further development of the engine for Risen 2. One of the most significant changes was the transition of the animation software from EMotionFX to NaturalMotions Morpheme. With this step, we hoped to achieve considerable improvements of the animation quality since Morpheme allowed for a databased generation of complex animation processes. Additionally, we developed a Cutscene Sequencer to create and play cutscenes using in-game graphics. We also completely replaced the game camera with a databased system. While in the previous games the entire landscape was created manually in a 3D program, a Terrain Engine was first used for Risen 2. The title was released for both PC and Xbox 360 as well as PlayStation 3.

    Risen 3

    In the final part of the Risen series, our focus moved back to the further development of the graphics engine. Like in Gothic 3 it was based on DirectX9, but was switched to a Full Deferred Renderer and extended by physically-based shading. This allowed for a more realistic presentation of various materials like metal, stone or fabric. We also invested a lot of time in environmental effects like volumetric fog with shadows and an im proved water presentation. One of the biggest changes in Risen 3 though was the integration of a polygon-based road system to navigate the NPCs. This saved us both a lot of time and nerves since the road system could now be generated automatically from the collision geometry and was less high-maintenance and prone to bugs.

    [Bild: Kopf_Engine_592x1024.jpg]
    Most NPCs are created in the engine via morphing.
    All varieties of heads are based on the same topology.

    Risen 3, too, was released for Xbox 360 and PlayStation 3. The release was followed by a port to the then newly launched PlayStation 4, which was released together with a graphically modified 64-bit enhanced PC version. Apart from higher-resolution textures, this version featured volumetric clouds, depth cueing with Bokeh and a revised bloom effect.

    Elex

    For Elex, we had made some big plans. Apart from the unique setting – a mix of fantasy and science fiction – we also ventured into completely new territory in terms of gameplay and graphics programming. We changed the
    Genome Engine from DirectX9 to DirektX11, which opened up a lot of new possibilities in terms of the graphical development of Elex.

    The material system was replaced completely and expanded by new techniques like tessellation. Plus, we implemented a series of new effects like Line Sweep Ambient Obscurance, physically-based volumetric light, volumetric clouds, flowmap-based water for all water surfaces and global illumination.


    Additional features that were made available for Elex are spline meshes (structures running along any given curved line for large roots, roads, pipelines, etc.) as well as an automatically (rule-based) operating vegetation system. While Risen 2 and 3 were set on several small islands, for Elex we decided to go with one large coherent land mass – for the first time since Gothic 3. In order to deal with the resulting data volume (the uncompressed height map alone took up 4 GB!), we also had to rewrite the world streaming from scratch. We also revised the AI of the NPCs: We switched from a completely script-based implementation of the NPC perception to a data-driven perception system which, triggered by stimulations, leads to the desired reactions. Elex will be available for both PC as well as for PlayStation 4 and Xbox One.

    The navigation

    Over the course of the various projects, comprehensive modifications needed to be done to the navigation system.
    For Gothic 3, we devised a new system from scratch according to a concept of our own which was based on zones (»fenced areas«) and paths connecting these zones. The corresponding data had to be inserted manually into the editor and maintained. Also, the entities in the world caused additional static and dynamic obstacles like trees and NPCs.

    [Bild: Spline_Mesh_verwendet_f_r_Stra_enverlauf.jpg]
    Elex uses spline meshes, e.g. to create road courses.

    By the time of the launch of Gothic 3, the system worked, but the zones were not always placed according to the rules, which led to bugs and performance issues. For Risen, this meant that critical constructions had to be marked while editing. Additionally, an in-game visualization in the live game was to make the debugging process easier. The system was extended by »free navigation« outside the defined areas. This helped us get rid of the remaining bugs. Basic performance optimizations were then tackled during the development of Risen 2. With the project start of Risen 3, it became clear that we wanted a future-proof system which would generate the required data automatically by evaluating the level geometry and objection.

    Navigation meshes generated through »recast« and reduced to the parts actually required in a second step, have since been the basis of our pathfinding system. Since we also wanted walking NPCs on rocking and moving ships, we enabled the system to navigate on moving objects as well.

    The massive coherent world of Elex eventually required further additions. Now, only the parts of the navigation mesh are loaded and used which belong to the corresponding area where the player or the game camera is currently at. Additionally, we implemented a compact net derived from the detailed navigation mesh, including a smooth change between both variants. This enables performant pathfinding beyond the currently loaded parts in the entire game world.

    [Bild: Beleuchtung_Engine_592x1024.jpg]
    Without GI and Bouncelight, interiors are
    hard to illuminate; after the GI
    implementation, all materials were
    correctly illuminated, adding
    to the ambience.

    The renderer

    The renderer is the part of the engine responsible for displaying 3D objects and their illumination. Usually, the scene as seen by the camera is »rendered« in a texture, later supplemented with all sorts of effects during post-processing, and finally displayed on screen.

    Over time, the renderer of the Genome Engine underwent a series of modifications. While a forward renderer was implemented for Gothic 3, meaning all objects were directly illuminated during rendering on the texture, we used a light pre-pass renderer for Risen 1 and 2 where, in an additional pre-pass, information about the material properties for all non-transparent objects is rendered in a texture to help generate the illumination in another texture. This texture will later be used on the same objects during the forward pass. The advantage of this technique is that lights and 3D objects can be separated from each other, making it possible to display more per-pixel lights.

    In Risen 3, the renderer was then switched to a deferred renderer which allows for more complex material properties vs. the light pre-pass technique. The forward pass for non-transparent objects is completely left out here. Instead, all material information will be rendered in several textures (the G-buffer) which will then be used to generate the completely illuminated image. Since neither light pre-pass nor deferred renderer naturally support native antialiasing (MSAA) (with a significant memory usage it is possible though) and the display of complex materials like hair and skin is very complicated and expensive, for Elex we decided to go with the old concept of the forward renderer.

    Thanks to DX11 it was now possible to display a large number of lights directly during the rendering of the objects. Since this technique is an upgrade to the classic forward renderer, it is also called Forward+. The innovation here is that all lights that are potentially visible on the screen, are inserted in a 2D (tiled lighting) or 3D texture (clustered lighting). Every pixel in this texture represents a part of the screen and refers to a list of lights relevant to it. Another advantage of this technique is that transparent and solid materials can be equally treated.

    [Bild: GBuffer_Teile_1.jpg]

    This image shows the material properties of a fully rendered image and the corresponding parts of the G-buffer (Albedo, Roughness, Normal).

    Since the forward+ renderer was implemented and functional, we had a lot of problems with the speed of this technique though, especially on the consoles and older PCs. It turned out that the complexity of the shaders was a considerable cause of these problems since all necessary calculations like material properties, illumination, shadow and fog had to take place in a shader. In order to reduce the complexity of the shaders, we decided to switch back to a deferred renderer. Due to the timing of this decision, this wasn’t exactly easy since the volume of features and the data which had already been generated were to remain the same.

    The solution was the tiled deferred technique which is also used in Uncharted 4, among others. It divides the G-buffer into 8×8 pixel-sized parts. For each of these parts, it checks the occurrence of material combinations and correspondingly enters the parts in a list for these combinations. Later, the parts of the shaders, optimized for the material combinations, will be illuminated and displayed, separating the material properties (G-buffer) from the illumination.

    Also, any further required calculations like sun shade and fog can be excluded from the still very complex shaders in pre- and post-passes, which improves the speed even more. Since the renderer was originally meant to be a forward renderer and the most »Forward+« techniques like clustered lighting resulted from the transition, the advantage was that there were only minor differences to be seen between »deferred« rendered (solid) and »forward« rendered (transparent) objects and big parts of the implementation remained the same.

    Conclusion

    A lot has happened in hindsight. While the development of the Genome Engine started with a difficult initial phase, it was pushed further and further over the course of the various projects. Ever changing requirements, new possibilities due to the changing generations of consoles and PC hardware and, last but not least, new and improved software technologies gradually led to the current status quo.

    We wish you a lot of fun and exciting times with Elex which we built on that engine. We also would like to thank all developers involved again.




    About the Authors:

    [Bild: Kurt_Philipp_768x432__1_.jpg]

    Kurz Pelzer is Senior Software Engineer at Piranha Bytes (left)
    Phillip Krause is Lead Programmer at Piranha Bytes (right)

    Kurt has been developing engines for games and 3D real-time simulations (Codecults Codecreatures Engine, ZenGIN, Genome Engine, and more) for 18 years. Prior to that, he studied mathematics. Since Gothic 1 he works on games for Piranha Bytes and is also a consultant to start-ups. Kurt is author of a large number of tech articles which were published in book series like Game Programming Gems, ShaderX and GPU Gems, among others.

    Philipp took his first steps on the C64 and later programmed demos and games on the Amiga. He joined the games industry in 2000, working on the Codecreature Engine for CodeCult as Tool Programmer and later on »Söldner« and »Söldner: Marine Corps« (later renamed to »Semper Fidelis Marine Corps«) for Wings Simulations. He joined Piranha Bytes during the development of Gothic 3, where he was appointed Lead Programmer in 2006. For Elex, he was primarily responsible for graphics programming and optimization.

    [Bild: odin_md_akcr.jpg]
    ASUS LGA-1150 Z97-K, Intel Core i7-4770 3.4 GHz, EVGA GTX 980 Ti Hybrid ( 6.0 Gb), 16Gb DDR3, SSD OSZ Vertex 460A (240 Gb) + SSD Samsung SM951 M.2 (256 Gb), Dell Ultrasharp U2515H (2560 x 1440) + BenQ E2400HD (1920x1080)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
Impressum | Наши Баннеры | Приват
World of Gothic © by World of Gothic Team
Gothic, Gothic 2 & Gothic 3 are © by Piranha Bytes & Egmont Interactive & JoWooD Productions AG, all rights reserved worldwide