'Gametextures tot zeventig procent kleiner'

Op de London Games Developers Conference heeft het bedrijf Allegorithmic software gepresenteerd waarmee de grootte van gametextures zeer fors kan worden gereduceerd. Het zogeheten ProFX-programma maakt gebruik van een techniek die 'procedural texturing' wordt genoemd, en waarmee textures zonder kwaliteitsverlies zeventig procent kleiner gemaakt kunnen worden. De officiële site rept zelfs van een compressieverhouding van 1:300. De technologie is met name bruikbaar voor spellen die online worden aangeboden, omdat de gamegraphics een belangrijk deel van de downloadtijd voor hun rekening nemen. Ook de laadtijden van spellen zouden dankzij ProFX verkort kunnen worden; de makers claimen dat het opbouwen van textures met hun software sneller gaat dan het uitlezen van ongecomprimeerde graphics van 'courante' harde schijven.

Het compressiesysteem werd gedemonstreerd met behulp van de game Roboblitz. Dit spel, dat op de Unreal 3-engine draait, mocht niet groter dan 50MB zijn om via Xbox Live Arcade verspreid te worden. De ProFX-auteurs slaagden daar naar eigen zeggen probleemloos in: de 80MB aan textures die voor het eerste level van het spel nodig zijn, werden in vier seconden gegenereerd met behulp van een bestand van slechts 280KB. Op de vraag waarom niet iedereen van deze software gebruik maakt, liet woordvoerder Sébastien Deguy weten dat ProFX-editor MapZone niet al te eenvoudig in het gebruik is, maar diverse scholingsprogramma's moeten dat probleem verhelpen. Volgens Deguy is het dan ook een kwestie van tijd voordat de grote gamestudio's zijn product in gebruik nemen. De Allegorithmic-software is beschikbaar voor Xbox- en Windows-games; ondersteuning voor de PlayStation 3 komt 'binnenkort' op de markt.

Reacties (122)

[Ooyevaar]

Was dit er vroeger ook al niet ? S3 had toch al een "texture compression" zodat je met minder videogeheugen ook al hele mooie plaatjes kon krijgen in je games. UT was daar een voorbeeld van met speciale drivers.
Althans ... dat staat mij bij

[.oisyn]

Dat is idd echte (lossy) compression waarbij een blokje van 2x2 of 4x4 pixels worden opgedeeld in kleinere data. De hardware kan deze compressie in real-time uitpakken tijdens het renderen.

Wat hier besproken wordt is eigenlijk helemaal geen compressie. In plaats van een array van pixels op te slaan, wordt nu opgeslagen hoe die texture tot stand is gekomen. Een "teken lijn van (1, 1) naar (54, 63) met kleur (255, 0, 0)" commando kost bijvoorbeeld veel minder data dan het uiteindelijke plaatje.

Het nadeel is wel dat de textures echt met dit programma gemaakt moeten worden - het is niet mogelijk om bestaande textures met deze techniek te "comprimeren". Daarnaast mag het duidelijk zijn dat je met ongecomprimeerde textures een stuk meer vrijheid hebt, niet alles is nou eenmaal efficient te beschrijven met commando's en formules

Bij de claim

makers claimen dat het opbouwen van textures met hun software sneller gaat dan het uitlezen van ongecomprimeerde graphics van 'courante' harde schijven

heb ik echter sterk mijn twijfels, en ik vraag me af hoe ze dat gemeten hebben. Het duurt wellicht langer om de data van disk te halen dan zelf die textures op de CPU te genereren, maar ze vergeten daarbij voor het gemak even het feit dat data lezen van disk parallel loopt aan de CPU. Je kunt dus een leescommando geven en verder je ding doen, en zodra de data binnen is daar gebruik van maken. Deze manier is ideaal voor streaming content, omdat het game gewoon door kan lopen terwijl de data langzaam binnenkomt. Ik vraag me af of deze techniek nog steeds nuttig blijkt in een game als san andreas waar gigantisch veel real-time gestreamed wordt - volgens mij zorgt het berekenen van de textures uiteindelijk alleen maar voor extra stalls.

Wat natuurlijk wel handig is is dat de data maar één keer omgezet hoeft te worden, zodat het voornamelijk voordelig is voor downloads - je download minder data, maar bij de install of het eerste keer runnen van je game worden de textures uitgepakt en weggeschreven naar disk.

[Verwijderd]

Wat hier besproken wordt is eigenlijk helemaal geen compressie, maar puur een andere manier om de data te beschrijven:

Zover ik weet is compressie een andere manier van data beschrijven.

[.oisyn]

Daar heb je helemaal gelijk in, ik heb de zin weggehaald

[Kurgan]

Bij de claim
makers claimen dat het opbouwen van textures met hun software sneller gaat dan het uitlezen van ongecomprimeerde graphics van 'courante' harde schijven
heb ik echter sterk mijn twijfels, en ik vraag me af hoe ze dat gemeten hebben. Het duurt wellicht langer om de data van disk te halen dan zelf die textures op de CPU te genereren

Wat ik niet uit de site kan halen is waar het proces van het opbouwen van de textures plaatsvindt, doet de CPU dat of de GPU? In het laatste geval kan ik me voorstellen dat het razendsnel gaat, sneller dan inlezen vanaf de HD - uiteraard wel ten koste van je framerate. Je kaart kan immers niet tegelijk renderen en decoderen.Dan heb je weer veel voordeel van Crossfire / SLI. Hoe dan ook, het is goed dat er bedrijven zijn die eens op een andere manier naar het gebruik van textures kijken, we accepteren immers allemaal dat meer detail en realisme ook meer opslagruimte vereist, maar dat hoeft dus helemaal niet zo te zijn.

[Verwijderd]

Het duurt wellicht langer om de data van disk te halen dan zelf die textures op de CPU te genereren, maar ze vergeten daarbij voor het gemak even het feit dat data lezen van disk parallel loopt aan de CPU. Je kunt dus een leescommando geven en verder je ding doen, en zodra de data binnen is daar gebruik van maken

Bij SCSI schijven of bij de S-ATA schijven met commandqueue-tagging zoals de WD Raptor wel ja. Normale IDE schijfjes belasten de processor toch echt nog steeds hoor door deze met interrupts te bestoken. SCSI en Raptors vallen overigens zeker niet onder de noemer 'courante' schijven; het moge duidelijk zijn waarom

Overigens, het is natuurlijk allemaal verkooppraat en als tegenargument voor de PS3/XBox360 en PC's kunnen we melden dat we binnenkort Blu-Ray of HD-DVD hebben en dus ook ruimte genoeg voor opslag. Voor online games heeft meneer wel een goed punt maar is die markt niet erg klein?

[Iblies]

Volgens de claim duurt het uitpakken maar enkele seconden,
toch een stuk sneller dan van een cd-rom of alles raw van de harde schijf lezen.

Verder kun je besparen op kosten,
een dvd kost duurder dan een cd-rom. Eentje is weer goedkoper dan twee.
Detail, maar in dergelijke oplages telt het wel even.

Daarnaast wordt steeds vaker de mogelijkheid geboden om via internet extra levels te downloaden, of zelfs complete episodes.
Jan met de pet op is denk ik blijer met een bestand van 50 MB die op een 2Mb lijntje enkele minuten duurt dan een bestand van enkele 100den MB wat weer minimaal een kwartier duurt. Ook kost het gewoon minder GB, klinkt ook onnozel,
maar het komt geregeld voor dat spellen legaal mbv bittorrent worden verspreid omdat de bandbreedte niet alleen ontoereikend is, het kost ook gewoon geld.

[.oisyn]

Wat ik bedoel is dat "leescommando geven, wachten op data, iets doen met die data, voer onafhankelijke operatie X uit" langer duurt dan "leescommando geven, voer onafhankelijke operatie X uit". Natuurlijk kost lezen van disk tijd, maar het is heel goed te parallelliseren, ookal krijg je tussendoor interrupts.

[Reinstein]

toch denk ik dat dit wel degelijk sneller is, de meeste games hebben straks een dualcore cpu, en een 10000rpm s-ata schijf als het mee zit. Als je dan maar 280KB ipv 80MB van je disk moet lezen dat scheelt een heet stuk tijd. Je CPU maakt dat makkelijk goed.

[.oisyn]

Volgens de claim duurt het uitpakken maar enkele seconden

Als je niets aan het doen bent ja. Tijdens het laden wel mooi, maar voor streaming data geen optie . Overigens vond ik het 2e CPU argument wel een goede, die staat nu vaak ongebruikt te zijn en kan daar uitstekend voor ingezet worden.

[Dragunov]

Markt groeit wel

EA Downloader
Steam

Beide programma's bieden toch ook al enorm grote games aan

[DaCoTa]

Kost duurder? Het is duurder of iets kost meer...
(Reactie op lblies)

[Ikke_Niels]

@lblies
kost meer of is duurder

[EfBe]

@.oisyn:
Het is inderdaad efficienter doordat je ongebruikte core(s) gebruikt voor het berekenen van die textures. DVD/BR is toch relatief traag mbt het ophoesten van grote blokken data, en je kunt zo dus meer parallel doen.

Ik moet er wel bij zeggen dat het er wel vanaf hangt wat voor textures je maakt. Hoe meer bewerkingen voor 1 texture, hoe trager (duh) en ik denk dan ook dat er een 'sweet spot' zit tot wanneer je kunt gaan met hun systeem.

Het is wel nuttig in games waarbij in grote werelden toch veel content gedistribueerd moet worden, en dit is ook de reden waarom in Spore ze deze technieken gaan gebruiken (ook voor models). Weet niet zeker of ze de Farbrausch boys' code hebben ingekocht daarvoor, wel dat ze duitsers daarvoor hadden ingehuurd, lijkt me dat er niet zoveel zijn naast Farbrausch die dit tot in de finesses beheersen.

[Verwijderd]

Dat klopt ook dat uitpakken (precalcen eigenlijk),bekijk maar eens die 64K dingen die er mee gemaakt zijn. Die staan eerst een forse tijd de textures (en volgens mij ook de muziek) te calcen en naar een temp dir te zetten al voor ze starten. Maar goed bij downloadable content zou je er dus voor kunnen kiezen het zo te maken dat er 1 keer gedownload en gecalculeerd wordt om vervolgens die data gewoon offline op een lokale schijf te cachen. (gooit de gebruiker die data toch weg, niks aan het handje calculeer je het toch gewoon nog een keertje )

[Rafe]

Texture compression bestaat idd al een hele tijd en de technologie van S3 is vanaf versie 6.0 meegenomen in DirectX.

Als ik het goed begrijp werkt de software van Allegorithmic anders, in plaats van een kant-en-klare texture laden wordt het bouwplan voor de texture geladen en wordt de texture dan in elkaar gezet. Beetje het Ikea-idee, een handleiding en onderdelen in een doos nemen ook minder ruimte in dan een al in elkaar gezette kast

[Verwijderd]

Dit is compleet anders.

In plaats van dat je vroeger bijvoorbeeld een grasmat maakte door het in photoshop te tekenen, wordt het hier in termen van functies opgebouwd. Bijv. (groen + noise) * motion_blur. Geeft meteen aan waarom het nog niet veel wordt toegepast; het is véél lastiger om een kwalitatief hoge texture te maken met procedures dan tekenen met pixels.

Dit soort tools bestonden al járen. In de allereerste 3D films (tijdperk van Tron) was procedural zelfs de énige manier, aangezien textures gewoon te groot waren om te verwerken door de computers van toen. En zowat elk rendering programma heeft ook procedural textures.

Nog voor de eerste shaders op GFX kaarten bestonden probeerde men dit soort tools al aan de gamedevelopers te slijten. Je kan zelf het daverende succes tot nog toe bepalen Ik heb dan ook mijn twijfels of het dit bedrijf wél gaat lukken.

[simen]

ik denk dat ze het met hun marketingpraat wel halen.

maargoed, het blijft wel lastig om op deze manier textures te maken, photoshop is toch een stuk makkelijker.
dat is argument 1, en ten tweede is dit *slechts* een manier om dingen kleiner op te slaan, het zal zeker weten ten koste gaan van de laadtijden(ze kunnen de pot op met hun verhaal over leestijden) en eens geladen kost het alsnog gigantisch veel videogeheugen.

aan de andere kant geldt ook het kudde-effect voor developers. en zeker aangezien er nu een game gemaakt word met UE3 en deze techniek zullen meerderen het nut inzien.

[J.J.J. Bokma]

"In plaats van dat je vroeger bijvoorbeeld een grasmat maakte door het in photoshop te tekenen, wordt het hier in termen van functies opgebouwd."

Procedureel textures maken is niet nieuw. Sla een Foley, van Dam et al: Computer Graphics, Principles and Practice maar eens open, en presto. Probleem was dat vroeguh de computers niet snel genoeg waren om het allemaal mooi te doen.

[ultimasnake]

Klopt en ook direct x enzo hebben compressed textures natuurlijk.. maar dit is gewoon weer een stap verder in de techniek

[Verwijderd]

Ja zo ken ik er nog een paar. Hoe kun je dit nou compressie noemen? Met deze logica is een midi file ook gecomprimeerde muziek.

[mcdronkz]

Link naar RoboBlitz

http://www.roboblitz.com/site.html

[justice strike]

een demo naar een fps gebaseerd op dezelfde technologie (hij is maar 97kb dus een moeite om het de downloaden is het niet )

http://kk.kema.at/files/kkrieger-beta.zip

homepage:

http://www.theprodukkt.com/home

[knirfie244]

Ik betwijfel of dat dezelfde techniek is hoor, Farbrausch maakt meestal gebruik van textures die eigenlijk uit hele simpele formules gegenereerd kunnen worden. Zij kunnen niet zo maar elke willekeurige texture ff comprimeren met zulke ratio's...


Maar wat ik me dan af vraag, kan dit ook voor foto's en andere plaatjes gebruikt worden?

[simen]

neen!

het is hetzelfde als .product
deze textures zijn ook niets meer dan formules en dit werkt dus ook niet met willekeurige bitmaps.

[EfBe]

Ah, ik had al zo'n vermoeden dat dit alles bekend voorkwam, maar het zijn de oude Farbrausch jongens Wel leuk om te zien dat na al die jaren Ryg en Chaos hun werk nog steeds mensen versteld doet staan

Overigens zijn onderdelen van de game Spore ook gebaseerd op zaken die Farbrausch en andere demosceners vroeger al gebruikten: niet alleen procedural textures maar ook models op basis van formules en operatie definities.

[Verwijderd]

Ach so, het is idd wel erg werkkzeug1 en dan hebben ze idd gelijk dat het niet echt laag drempelig is. Als je denkt dat je even een demol in elkaar flanst met die tool kom je van een aardig kouwe kermis thuis.

Maar man, wat hebben die gasten mooie dingen in 64Kb weten te frotten..

(alhoewel deze fairlight 64Kb er ook best mag zijn.!)

[plofkip]

Dat ding vreet 300 MB Ram

[C00P]

Haalt alle textures uit directx heb ik me laten vertellen vroeger ?

[Hightree2k]

Allemaal geweldig die compressie verhoudingen, maar je kunt met dit prog niet meer gebruik maken van foto's als bronmateriaal voor texturing.
Tevens kun je de photoshoppers uit je gamedev team schoppen, want er wordt niks gepaint met deze technologie.
Alles moet procedureel in elkaar gedraaid worden.
Daar heb je dus een heel andere skill-set voor nodig, mensen met meer technische kennis dan alleen painten.

[MetalStef]

Geweldig, die compressieverhoudingen! Hoewel je inderdaad niet dezelfde fantastiche scores behaalde met textures uit fotomateriaal, kun je je real-time gerenderde textures wel heel veel fijner maken:

Stel je een betonnen muur voor (niet een heel zeldzaam soort texture bij games). Bij de huidige techniek wordt gebruik gemaakt van een texture die verkleind wordt naar behoefte, in verschillende niveaus (mipmapping). Een muur in de verte gebruikt dus dezelfde texture als een muur dichtbij, maar dan verkleind. Dat is zonde, omdat je voor een paar pixels op een grote afstand wel een hele texture moet verstouwen.

Diezelfde muur heel dichtbij gebruikt dezelfde texture, maar omdat je zo dichtbij staat, komt hij blokkerig op je scherm.

Als nu die muur real-time gerenderd wordt met een bepaald algoritme, is voor de muur op afstand maar heel weinig detail nodig. Je haalt het (heel kleine stukje) beton-algoritme op en slaat aan het rekenen. Je bent dus snel klaar met het plakken van de texture.
Voor de muur dichtbij neem je hetzelfde kleine algoritme, en rekent er lustig op los, totdat er een zeer fijn gedetailleerd stuk beton op je scherm staat. Die extra rekentijd heb je over omdat je nou eenmaal minder andere dingen hoeft te renderen. Ze zijn immers toch niet zichtbaar zolang jij met je neus tegen de muur staat.

Dus behalve dat je minder ruwe data hoeft te verwerken, zullen je games er ook nog eens veel beter uit gaan zien!

[.oisyn]

Leuk idee, maar niet erg bruikbaar omdat er vaak zowel een muur dichtbij als een muur ver weg getoond wordt. En als je 'm nu niet van dichtbij ziet kun je 'm binnen enkele frames wél van dichtbij zien, en dan kun je die texture dus beter gewoon in memory houden.

Overigens wordt een variant op dit idee al jaren toegepast - detail textures. Dat zijn textures met extra repeterend detail die op die muur worden getoond op het moment dat die muur heel dichtbij is. Omdat de detailtexture vaker reperteert dan de normale muurtexture hoeft hij dus niet gigantisch groot te zijn.

[engelbertus]

het l;ezen van textures van harde schijf in plaats van te genereren in het geheugen is langzamer, omdat hoe dan ook de cpu moet zorgen dat de uiteindelijke texture in het geheugen komt. in het ene geval moet het daarvoor op de harde schijf wachten en in het andere geval genereert hij dat on the fly.

verder zijn textures natuurlijk niet de reden van stalls. omdat je die natuurlijk efficient vn te voren in het geheugen moet zetten, en beschikbaar houd zolang ze nodig te zijn.
dus bij het binnengaan van een level of ruimte alvast alle textures in het geuegen laden. als je dat elke keer van die traag-als-dikke-stront-in-de-winter hardeschijf doet, dan duurt dat langer dan dat je het ff zelf doet, op momenten dat de game dat toestaat.

vergelijken met streaming media is natuurlijk niet eerlijk, want een texture is geen streaming media. nu wordt er wel steeds meer gestreamed, maar wie weet.. misschien, als een stream ook bestaat uit digitale einformatie en textures, is daar ook een voordeel te behalen met een "nieuw" streaming formaat. echte films streamen gaat natuurlijk nooit sneller dan de ruwe ( gecomprimeerder) data van schijf lezen, omdat je ze slechts eenmaal nodig hebt.

het staat of valt dus met het type texture hoeveel sneller deze nieuwe techniek wordt.
het zal dus afhangen van de eisen die er aan graphics en resolutie worden gesteld waar het omslagpunt zal liggen.

[.oisyn]

het l;ezen van textures van harde schijf in plaats van te genereren in het geheugen is langzamer, omdat hoe dan ook de cpu moet zorgen dat de uiteindelijke texture in het geheugen komt.

Dat is niet waar, de CPU hoeft zich niet de hele tijd bezig te houden met het ophalen van de data. Hij zal een leescommando versturen, en de dma controller zal een interrupt genereren op het moment dat die data klaar is. Ja, dat kost even tijd, maar terwijl de harddisk de data naar het geheugen aan schrijven is kan de CPU wel gewoon z'n eigen dingen doen.

verder zijn textures natuurlijk niet de reden van stalls

Klopt, de reden van de stalls is het wachten/bereken van de data. Wachten op de data hoeft vaak niet in streaming omgevingen, het berekenen van de data zal er wel voor zorgen dat je die kostbare CPU tijd niet aan andere taken kunt besteden.

vergelijken met streaming media is natuurlijk niet eerlijk, want een texture is geen streaming media.

Onzin, een texture is wel degelijk streaming media. In alle games die ik tot nu toe aan meegewerkt heb (Project: Snowblind, Tomb Raider: Legend, de games waar we nu aan werken waarvan ik nog niets mag zeggen) worden textures dynamisch gestreamed, en met de steeds groter wordende textures gaan we nu op mipmapvolgorde streamen, zodat in verloop van tijd steeds meer detail ingestreamed wordt.

[Timfonie]

Dit is een belangrijke (door)ontwikkeling binnen de graphics-wereld, maar in mijn ogen vooral ook voor content-creatie.

Werken met functies en definities van hoe een stukje beeld eruit moet komen te zien, kan een hoop werk uit handen nemen en de precisie enorm vergroten.

Neem als voorbeeld een landschap met gras. Maak definities van grassprieten, graspollen en grasvelden en laat het a.h.w. 'groeien' volgens diverse formules, met random- en andere variatie-elementen erin. Op grote afstand hoef je individuele sprieten of zelfs pollen niet te zien, maar naarmate je dichterbij komt, is het tijd om individuele grasprieten te gaan berekenen en deze steeds scherper af te beelden. Als je tenslotte met je neus in het gras ligt, zie je een woud van sprieten met mieren en andere insecten ertussenin.

Op deze manier heb je niet het probleem dat wanneer je inzoomt op een texture, het beeld alleen maar vager wordt omdat er op een gegeven moment het beeld groter wordt zonder dat er detail bij komt.

Natuurlijk kost het heel wat rekencapaciteit, maar wie kan me een methode noemen waarbij je eindeloos willekeurig kunt inzoomen zonder verlies aan detail?

[roy-t]

Dit random genereren van een grasveldje is nu net iets wat we in de 3e unreal engine gaan terug zien (jn iedergeval in de editor ik weet niet 100% zeker of het nu ook ingame telkens anders wordt opgebouwd)

Artists can build terrain using a dynamically-deformable base height map extended by multiple layers of smoothly-blended materials including displacement maps, normal maps and arbitrarily complex materials, dynamic LOD-based tessellation, and vegetation layers with procedurally-placed meshes. Further, the terrain system supports artist-controlled layers of procedural weathering, for example, grass and vegetation on the flat areas of terrain, rock on high slopes, and snow at the peaks.

(het stond ergens duidelijker maar kan het zo niet vinden )

[Sluuut]

Dit mogen ze wel eens toepassen op Flight Simulator X.. Dat spel is 13GB dankzij de belachelijke textures

[i-chat]

er zijn meer dan genoeg spellen waar dit voor mag gelden,
een niet eens helemaal af spel als America's army is al 2.7 gb ... (en nog 's alleen online ook dus - elke upgrade kost je weer een ruim een uur downloaden. - 1:300 volgens 't artikel... hmmz. dat geloof ik dan weer nie helemaal maar als was 't alleen al 1:10 was ik al zeer blij, (dat scheeld op een spel met 1gb aan textures (en die heb je al snel) 900mb

[VarpoS]

Dat zeggen ze nou juist, dat je niet tex kan omzetten maar dat ze moeten worden gemaakt met dit proggel. Ofwel... als je gelezen had dan wist je dat je post nergens op slaat.

[stewie]

het voordeel is ook dat je geen 512MB video kaart nodig hebt voor wat andere engine wel nodig hebben "ala Quake4".

maar Quake-Wars doet hetzelfde.

[.oisyn]

Complete onzin. Textures moeten nog steeds uncompressed naar je videokaart verstuurd worden voor ze gerenderd kunnen worden. Het scheelt dus alleen in hoeveelheid data op disk, niet in memory.

[truegrit]

je hebt nog wel die mb's nodig voor de "uitgepakte" textures, want om nou 4 seconden te moetne wachten totdat hij weer alle textures gemaakt heeft voor de volgende frame lijkt me ook niet efficient!

[stewie]

nee je kan direct de texture uit het systeem geheugen lezen, je hebt mischien meer systeem geheugen nodig maar niet meer video geheugen.

je gebruikt je CPU om naar je GPU te streamen dus is de Video geheugen Requirment gehalveert.

[Eskimo0O0o]

En wat gaat sneller denk je?

Een videokaart die alles uit het systeemgeheugen moet halen of direct naast zich in het (tevens snellere) videogeheugen heeft zitten?

Er is in de regel ook niet echt een 'requirement', in de zin dat spellen weigeren te draaien als je niet genoeg geheugen op je videokaart hebt zitten.

De reden dat videokaarten met steeds meer geheugen worden voorzien zit niet in het feit dat dit 'vereist' is. Het is simpelweg sneller als een spel veel en grote textures moet cachen en dit lokale geheugen alles (ongecomprimeerd) op kan slaan. Een videokaart die niet zoveel geheugen heeft, moet dus op een gegeven moment alsnog, gecomprimeerde, textures uit het systeemgeheugen, of in het ergste geval, van de harde schijf halen. Dit levert vertraging op, en uit zich in een lagere framerate.

[MetalStef]

Een stevige videokaart met een sloot geheugen blijft natuurlijk wel nodig: Hoewel de texture in 'opgeslagen' formaat erg klein is, neemt hij een normaal formaat in zodra hij uitgepakt is en verwerkt wordt door je videokaart.

Als dit aanslaat voorzie ik echter wel dat videokaarten er weer een taak bijkrijgen: Texture-uncompressie. De gecomprimeerde textures kunnen dan over de PCI-E bus de videokaart ingestuurd worden, die vervolgens zelf de boel uitpakt en verwerkt.

[Verwijderd]

Volgens mij worden de textures na het uitpakken gewoon weer groot. Het is m.i. alleen bedoeld om snel en klein online te kunnen versturen.

[Engineer]

Doet me denken aan de techniek die farb-rausch gebruikte voor hun scene demo's.

http://www.theproduct.de/text.html

x GB aan textures in 64kilobyte (+muziek/models/etc)

[Tjeerd]

En het doet me ook denken aan Genetica, een texture-generator. Door middel van diagrammen - die een bepaald logaritme bevatten - die je aan elkaar knoopt genereer je uiteindelijk een bepaalde texture.

[exyll]

.. doet me denken aan The Black Lotus en dan specifiek de demo Jizz.

Dat was nog wel even wat eerder dan .product ;-)

[GeertJohan]

dat is alemaal heel mooi maar hoe groot is dat compressie/decompressie programma van hun dan?

[simen]

waarschijnlijk ook heel klein. als je kijkt naar de voorloper hiervan (.produkt) zie je dat ze een hele FPS game met textures, modellen, geluiden én de code om het allemaal op te bouwen in 96kb kunnen proppen.

wel is het waar dat deze textures nooit zo mooi zullen worden als echte bitmaps, simpelweg omdat dit formules zijn en niet beelden. als je een formule zou maken om een bestaande foto op te slaan, dan heb je in principe het TGA formaat. lossless compressie.

[Verwijderd]

Ik zie het genereren aan de hand van formules eerder als een voordeel, lijkt me stuk beter uitzien op moment dat je de texture oprekt e.d.