Generování lightmap - AO

[mar]

Tak, přidal jsem verzi 1.4

opravil jsem ještě dva drobné bugy (hlavně 1px obal clusterů - lightmapy teď vypadají zhruba tak, jak jsem si představoval)
a přidal jsem úpravu rotace, aby se clustery líp vešly do obdélníku
(můj lightmapper používá rectangle packing, s tím, že umí do určité míry využít nevyužité části clusteru)
Výsledek by měl být mnohem lepší packování u šikmých clusterů a zároveň zmenšení využití paměti pro výpočet.

Na nějakou dobu mi lightmapy stačily, časem bych rád ještě nadobro vyřešil švy, ale není to triviální a prozatím odsouvám na neurčito

[VODA]

Paráda, integrováno, otestováno.

Jediná věc, která trochu bije do očí jsou ty POT textury. Původně jsem myslel, že jen "přidáš" chybějící pixely do již stávajících lightmapy a přepočítáš uv souřadnice, tím by se tedy zbytečně neplýtvalo pixelama. Jak jsem psal, např. pro 104x80 by byl výsledek 128x128, pozice pixelů zachována, jen by se textura rozšířila o 24x48.
Teď jsou všechny textury maximální velikostí a tady to plýtvání podle mě už nastává.

Myslíš, že by bylo těžké udělat to tak, jak jsem navrhoval prvně? Že bys dopočítal nejbližší vyšší POT rozměry, dodal pixely (rozšířil texturu) a přepočítal souřadnice? Ale už Tě nechci otravovat. Už jsi udělal spousty práce a nic sis za to neřekl...

(Jako, asi bych si to zvládl upravit už sám u sebe v enginu, ale přeci jenom, když už to bude umět AOGen sám, bude to odolněší proti budoucím úpravám).
_________________
Opravdovost se pojí s trýzní...

[mar]

No to bude možná tím, že tam byl bug, jak jsem to psal narychlo
Před opravou (uploadnul jsem) mi to např. generovalo na malém testovacím modelu 256x256, teď správně 256x128.

Nebo tím plýtváním myslíš, že to teď není nahuštěné v levém horním rohu? Nebo kvůli cache/kompresi? Každopádně zkus tu opravenou verzi
(pokud NPOT udělá 104x80, POT by měl být 128x128)

Samozřejmě co říkáš by šlo bez problémů, ale já jsem to udělal tak, aby to zároveň zkrátilo build time.

Ale pokud opravdu nechceš plýtvat, pak doporučuji NPOT (nebo to aspoň změř na min target hw, jaký je tam reálný performance hit).

[mar]

Hmm, tak jsem trochu hledal nějaké info o tom, jak kvalitní je podpora NPOT textur na různém hw a přesvědčilo mě to, abych NPOT nepoužíval...

Uploadnul jsem verzi 1.5
Takže jsem to teď změnil tak, jak jsi navrhoval (plus korektní rescale + offset), to je teď default.
Přidal jsem parametr -N, který dělá NPOT výstup jako předchozí verze.
Parametr -2 zůstal, ten se chová tak, jak jsem původně implementoval POT packing, takže ti ho stačí jednoduše odstranit.

[Spytihněv]

[mar]

Určitě

https://www.khronos.org/opengl/wiki/NPOT_Texture

http://gamedev.stackexchange.com/questions/7927/should-i-use-textures-not-sized-to-a-power-of-2

V tom druhém linku někdo dokonce tvrdí, že se interně zarovná na nejbližší POT velikost; nevím, jak moc se tomu dá věřit

Dost pochybuji, že tomu tak je, protože tomu hned odporuje jeho druhý bod ohledně poklesu výkonu (odkud by se vzal).

Na druhou stranu si umím představit, že by to někdo tímhle způsobem obešel v driveru na HW, který NPOT nepodporuje.

[VODA]

[VODA]

v1.5 funguje přesně jak jsem čekal. Paráda mare!
_________________
Opravdovost se pojí s trýzní...

[Spytihněv]

mar> že to vyžadují staré karty (první link) není pochyb (ale Sollertia sama o sobě používá OGL3). Druhý link je diskuse z roku 2011. Říkám si například, že je úplně běžné kreslit do textury o rozlišení okna.

Já v současném projektu hned od začátku POT zavrhl (právě kvůli plýtvání), kdy mám třeba loď v 800x800, protože 512 nestačí, ale 1024 by bylo zbytečně moc. Kdyby mě teď někdo zviklal na POT, musel bych předělat asi 300 textur a to bych se šel raději bodnout

[mar]

Nechci zbytečně plašit, taky si myslím, že na moderním hw to nebude problém, navíc texture render targety by měly fungovat s NPOT.

(jinak pokud nepotřebuješ mipmapy, dal by se z toho udělat atlas)

VODA: super, teď už jenom někdy do budoucna vyřešit švy a zoptimalizovat rychlost rectangle packeru a budu s tím spokojený

[VODA]

Napadlo mě ještě takové malé zlepšení. Někdy by se mi hodilo, aby nějaký objekt nevrhal stín, jenom ho přijímal.
Myslíš mare, že by šel udělat nějaký blacklist objektů (podle jména z obj), se kterými by se nekolidovalo? Mohl by to být jednoduchý volitelný soubor, na každém řádku jméno objektu.
Může se to hodit např. pro decaly na zemi. Praskliny, cákance od krve, atp.
_________________
Opravdovost se pojí s trýzní...

[mar]

Pokud by stačilo z o nebo g tagu, tak by to neměl být problém.

[mar]

V1.6, přidal jsem parametr -x <filename>
je to pak blacklist názvů objektů (nebo groups, object tag má prioritu)
snad by to mohlo fungovat tak, jak potřebuješ. moc jsem to ale netestoval

ještě poznámka: takto otagované objekty nebudou přijímat AO ani samy od sebe

[VODA]

Super!
Jdu to otestovat.
_________________
Opravdovost se pojí s trýzní...

[VODA]

Tak funguje to perfektně. Opravdu moc děkuji.
Už bych asi měl dodělat načítání/renderování scén v enginu, abych mohl začít ukazovat nějaké reálné výsledky (no a pochopitelně musím vymodelovat nějakou hezkou testovací scénu).
_________________
Opravdovost se pojí s trýzní...