Modulární 3D prohlížeč pro Škoda Auto - report 4

Dosavadní stav implementace

• základní wxWidgets aplikace
• víceúrovňové logování událostí do okna a souboru s možností nastavení úrovně zobrazení
• kostra jádra (kernel) pro správu modulů
• jádro obsahuje několik serverů spravujících příslušné moduly

Poznámky k implementaci a další postup

• problém exportu C++ tříd/metod z modulu
• jádro definuje abstraktní třídu pro daný typ modulu
• modul definuje metody ve své zděděné třídě
• nutnost použití wrapperu nezávislého na platformě

Modulární 3D prohlížeč pro Škoda Auto - report 3

Předběžné zadání diplomové práce:

Navrhněte a implementujte modulární aplikaci sloužící jako jádro pro zpracování a vizualizaci 3D dat. Zaměřte se na návrh flexibilní modulární architektury pro efektivní použití externích modulů. Externí moduly budou v podobě dynamických knihoven s podporou vícevláknového zpracování. Zajistěte běh aplikace na operačních systémech Microsoft Windows a Linux.

Implementujte datové struktury pro graf scény do jádra aplikace. Graf scény bude možné modifikovat a musí podporovat reprezentaci tzv. variant jednotlivých částí scény. Aplikaci bude možné předat parametry z příkazové řádky a pomocí textového terminálu zadávat příkazy jádru aplikace a připojeným modulům.

Implementujte modul pro import a export grafických formátů FHS a OBJ, dále modul pro intuitivní ovládání kamery a modul pro zobrazení scény pomocí knihovny OpenGL.

K implementaci použijte jazyk ANSI C++ a využijte knihovny wxWidgets. Součástí práce bude dobře dokumentovaný zdrojový kód a přehledný návod k programu.

Hrubý návrh architektury aplikace:

Poznámky k návrhu

• vzhledem k nežádoucí závislosti na další knihovně a v případě použití OpenSceneGraph navíc zbytečné funkčnosti, bude graf scény implementován vlastní datovou strukturou
• prvek Scene BVH v jádře bude zjednodušenou implementací BV hierarchie, kterou bude možné nahradit externím modulem
• externí modul BVH bude moci využívat zjednodušené metody Scene BVH v případě potřeby
• dynamika objektů bude řešena vložením daného uzlu/uzlů scény do fronty procesů. Objekty ve frontě budou volány v hlavní smyčce skrze definovaný interface implementující aktualizační metody

Modulární 3D prohlížeč pro Škoda Auto - report 2

Poznámky k plugin architektuře

• automatický import dostupných a platných pluginů
• daný počet typů použitelných pluginů (vstup, archivační, načítací, BVH, ...)
• hlídání verze jednotlivých pluginů pro případ změny jádra
• pouze tam, kde je to bezpodmínečně nutné, bude mít plugin přístup k instanci jádra

Poznámky k návrhu jádra a standardních pluginů

• Scene graph - celý obsažen v jádře z důvodů efektivity a čistšího kódu. V případě potřeby bude možné jej nahradit pluginem se shodným interface.
• BVH plugin - přístup k datům scény. V jádře může být 'dummy bvh' se shodným interface.
• Input/console/GUI plugin - přístup k jádru a všem dostupným metodám
• Renderer - přímý přístup k BVH, metody view frustum culling, pick atd. nad BVH

Další postup

• podrobnější studium dokumentace wxWidgets a otestování podpory pluginů
• zjištění možností reprezentace scény - seznámení s OpenSceneGraph a diplomovou prací Prohlížeč FHS / FHB (M. Schindler), zvážení výhod/nevýhod vlastní implementace
• první verze implementace jádra a správce pluginů
• návrh názvu diplomové práce

Modulární 3D prohlížeč pro Škoda Auto

Vedoucí: Jiří Bittner (bittner [at] fel·cvut·cz)
Externí konzultant: Antonín Míšek (Antonin.Misek [at] skoda-auto.cz)
Řešitel: Václav Kyba (kyba [at] feld·cvut·cz)

Navrhněte a implementujte modulární aplikaci sloužící jako jádro pro zpracování a vizualizaci 3D dat. Aplikace bude mít architekturu využívající pluginy ve formě dynamických knihoven s podporou vícevláknového zpracování. Při návrhu dbejte na možnost běhu na operačních systémech Windows a Linux. K implementaci použijte jazyk ANSI C++ a knihovnu wxWidgets.

Aplikace bude mít následující komponenty:

• datová struktura pro reprezentaci grafu scény včetně tzv. variant (podpora pro reprezentaci několika scén současně, metody pro modifikaci grafu scény)
• flexibilní pluginové rozhraní, jednotná reprezentace a modifikace parametrů pro pluginy
  ovládání pomocí vlastního textového terminálu
• parser příkazové řádky systému
• importní a exportní pluginy formátů FHS a OBJ
• zobrazovací plugin na bázi OpenGL
• plugin pro ovládání kamery

Plán prvních prací na projektu:

• formulace požadavků na pluginové rozhraní
• seznámení s možnostmi knihovny wxWidgets především co se týče podpory pluginů
• v případě nevyhovující funkčnosti wxWidgets nalezení vhodné alternativy s flexibilní pluginovou architekturou
• v nejhorším případě definice požadavků pro vlastní implementaci

TerraD3D v1.10

Version 1.10 of TerraD3D project implementing GPU geometry clipmaps.
Synhtesization and shading changes described in older posts. Many framework changes. There are still some issues as always ;)

TerraD3D report (czech ~3.0MB)
36RSO presentation (czech ~8MB)
Video here (~7.1MB)

TerraD3D v1.10 binary here (~5MB)
TerraD3D v1.10 source here (~49kB)
Doxygen documentation

36RSO Project progress 5

Last 2 weeks

• reconsidered height and normal texture packing due to float precision problem and artifacts on clipmap edges
• textures are now separate, no coarse and fine values packing together. It means more texture lookups but solves many problems - use of A32B32G32R32F and packing height value and normal together could be interesting in the future
• camera speed control and fixed updating when moving too fast (still minor bugs)
• TerraD3D automatically uses noise addition to real height data or synthesizes all the levels with perlin noise according to selected synth_levels variable, which can be set from the console
• perlin noise added for complete terrain synthesization. Terrain is synthesized on GPU
• perlin noise functions are implemented as a GPU shader program - thanks to FilouGK http://filougk.blogspot.com/

36RSO presentation (czech ~8MB)

Video here (~7.1MB)

36RSO Project progress 4

Last 2 weeks

• most of the time spent on correcting the code for new type of clipmaps - synthesized
• synthesized clipmaps are updated using GPU unlike levels updated from heightmap
• synthesized levels smoothly add noise to levels with real height data or synthesize terrain from scratch
• implemented mid-point displacement - easy and fast algorithm with good results. New height values on finer levels are sampled from a randomly generated noise texture. Range for the displacement is always halved on finer level

W/o noise With noise
W/o noise
With noise

Next 2 weeks

• try more complex algorithms for synthesization - perlin noise etc.
• when generating terrain from scratch either use the same algorithm or implement special algorithm only for this purpose
• solve problem with precision limits when packing 2 float height values into one using integral and fractional part in height value textures

36RSO Project progress 3

Last 2 weeks

• implemented 3rd method for shading - using normal maps in vertex shader. VS fetches normal map and sends normal to PS. Probably the fastest solution and results are good. (Final shading comparison will be made after implementation of synthesized terrain)
• studied several methods for terrain synthesizing on GPU (noise or auxiliary function, fractal noise, Perlin noise)
• rewritten clipmap code for height values source other than heightmap. Now it is possible to choose number of synthesized levels that will be added to arbitrary number of heightmap levels (coarse to fine - synthesized levels are finer)

Next 2 weeks

• synthesized terrain prerequisities - prepare textures for noise generation, finest heihtmap level as base texture
• GPU shader program for synthesizing
• try to ensure smooth transition between real and synthesized terrain

36RSO Project progress 2

Last 2 weeks

• revised existing shading
• studied appropriate shading methods for geometry clipmaps
• implemented shading using normal maps computed on GPU (user can change normal map resolution)
• implemented 'on-the-fly' shading on GPU (2 possible ways of normal computation)

Next 2 weeks

• implement supersampled normals using both ways of shading
• try to make on-the-fly shading more effective
• study possible ways of synthesizing terrain on GPU
• modify existing clipmap code to enable reading height values from synthesized source, not only heightmap

TerraD3D Shading 1 (v1.04)

Implemented two different ways of shading - using normal maps and on-the-fly.

Normal maps define one normal per vertex and are computed during clipmap update. Asirvatham and Hoppe use double resolution normal maps but these form undesirable blocks. Normal maps are computed in vertex shader and rendered to a texture, during rendering the pixel shader simply samples the texture and computes a color. Normal maps require the same amount of video memory as height maps (4 times more for double resolution) but provide very fast way of shading.

The second way is to compute normals on-the-fly in vertex shader reading several height samples (currently 4) to obtain a normal, which is then sent through pipeline to pixel shader. No extra memory is needed but vertex texture lookup is still very expensive and framerate drops down to 50% compared to normal maps. It would be interesting to find out if only 2 extra texture lookups can produce similar shading quality.

Normal maps - close

On-the-Fly - close

Normal maps - far

On-the-Fly - far

Normal maps form block artifacts at close views, on-the-fly method provides best results with higher vertex density. Blending both methods could be the way to go (http://www.robertwrose.com/cg/terrain/rose-geoclipmaps.pdf).

TerraD3D v1.04 binary here (~4.5MB)
Shading techniques can be changed in console using clipmap.render_texhnique command with parameter render for normal maps and render1 or render2 for on-the-fly method. clipmap.normal_res_double turns on/off double resolution for normal maps.

36RSO Project progress 1

Last 2 weeks

• studied possible ways of mesh locality optimizations
• implemented own way to generate triangle strips for regular grids (up to 400% higher framerate!)
• compared with nVidia tristrip library (worse results due to the general use of this library)

Next 2 weeks

• study of shading techniques for GPU clipmaps
• revise existing shading and update to valid GPU per-pixel shading using normal maps
• proper normal map update during clipmap shift on GPU
• blend normals near boundary of clipmaps (same way as geometry blending)

36RSO Project assignment

GPU implementation of geometry clipmaps

Student: Václav Kyba kybav1@fel.cvut.cz
Supervisor: Jaroslav Křivánek xkrivanj@fel.cvut.cz

Extend existing geometry clipmap implementation done as a 36SEM project:

• optimize clipmap footprint locality for better vertex cache usage http://research.microsoft.com/~hoppe/tvc.pdf
• compare 3 different ways of shading the terrain - per-vertex (on-the-fly), per-pixel (normal map), blended (combination) http://www.robertwrose.com/cg/terrain/rose-geoclipmaps.pdf (pg.4)
• synthesize fractal detail of finer levels on GPU using appropriate function http://research.microsoft.com/~hoppe/gpugcm.pdf (pg.42) http://research.microsoft.com/~hoppe/geomclipmap.pdf (pg.6) http://wwwcg.in.tum.de/Research/data/Publications/vmv06.pdf
• number of synthesized clipmap levels can vary from 0 (height-map data only) to l-1 (only the coarsest level comes from height-map)

TerraD3D

• school project for 36GS and 36SEM
• C++ Win32 Direct3D application
• terrain LOD algorithm based on geometric clipmaps, mainly on their GPU version
• very effective and promising algorithm for today's graphics hardware
• main aspects described in paper (czech) and presentation (czech)
• binary v1.03 here (~4.5MB)

Buggy 2

• school project for 36ZPG course
• rewritten from scratch but never finished
• quadtree for terrain frustum culling
• logging and simple UI
• source + binary here (~9.2MB)

Buggy

• school project for 36V2B course
• C++ Win32 OpenGL application
• naive algorithm for terrain rendering from height-map
• simple physics, frustum culling and collision detection
• particle system for weather - rain, snow
• source + binary here (~1.1MB)

3D Maze

• school project for 36V1B course
• first 3D attempt - simple Win32 C++ OpenGL application
• go through a maze and find an exit to the next level
• time limited top view for better orientation
• source + binary here (~1.9MB)