Generování lightmap - AO

[VODA]

Ok, tak jsem to pochopil správně.

Ty jo, to je tak super, když to takhle hezky funguje. Já už nad AO v lightmapách přemýšlel od doby, co jsem zjistil, že je má takhle Diablo 3. Nejprve mi stačilo to vertexové osvětlení, ale teselace musela být někde docela brutální a hlavně... muselo se to řešit ručně.

Tohohle bych chtěl dosáhnout (plus mínus):
https://www.flickr.com/photos/67894300@N05/6196260123/
_________________
Opravdovost se pojí s trýzní...

[mar]

Převapuje mě, že mají taky celkem velký šum (resp. málo samplů), ale ve finálním osvětlení to není vůbec poznat.
Pro finální buildy můžeš zkusit víc samplů, co jsem zkoušel tak 256 stačí a s blurem se pak šum prakticky úplně eliminuje - ale zase blur zvýrazňuje seamy.

Jinak mají buď lepší automatický clustering, nebo ručně generovaný unwrap pro lightmapy, že jim to tak sedí.

Nevím, jestli finální verze bude tak dobrá, ale určitě to chci ještě poladit.
K dokonalosti to má ještě daleko.

Ono teď je zatím výhoda, že ten vysoký detail lightmap celkem redukuje seamy, když se sníží, tak to začne být mnohem větší problém.
Další problém lightmap je, že seberou dost místa, ale na druhou stranu na AO stačí jeden kanál.

A navíc zapékat AO místo celého statického osvětlení další výhodu, a to tu, že je stejné pro celý mesh bez ohledu na počet instancí,
takže možná to půjde pak takhle vyřešit a tím pádem mít zhruba kontrolu nad detailem, no upřímně jsem dost zvědavý, jak to nakonec bude vypadat.

[mar]

Můžeš zkusit další verzi (1.2). Opravil jsem jeden bug a přidal jsem další parametr,
-k n (blur kernel size override)
Jediná zajímavá hodnota je asi -k 3

Jinak u mě s tím ty teapoty teď vypadají takhle (256 samples):

[micky]

Wow, paráda, pánové. Jak dlouho trvá to generování mapy?
_________________
https://www.bluepulsar.cz/
https://twitter.com/11thDream_Game/

[mar]

To záleží na vstupní geometrii, detailu lightmapy, počtu samplů atd. Třeba ty teapoty myslím trvají cca 20 vteřin (z hlavy nevím), u větších scén by to mohlo být v řádu minut.

Pokud ti ujede ruka a naimportuješ třeba model ve špatném měřítku (v cm místo m), tak to může trvat i hodiny (pokud dřív nedoje paměť).

[VODA]

Tak verze 1.2 funguje parádně a dá se říci, že problémy se švy už prakticky nemám.
Ještě trocha práce a budu moci scény renderovat v enginu.
_________________
Opravdovost se pojí s trýzní...

[mar]

Super Jsem moc zvědavý na výsledek

[VODA]

To já jsem také zvědavý. Je pravda, že žádnou "typickou" scénu jsem ještě počítat nezkoušel. Ale zkusím nějakou vyrobit.
_________________
Opravdovost se pojí s trýzní...

[VODA]

Měl bych ještě jednu věc, kterou bys mohl vylepšit. AOGen by mohl mít flag, který by programu řekl, aby vyráběl výsledné textury vždy s rozměry mocniny dvou.
Neměl by to být ale rescale. Pouze by se měly doplnit černé pixely a přepočítat texturové souřadnice.

Důvod je takový, že pro malé meshe mi vypadne textura např. o velikosti 104x80. Engine si provede při načítání rescale na 128x128, tím pádem natáhne pixely textury a sem tam to může působit nekonzistentně.

Ale to jen kdybys na to měl čas. Není to nutnost.
_________________
Opravdovost se pojí s trýzní...

[mar]

To by neměl být problém, jenom se zeptám proč trváš na mocninách dvojky?
Stejně tam dáš clamp to edge a NPOT v takovém případě umí i GLES2 hardware (tedy i starší mobily).
Já jsem se nakonec rozhodl pro NPOT kvůli ušetření místa, proč plýtvat.

Ale klidně to tam přidám, jenom doufám, že ti nebude vadit, že to nebude čtvercové, tam se pak plýtvá už hodně (třeba 256x128 by snad mohlo být ok).
Stejně jsem chtěl ještě upravit přesnost na 6 desetinných míst, hlavně u generovaných uv, nevím, jestli 4 jsou dost.

EDIT: stejně to je NPOT dělitelný osmi

[VODA]

Kdysi nám ve škole pet říkal, že i v dnešních dobách je samplování textur rychlejší, když jejich rozměry jsou mocniny dvou.
A hlavně, jak jsem psal, engine mi to automaticky konvertuje na mocniny dvou a chci se vyvarovat deformaci pixelů v textuře.

Rozhodně to nemusí být čtvercové textury. Myslel jsem to přesně tak, jak píšeš. Např. 200x80 pak bude mít po úpravě 256x128.
Přesnost uv coordinát je v tuto chvíli dostačující. Alespoň jsem si nevšiml žádné chyby.

Ale rozhodně to není nutná úprava, to jen kdyby se Ti chtělo.
Třeba to roztahování nakonec v enginu ani nebude poznat.
_________________
Opravdovost se pojí s trýzní...

[mar]

Rozdíl ve výkonu jsem neměřil, určitě logicky samplování POT textur by mělo být rychlejší, ale je otázka, jaký tam je reálný rozdíl na HW, hádám zanedbatelný.

Pokud tě netrápí to, že třeba kdyby se atlas vešel do 2048x1032, ale z důvodu POT omezení prakticky vyplýtváš 2Mtx, tak ok

Přidat to bude triviální a navíc to výrazně urychlí poslední krok při optimalizaci atlasu.

[VODA]

[mar]

Ok, uploadnul jsem verzi 1.3 (stejný link)

exportuje se teď všechno na 6 desetinných míst

přidal jsem parametr -2, který pak dělá POT atlasy

pokud jsou v obj vertex normály, tak se použijí. netestoval jsem, jestli to funguje dobře,
pokud ne, parametr -n vynutí automatický přepočet normál (jako předtím)

[VODA]

Ty jo, paráda, jsi neskutečně rychlej. Jdu to testnout.
Díky!
_________________
Opravdovost se pojí s trýzní...