Vizualizace je jednou z velice důležitých věcí pro jakéhokoliv architekta, stavebního inženýra, developera a mnohé jiné. Často si to neuvědomujeme, ale jde o pomyslný most mezi zákazníkem a vaším návrhem. Zákazníkovi nebo investorovi není možné dát plány a počítat s tím, že jim porozumí a že si představí, jak bude návrh vypadat. Zákazník ani nemusí nutně vidět ze hmotové studie ve 3D, jak bude prostor vypadat a jestli je pro něj vhodný, nebo ne. Čím je tudíž pro něj prezentace lépe připravena, tím lépe i pro vás jako prodejce myšlenky.
Samozřejmě je jistá hranice, kdy už se vám vynaložený čas nevyplatí, zákazník nevidí takové detaily. Dokonce se může míjet snaha „grafika“ s pochopením vizualizace zákazníkem. Tak jako zákazník nedokáže přečíst plán, nedokáže přečíst, ani kolik práce bylo za perfektně zvládnutou vizualizací, kterou nerozezná od fotografie.
Vizualizace a vizualizační software se zdánlivě také míjí. Zatím co vizualizace, především když přihlédneme k těm architektonickým, se snaží být abstraktnější, hyper-realističtější a lákavější pro zákazníka, software na vizualizování je staticky jednoduchý „kostkový“ podklad pro další úpravy v Photoshopu nebo Gimpu, nebo naopak extrémně náročný na uchopení. Druhý typ produkuje velice realistické scény za cenu několikaleté praxe. Nicméně to je spíš hudba minulosti. Od přelomu tisíciletí se vyvíjí programy především v několika směrech, z nich se podíváme na ty hlavní.
Optimalizace rendrování
Prvním směrem je snaha optimalizovat již zaběhnutý způsob rendrování, zde je ale již většina programů – aspoň zdánlivě – na samé hranici toho, co lze zdokonalit.To platí pro programy založené na CPU (central processing unit) výpočtech, a to minimálně posledních pár let, bavíme-li se ovšem o programech založených na využití GPU (graphic processing unit), zde jsou zatím velké možnosti k vývoji a k objevování. Optimalizace CPU výpočtů je již po několik let natolik složitá a s minimálními výsledky, že vývojáři těchto vizualizačních a renderovacích nástrojů s radostí zareagovali na vývoj v oblasti CUDA jader (grafická jádra simulující výpočty jader procesorových) a alternativy od AMD. Tato technologie přináší výsledky, nicméně nejsou tak zázračné, jak by se mohlo myslet.
Je třeba si uvědomit, že 1 jádro CUDA se nerovná jednomu jádru procesoru. Jeho náhradu zabere mnohem více CUDA jader. Uvádí se poměr okolo 1:48. Co je ale důležité, záleží zásadní měrou na optimalizaci programu. V praxi tak vidíte, že program běží lépe s grafickou kartou herní než s „profesionální“. Tuto podporu a optimalizaci pro CUDA jádra klasické CAD aplikace se stavebním zaměřením totiž téměř nenabízejí (více v dalším článku na téma grafické karty a stavební SW) – i když je opak mnohdy uveden na stránkách distributorů apod. – a vyplatí se tak volit pro tyto aplikace radši karty herní. Ty svým výkonem – neustále vylepšovaným díky hernímu průmyslu – lehce předběhnou specializované karty „profesionální“ v drtivé většině případů úkonů a CAD aplikací. Uvědomme si, že pokud CAD program a kartu správně nepropojíte, řeší „jen“ otázku zobrazení obsahu 3D a vykreslování 2D, což zvládá lépe karta herní. To také za neporovnatelně méně peněz, což je ale zřejmě důvod, proč se stále ještě doporučují ke stavebnímu SW karty „profesionální“. To stejné platí i pro různé vizualizační podprogramy, jež CAD aplikace obsahují. Existují i vizualizační programy (samostatné), jež jsou optimalizované pro CUDA jádra a dovolují tak rychlejší render. Nicméně stále je z uvedených možností nejrychlejší a nejefektivnější využít grafické výpočty, tzn. grafickou kartu herní a nějaký engine.
Tak nebo onak, stále jde o výpočty negrafického rázu. V tomto mají programy běžící přes GPU velkou výhodu, dokážou využít celou kapacitu grafické karty. Optimalizace zde probíhá na úrovni lepší kompatibility grafické karty s prostředím programu, což následně dovoluje i přesvědčivější výsledky. Celkově se tedy zdá, že optimalizace má nejmenší potenciál u CPU programů a největší, když běží přes GPU. Na druhou stranu GPU programy, které jsou schopny produkovat opravdu realistické nebo zajímavé výstupy, jsou až na světlé výjimky poměrně složité, a uživatel tak musí být profesionál.
Zlepšování kvality renderu
Druhým směrem je zlepšování kvality finálního renderu. To, co bylo před pár lety nemyslitelné, je dnes dosažitelné a méně odbornou veřejností považováno za standard. To je způsobeno celkovým vlivem grafiky – jak herní a filmové, tak i prezentací stavebních projektů a grafickým designem obecně. Tady je ale problém nastíněný v prvním odstavci. Jakmile trávíte hodiny modelováním bublinek do šampaňského, nikdo vaši práci nejspíše neocení a pravděpodobně ani nezaplatí. Stejně tak to může být s nastavováním materiálů apod. Naopak může mít takto zpracovaná scéna efekt opačný, než jste chtěli, zákazník z ní nepozná, že nejde o fotografii, a tudíž něco zvláštního (za co by měl platit tisíce korun). To je ale věčný souboj vynaložených prostředků a výsledku. Také souboj uměleckého a realistického renderu.
Zjednodušení ovládání
Třetím je zjednodušení pro uživatele. V době, kdy se vše zjednodušuje kvůli uživatelům a jejich nevoli učit se něco nového, je jedním z mála pozitivních rysů tohoto zjednodušování i zjednodušení ovládání grafických programů. Mnoho programátorů si totiž neuvědomovalo, že více neznamená lépe, a tak do programů přidávali další a další možnosti, ale vzhledem k finálnímu výsledku tak mohlo být na jednu viditelnou věc ve výsledku hned několik různých funkcí, tlačítek a posuvníků. Nynější trend je jasný, na jednu viditelnou věc jeden posuvník.
To je velice složité a v podstatě jen relativně nové programy toto začaly aplikovat v pravém slova smyslu. Stejně tak jako realtime zobrazení (i když tento pojem existuje již poměrně dlouhou dobu a je z dnešního hlediska již téměř nepochopitelné, jak byl aplikován), kdy vidíte výsledek hned při tvorbě. To vám podstatně zjednoduší práci díky vynechání pokusných renderů. Také například práce s texturami se velice zjednodušila, programy mají jednodušší prostředí pro mapování textur a dokážou generovat automaticky například i normálové mapy na základě derivace barevných rozdílů ploch.
Postprodukce v 3D prostředí
Dalším trendem souvisejícím se zjednodušením je přesun postprodukce do 3D prostředí. Máte tu tak k dispozici kromě klasického zaostření a práce s barevnou korekcí i různé možnosti barevných filtrů, uměleckých stylů, přepínání vrstev apod. To je užitečné především při prvních fázích konzultací, a pokud chcete udělat v projektu změnu. Můžete tak například plynule a jednoduše přejít od hmotové prezentace zákazníkovi ve formě například „polystyrénového modelu“ do (hyper)realistického zobrazení finálního výstupu.
To vše v důsledku dovolí uživatelům to, čeho se museli před cca 20 lety vzdát kvůli složitosti grafických programů. Mohou nyní opět pracovat ve svém oboru, tvořit 3D a tvořit si i vizualizace. Nemusí je tak zadávat, protože forma zjednodušení dospěla tak daleko, že v nových programech můžete tvořit – třeba i díky náhledu v reálném čase – natolik jednoduše, že to zvládnete bez pomoci specialisty grafika.
Rychlé výstupy
Poslední věcí je doba renderu, zde je z již zmíněného jasné, že jsou na tom nejlépe GPU programy, ty dokážou dělat průběžný render třeba 60krát za vteřinu a finální obrázek se vším všudy se místo několika hodin rendruje několik vteřin. Můžete tak jednoduše dosáhnout i na videovýstupy ve fullHD anebo panoramatické snímky, virtuální realitu a další formy prezentací. Tyto výstupy jsou jinak se staršími typy programů nemyslitelné nebo jen s velmi drahými počítači, rendrováním na cloudu apod. Optimalizovaný program využívající grafickou kartu jako primární výpočetní prostředek navíc dokáže rendrovat a u toho nezaměstná zbytek PC, můžete tak například dělat dál v některé vaší CAD aplikaci, nebo jenom odepisovat na maily apod.
Programy, jichž se tento článek týkal
Vybrané CPU programy (některé s určitou podporou CUDA): 3DS MAX, Blender, Maya, Cinema 4D, Rhinoceros, Sketchup, Softimage, Massive, TrueSpace a Golaem Crowd, Corona render, V-ray, Octane render, ...
Vybrané GPU programy: Lumion, Unreal engine, Unity, Twinmotion, Lumen RT.