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

 

Ergebnis 1 bis 11 von 11
  1. Homepage besuchen Beiträge anzeigen #1 Zitieren
    Knight Commander Avatar von odin68
    Registriert seit
    Aug 2008
    Beiträge
    2.729
     
    odin68 ist offline

    [PB] Оливер Хёллер - программирование /Oliver Höller, externer Programmierer


    [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)
    Geändert von odin68 (22.12.2017 um 08:00 Uhr)

  2. Homepage besuchen Beiträge anzeigen #2 Zitieren
    Knight Commander Avatar von odin68
    Registriert seit
    Aug 2008
    Beiträge
    2.729
     
    odin68 ist 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)

  3. Homepage besuchen Beiträge anzeigen #3 Zitieren
    Knight Commander Avatar von odin68
    Registriert seit
    Aug 2008
    Beiträge
    2.729
     
    odin68 ist offline
    [Bild: gi8X9o7bnm0qgrJt04.jpg]
    Программисты на работе. (на первом плане Оливер Хёллер, позади Карстен Эденфельд)

    [Bild: IMG_6289.jpg]
    Пещера программистов: слева Карстен Эденфельд, в центре Оливер Хёллер

    [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. Homepage besuchen Beiträge anzeigen #4 Zitieren
    Knight Commander Avatar von odin68
    Registriert seit
    Aug 2008
    Beiträge
    2.729
     
    odin68 ist offline
    Оливер Хёллер / Oliver Höller
    CEO, Head of Development
    Kodierwerk GmbH Essen, Германия

    [Bild: Oliver_Hoeller.jpg]

    09/1999 - 12/2000
    Lead Programmer
    Codecult Research & Development GmbH
    www.codecult.com
    Уровень карьеры: Менеджер (с работой с персоналом и без)

    01/2000 - 12/2002
    Head of Development
    Codecult Research & Development GmbH
    www.codecult.com
    Уровень карьеры: Директор (руководитель отдела, VP, SVP и т.д.)

    01/2003 - 08/2007
    Senior software engineer/Consultant
    Piranha Bytes (Pluto 13 GmbH)
    www.piranha-bytes.com
    Уровень карьеры: Менеджер (с работой с персоналом и без)

    ....

    12/2009 - 01/2012
    Lead Programmer
    Nevigo GmbH
    www.nevigo.com
    Уровень карьеры: Менеджер (с работой с персоналом и без)

    [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. Homepage besuchen Beiträge anzeigen #5 Zitieren
    Knight Commander Avatar von odin68
    Registriert seit
    Aug 2008
    Beiträge
    2.729
     
    odin68 ist 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)

  6. Homepage besuchen Beiträge anzeigen #6 Zitieren
    Knight Commander Avatar von odin68
    Registriert seit
    Aug 2008
    Beiträge
    2.729
     
    odin68 ist offline
    Phenomedia 03/2000

    [Bild: phenomedia_ar_e_99_20.jpg]

    Stefan Herget and Oliver Höller
    – setting global standards for 3D-engines

    [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)

  7. Homepage besuchen Beiträge anzeigen #7 Zitieren
    Knight Commander Avatar von odin68
    Registriert seit
    Aug 2008
    Beiträge
    2.729
     
    odin68 ist offline
    gulp.de

    Projekthistorie
    Projekte, Referenzen und Publikationen:
    -----------------------------------------------------------
    2018 GenXBot, Robot-Platform (in Development)
    2018 Stryker Platform Adapt 2.1
    2017 Stryker Adapt 2.0 Platform for Hip Fracture/Adapt
    2013 Erweiterung Stryker FluoroMap Softwarefür das „Gamma3 Hip Fracture System“
    2012 Trentino SOA Laufzeitumgebung für das SmartGrid von Siemens
    2011 Articy:draft
    2009 Entwicklung Kompressionsalgorithmus für ein Sensormodul der Firma Humotion GmbH
    zur Sturzprävention
    2008 „My life in cash“, Finanzplanung, Investmentplanung, Haushaltbudgetierung
    2008 Erweiterung des Händler-Portals der Volkswagen AG im Auftrage der WebOne GmbH
    2007 Needya.tv Präsentationsprototyp, Rich-Media Client für eine Seed Unternehmung
    2006 Gothic 3, eines der erfolgreichsten deutschen Full-Price Computerspiele
    2004 Publikation des Artikels „Optimizing Resource Management with Multistreaming“
    für das Buch GPU-Gems II (Addison-Wesley, USA)

    2003 Publikation eines Artikels „3D Engine Design“ für das Buch
    „ShaderX“ (Wordware, USA)
    2003 Gothic II Addon zum RPG Computerspiel Titel Gothic II
    2002 Simulations-Projekt der Transrapid Shanghai-Strecke der Firma Siemens AG.
    2001 codecreatures Benchmark exklusiv Demo, für den Launch der GForce4 Reihe der
    Firma Nvidia Corp. (Sitz in Santa Clara, CA)
    2000 Entwicklung des E3/ECTS Demos für das codecreatures Development System
    1995 Entwicklung des Programms „Profil Administrator+“ (vertrieben von Markt&Technik)
    1988 Entwicklung eines Musikprogrammes (C64) „Timecomposer“ (Digital Marketing)
    1987 Entwicklung eines Spiels auf dem C64 mit dem Namen „Platou“ (Kingsoft).


    Профессии:
    --------------------------------------
    Старший инженер-программист / Главный инженер / Архитектор C ++ / С # Разработка программного обеспечения и ИТ-консалтинг / управление проектами в основных областях медицины, робототехники (встраиваемых) и развлечений.
    2017 - сегодня .....: руководитель отдела разработки / управляющий директор
    2012 - 02/2019 ...: старший инженер-программист / главный инженер / старший консультант
    2009 - 2012 ......: ведущий архитектор программного обеспечения / ведущий программист
    2003 - 2009 ......: Старший инженер-программист / Консультант / Подрядчик
    2001 - 2003 ......: Руководитель отдела разработки
    1999 - 2001 ......: Старший программист


    Projekte:
    ---------------------------------------
    01/2017 - сегодня,
    3 года 1 месяц
    GenXBot
    роль - Руководитель отдела развития
    клиент - Kodierwerk GmbH
    расположение - Эссен, Рур

    11/2012 - сегодня,
    7 лет 3 месяца
    HipFx Adapt 2.0/2.1
    роль Старший инженер-программист / старший подрядчик
    клиент Stryker Corporation (Stryker Leibinger GmbH & Co. KG)

    02/2012 - 10/2012,
    9 месяцев
    Trentino SOA Runtime for embedded systems
    роль Старший инженер-программист / старший консультант
    клиент Siemens CT AG

    12/2009 - 01/2012
    2 года 2 месяца
    Articy:draft und Meshmill
    роль Ведущий архитектор программного обеспечения / Ведущий программист
    клиент Nevigo GmbH
    содержание проекта Управление и разработка дизайна основных и базовых компонентов для продуктов Meshmill и Articy:draft

    01/2009 - 11/2009
    11 месяцев
    Humotion Messtechnik und Biofeedbacksysteme: Aufnahme und Anaylse von Sensordaten
    роль Старший разработчик / консультант
    клиент Humotion GmbH

    05/2008 - 12/2008
    8 месяцев
    My Life in Cash (финансовое программное обеспечение)
    роль Старший разработчик / консультант
    клиент Delaro GmbH
    содержание проекта Соединение с базой данных, моделирование данных и моделей, а также связанная бизнес-логика

    09/2007 - 04/2008
    8 месяцев
    Дилерская платформа для Volkswagen AG
    роль Старший разработчик
    клиент WebOne GmbH
    содержание проекта Внедрение инструментов импорта и миграции для дилерского портала.

    03/2007 - 04/2008
    1 год 2 месяца
    Rich Media Client
    роль Главный архитектор программного обеспечения
    клиент Needya.tv (венчурная компания с партнерами
    содержание проекта Концепция, разработка клиента для социальных сетей для мультимедийного контента, а также для развлечений и веб-контента.

    12/2006 - 09/2007
    10 месяцев
    RPG
    роль Консультант / Подрядчик, Старший разработчик
    клиент Pluto 13 GmbH (Piranha Bytes)
    содержание проекта Оптимизация и расширение системы разработки игр «Genome» для предстоящего названия игры от Piranha Bytes, подготовка к порту XBox 360
    знание C++/ C# / MSVC++ 2005 / разнообразные сторонние инструменты (Speedtree / MotionFX / PhysX)

    02/2003 - 11/2006
    3 года 10 месяцев
    Gothic 3
    роль Консультант / Подрядчик, Старший разработчик
    клиент Pluto 13 GmbH (Piranha Bytes)
    содержание проекта Отвечает за разработку компонентов ядра, рендеринг / управление ресурсами и сценами. Дальнейшее сотрудничество в реализации аддона Gothic II.
    знание C++/ C# / MSVC++ 2005/2203 / разнообразные сторонние инструменты (Speedtree / MotionFX / PhysX)

    08/2000 - 01/2003
    2 года 6 месяцев
    codecreatures 3D система разработки в реальном времени
    роль Руководитель отдела развития
    клиент Codecult Research & Development GmbH
    содержание проекта Руководитель разработки: Ответственный за проект трехмерной визуализации в реальном времени линии Transrapid в Шанхае (симулятор поездов шанхайского метро) для Siemens AG.
    знание C++/ Borland C++ / VCL / Delphi / MSVC++ (6.0 und 2001/03) / Borland

    09/1999 - 07/2000
    11 месяцев
    codecreatures 3D система разработки в реальном времени
    роль Ведущий программист
    клиент Codecult Research & Development GmbH
    содержание проекта Концепция и дизайн системы разработки, совместное управление областью разработки, управление различными проектами, такими как демонстрационная презентация для нового поколения видеокарт GForce4 от Nvidia (базируется в Санта-Кларе, Калифорния).
    знание C++/ Borland C++ / VCL / Delphi / MSVC++ (6.0 und 2001/03) / Borland C++ Builder

    03/1997 - 08/1999
    2 года 6 месяцев
    Сервер сайта, сервисы под W2k для VW AG и Berkom
    роль Бесплатный разработчик
    клиент WebOne Informatik GmbH
    содержание проекта Разработка приложений сервера сайта MS и предоставление различных сервисов операционной системы MS под W2k.
    знание C++/ Visual Basic / ASP / MS Visual Studio C++ 6.0 und MS Visual Studio VB 6.0

    01/1996 - 05/1998
    2 года 5 месяцев
    Использование Delphi и Interbase
    роль Бесплатный разработчик
    клиент Schroeder GbR
    содержание проекта Внедрение веб-приложений для Interbase SQL Server.
    знание C / Delphi / Interbase / Borland Delphi

    03/1995 - 03/1997
    2 года 1 месяц
    Поддержка ПК
    роль ИТ руководитель
    клиент Baedeker GmbH
    содержание проекта Устранение проблем EDP всех видов, поддержка проблем с офисными программами, поддержка с приобретением новых компьютеров, обучение сотрудников новым программам.

    01/1996 - 01/1997
    1 год 1 месяц
    Profil Administrator Plus
    клиент Eigenentwicklung
    содержание проекта Программа для управления Windows 95 для демонстрационных компьютеров или рабочих станций с ограниченным доступом, а также для восстановления стандартных профилей.
    знание C / C++ / Delphi / Borland Delphi / Visual Studio 5

    ИСТОЧНИК

    [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)
    Geändert von odin68 (14.02.2020 um 22:10 Uhr)

  8. Homepage besuchen Beiträge anzeigen #8 Zitieren
    Knight Commander Avatar von odin68
    Registriert seit
    Aug 2008
    Beiträge
    2.729
     
    odin68 ist offline
    ShaderX2: Shader Programming Tips and Tricks With Directx 9.0

    08/2003

    Section 6 – 3D Engine and Tools Design
    стр 625-630

    “Shaders under Control (Codecreatures Engine)”
    by Oliver Hoeller


    [Bild: 001w.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)
    Geändert von odin68 (15.02.2020 um 00:07 Uhr)

  9. Homepage besuchen Beiträge anzeigen #9 Zitieren
    Knight Commander Avatar von odin68
    Registriert seit
    Aug 2008
    Beiträge
    2.729
     
    odin68 ist 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, которая разработала RPG Gothic I и Gothic II. Ранее он был директором по разработке в H2Labs / Codecult, где он отвечал за разработку и проектирование архитектуры игровой системы Codecreatures. Он был активным участником немецкой демо-сцены в 1980-х и начале 1990-х годов. После изучения различных областей - разработки музыкального программного обеспечения, создания программы безопасности и работы консультантом по веб-сервисам - Оливер вернулся к своим истокам и теперь гарантирует высокий уровень визуального качества для предстоящей Готики III Piranha Bytes.


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

    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. Homepage besuchen Beiträge anzeigen #10 Zitieren
    Knight Commander Avatar von odin68
    Registriert seit
    Aug 2008
    Beiträge
    2.729
     
    odin68 ist offline
    PC Action 11/2001

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

    [Bild: codecult.jpg]

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

    [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. Homepage besuchen Beiträge anzeigen #11 Zitieren
    Knight Commander Avatar von odin68
    Registriert seit
    Aug 2008
    Beiträge
    2.729
     
    odin68 ist offline
    freelancermap.de

    [Bild: filename.png]

    ИСТОЧНИК

    PROJEKTHISTORIE

    01 / 2017 - heute
    Kodierwerk GmbH, Head of Development und Geschäftsführer
    Schwerpunkt Robotik in verteilten Systemen
    Tätigkeitsfeld: C, C++, Qt, C#, .net, (Micro-)Python, WPF, Embedded für ARM Cortex Mx MCUs (ST32, Arduino)

    02 / 2012 – heute
    Stryker Trauma und Extremities im medizinischen Umfeld, u.a. ‚Hip Fracture‘, Gamma3 Nagel, Einsatz von Software für den ausführenden Chirurgen im Bereich bildgebende Verfahren und Maschinelles Lernen, Einsatz als Freiberufler in der Rolle eines Senior Software Engineers und System Architekten.
    Tätigkeitsfeld: C, C++ Entwicklung, Python, Qt, QtQuick(QML), bildgebende Verfahren, Softwaredesign, Architektur, Tests und Reviews
    Siemens Corporate Technology im Embedded Bereich (smart grid), Einsatz als Freiberufler
    Tätigkeitsfeld: C, C++, .net, C#, Entwicklung

    12 / 2009 – 01 / 2012
    Nevigo GmbH. Lead Software Architect/Lead Software Developer
    Leitung und Entwicklungsdesign für folgende Produkte:
    „Meshmill“, das zum komfortablen Editieren von 3D-Punktmengen und Umwandeln in polygonale Mesh-Strukturen eingesetzt wird.
    „articy:draft“, welches zur Erzeugung von interaktiven Geschichtselementen und dazugehörige Assets benutzt wird, um komplexe und nicht lineare Handlungsstränge für multimediale Inhalte (u.a. Spiele/Filme) zu visualisieren und zu exportieren.
    Tätigkeitsfeld: C, C++, .net, C#, WPF, Entwicklung, Softwaredesign und Architektur

    05 / 2008 – 11 / 2009
    Delaro GmbH, Software Consultant
    u.a. Entwicklung der Finanzsoftware „My Life in cash“
    Tätigkeitsfeld: C#, .net, Windows Forms, Development

    Humotion GmbH, Anbieter von Produkten für den medizinischen (u.a. Geriatrie) und sportmedizinischen Bereich
    Entwicklung eines Kompressionsalgorithmus für Sensordaten in
    einer Embedded Microchip Umgebung sowie deren Analyse und visuelle Auswertung, Einsatz als Freiberufler
    Tätigkeitsfeld: C++, Embedded (Microchip), Development

    03 / 2007 – 04 / 2008
    Needya GbR, Software Architekt für die Prototyp-Entwicklung eines IPTV Rich Media-Clients, Einsatz als Freiberufler
    Tätigkeitsfeld: C++/C#, Qt, .net

    09 / 2007 – 04 / 2008
    WebOne GmbH. Consultant/Contractor/Senior Developer
    Einsatz als Freiberufler
    Volkswagen AG, Entwicklung/Weiterentwicklung der Authorisierungsapplikation des Händerportals (DP)
    Tätigkeitsfeld: C#, VB, .net, asp.net

    12 / 2006 – 09 / 2007
    Pluto 13 GmbH (Piranha Bytes), Consultant/Contractor
    Optimierung und Erweiterung des Game Development Systems „Genome“ für kommende Spieletitel aus dem Hause Piranha Bytes

    02 / 2003 – 11 / 2006
    Pluto13 GmbH (Piranha Bytes), Consultant/Contractor für den Triple-A Titel „Gothic 3“, Einsatz als Freiberufler
    Verantwortlich für die Entwicklung der Kernelkomponenten, Render-/Ressource und Scenemanagement.
    Mitarbeit bei der Umsetzung des Gothic II Addon

    08 / 2000 - 01 / 2003
    Codecult R&D GmbH, Head of Development/Projektleiter für die Codecreatures 3D Echtzeit Entwicklungsumgebung
    Fachlich zuständig für die Ausbildung und Betreuung von Praktikanten, Diplomanden und angehenden Fachinformatikern
    Nvidia Corp. (Sitz in Santa Clara, CA), Leitung diverser Projekte wie das Präsentationsdemo für die neue Grafikkarten-Generation GForce4
    Siemens AG, verantwortlich für das Projekt der 3D Echtzeit Visualisierung der Transrapid-Strecke in Shanghai

    09 / 1999 - 07 / 2000
    Codecult R&D GmbH, Leitender Programmierer für die Codecreatures 3D-Echtzeit Entwicklungsumgebung, Verantwortlich für das Architekturdesign und den strukturellen Aufbau der Codecreatures Engine
    Piranha Bytes GmbH, beratende Unterstützung für den RPG-Spieletitel Gothic

    03 / 1997 - 08 / 1999
    WebOne GmbH, Consultant/Developer für MCIS2 Systeme Microsoft (Site Server, Win32 Services, COM+ Components)
    Einsatz als Freiberufler für die Berliner Telekom (Berkom) und
    Volkswagen AG

    01/ 1996 - 05 / 1998
    EBusiness Solutions, IT-Bereich (Datenbanken Interbase, Borland Delphi VCL Components, Services), Einsatz als Freiberufler

    03 / 1995 - 03 / 1997
    Baedeker GmbH, DV-Betreuer, Wartung, Instandhaltung und Beratung im IT-Bereich (Teilzeitkraft)

    09 / 1993 - 11 / 1995
    Compunet GmbH, Werkstudent, System- und Netzwerkinstallationen u.a. für die Firma Provinzial.

    [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)

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
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