Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 50, views: 23.246 •
Bron: Extreme Tech

Naar aanleiding van de tiende verjaardag van DirectX heeft Microsoft op de Game Developers Conference enkele interessante feiten over de toekomst van deze visuele API en het overkoepelende XNA verkondigd. Een eerste onderdeel dat vernoemd werd is de 'Common Game Controller'. Deze omschrijving verwijst echter meer naar een interface en layout-specificatie dan naar een stuk hardware. Deze controller is gebaseerd op de game pad die onderdeel uitmaakt van de Xbox 2 en kan met een USB-verbinding ook aangesloten worden op de pc. Het keyboard en de muis zullen volgens Microsoft echter niet verdwijnen. Daarvoor zijn ze te geschikt voor bepaalde types games, waaronder Real Time Strategy-spellen. Met behulp van de Common Game Controller zullen console gamers gemakkelijker over kunnen stappen naar de pc. Ook het tweede onderwerp dat besproken werd, handelt over een onderdeel van de Xbox dat naar het pc-platform gebracht zal worden.

De Performance Investigator for Xbox (PIX) is een tool waarmee ontwikkelaars de code voor het opbouwen van de graphics onder de loep kunnen nemen om deze te optimaliseren. Als onderdeel van het XNA-ontwikkelplatform werd ook een PIX-versie voor Windows gecreŽerd. Deze is nog volop in ontwikkeling, maar biedt ondertussen wel al de mogelijkheid code te onderzoeken en te debuggen tot op het niveau van de tijd die besteed wordt aan specifieke DirectX-API's. Bovendien kunnen ontwikkelaars een reeks DirectX-calls opnemen in een soort van macro, om deze vervolgens op verschillende systemen af te spelen en na te gaan wat de invloed van de systeemconfiguratie op de prestaties is. Tot zover de overige XNA-onderdelen. David Blythe en Michael Doherty, respectievelijk verantwoordelijk voor de Windows Graphics and Gaming Group en de Xbox Advanced Technology Group, hadden het namelijk ook over de toekomst van DirectX zelf.

DirectXZe focusten daarbij echter niet op details als de shader models en dergelijke technische zaken, maar bespraken enkele fundamentele problemen waar spelontwikkelaars tegenwoordig mee te maken krijgen en de rol van DirectX in de oplossingen voor die problemen. DirectX is namelijk begonnen als een API voor game-programmeurs, maar evolueert steeds meer buiten die grenzen. In de toekomst zal de naam dan ook gewijzigd worden naar de Windows Graphics Foundation en de basis vormen van Longhorn's grafische Avalon-interface. Het belangrijkste probleem voor ontwikkelaars situeert zich rond de beschikbare bandbreedte. Hoewel moderne videokaarten geheugenbandbreedte aanbieden tot 36GB per seconde, kan een scene die gerenderd wordt met 64 bits per pixel met High Dynamic Range lighting, Z-test en alpha blending gemakkelijk 144GB per seconde vereisen.

Ook de cpu-kracht is tegenwoordig verbluffend hoog, maar is iets waar ontwikkelaars meer van zouden kunnen gebruiken. Enkele mogelijke oplossingen volgens Blythe zijn displacement mapping en geavanceerde shading. Ook hardwarematig 'tessellating', een technologie waarbij een object met relatief weinig hoekpunten doorgestuurd wordt en de extra geometrie on the fly gecreŽerd wordt, kan bandbreedtebesparend werken. Een hardwarematige oplossing lijkt dan ook voor de hand liggend en gpu-bouwers zouden in staat zijn een snelle en gestandaardiseerde 'tesselation engine' te bouwen. Een programmeerbare oplossing lijkt dan weer wenselijk omdat niet iedereen dezelfde eisen stelt, maar dan kijkt men tegen het probleem van de verschillende implementaties aan. Een deeloplossing voor het afhandelen van tesselation is displacement mapping. Daarbij wordt een bitmap-afbeelding gebruikt met verschillende grijswaarden, die de mate van 'tesselation' weergeven.

Displacement Mapping 1 Displacement Mapping 2 Displacement Mapping 3
Displacement Mapping

Daarmee kunnen op eenvoudige wijze details toegevoegd worden, wat zich het beste uit in het niet langer verschijnen van 'hoekige hoofden' op, voor de rest, realistische karakters. Advanced shading is dan weer een technologie waarbij men niet langer uitgaat van het produceren van meer pixels, maar van het uitvoeren van meer bewerkingen op ťťn pixel. Dit omvat ook de 'procedural shaders', door de software zelf gegenereerde textures of oppervlaktes. Het doorsturen van een aantal berekeningen voor het berekenen van de textures is namelijk efficiŽnter voor de bandbreedte dan het doorsturen van ťťn grote afbeelding. Deze technologie wordt overigens al geruime tijd gebruikt door filmproducenten. Tot slot wordt nog even geÔnsinueerd dat Microsoft misschien wel het enige bedrijf is dat groot genoeg is om de verschillende vendors, zowel fabrikanten van videokaarten als ontwikkelaars van spellen, samen te brengen. Het bedrijf is dus duidelijk van plan het DirectX-succes verder te zetten.

Update: De collega's van XboxArena hebben menuscreenshots on line gezet van de Xbox 2 Guide interface, die getoond werden tijdens de presentatie door Microsofts J. Allard tijdens het Game Developer Conference.

Reacties (50)

Reactiefilter:-150048+142+212+32
ik krijg kruisjes bij de 2 rechter displacement mapping pics

edit: lijkt verholpen
ik bij links en rechts net
de pic server loops misschien niet helemaal lekker lijkt het.
Betekent dit nou ook dat Microsoft in de toekomst alle goeie ontwikkelingen op het gebied van DirectX van het PC platform af kan drukken en lekker XBOXen kan verkopen?
Ik snap eigenlijk niks van je post :?

DirectX is door Microsoft ontwikkeld voor het Windows-platform. Xbox draait op een gemodificeerde Windows-versie en beschikt over een, aan de noden aangepastte, DirectX-implementatie. Dat is ný al zo.

Ik zou zeggen, verduidelijk jezelf even want nu slaat je post eigenlijk nergens op imho :)
Ik dacht juist andersom, dus dat de pc en xbox dezelfde controllers kunnen gebruiken :?

Verder zal het makkelijker worden om games van de xbox op de pc uit te brengen, als ik het goed begrijp...
Ik snap wat je bedoelt Yoeri
Mijn vraag was eigenlijk veel algemener bedoelt. Als ik het bovenstaande verhaal lees bekruipt mij het gevoel dat Microsoft feitelijk kan doen en laten wat ie wil. Daarom mijn vraag; Wat voor nut heeft het nog voor MS om in de toekomst te blijven ontwikkelen voor de PC als game platform.
'Ons' enige lichtpunt hierbij is dat MS natuurlijk games ontwikkelt op het PC platform, daar leent een XBOX zich (nog) niet voor. Ik vraag me af waar MS het heen gaat drukken... :>
Je kunt natuurlijk vraagtekens zetten bij de monopoliepositie van Microsoft wat betreft DirectX.

Feit blijft dat Microsoft mŤt DirectX een knap staaltje neergezet heeft dat heel wat deuren geopend heeft voor gameontwikkelaars. OpenGL doet zijn best, maar als ik me niet vergis (ik ben geen kenner) zijn er toch nog wel wat problemen waar men tegenaan loopt om alle DirectX-functionaliteit ook in OpenGL aan te bieden.

Daardoor zijn ontwikkelaars massaal op DirectX gesprongen om hun games te ontwikkelen (vooral vanaf DirectX 5 als ik me niet vergis), wat DirectX gemaakt heeft tot wat het nu is. Een quasi onmisbare API voor alle visuele hoogstandjes. Ik denk dat je dit dan ook vooral moet zien als een superhandige API, en niet als 'weer een mogelijkheid om zijn eigen keuzes door te drukken'. Natuurlijk is het MS die beslist over wat wel of niet geÔmplementeerd wordt in DirectX, maar het moet daarbij wel luisteren naar de noden van de ontwikkelaars of het DirectX-imperium kan even snel weer instorten als het opgebouwd is.

Dit in tegenstelling tot de Windows-markt, waar het gaat om 'domme consumenten' die niet zo gemakkelijk overstappen. Pakweg Electronic Arts zal het echter niet pikken als Microsoft vuile truucjes uithaalt in DirectX om hen erbij te lappen of zo :)
@bas

Neem je eigen advies ter harte en reageer niet als er geen verstand van hebt!

De allereerste directX versies waren inderdaad niet best, maar tegenwoordig is het gewoon beter voor de game industry dan OpenGL.

En dat heeft een aantal redenen:
Ten eerste is het voor het vaststellen van een standaard gewoon verrekte handig als een monopolist dat doet. Kijk maar naar de puinhopen bij DVD-/+ en BluRay/HD-DVD als dat er niet is.

Nu kan een spelfabrikant gewoon op een doos zetten dat een bepaalde DirectX versie nodig is en dan weet iedereen waar ie aan toe is.

Bij OpenGL heb je dat niet. OpenGL loopt gewoon wat betreft game-functionaliteiten erg achter.
Nu kan je echter al die hardware functies van ATI en NVidia kaarten wel aanspraken, maar dan alleen via propiŽtaire extensies. Dus een extensie speciaal voor nvidia en een extensie voor ATI en eentje voor SIS etc.
Dat is voor een game developers gewoon hardstikke onhandig. (En kost veel extra tijd en dus geld)
Systeem eisen op een doos vermelden is dan ook een ramp. Dat kan alleen maar door al die videokaarten apart te benoemen.

En om maar niet terug te denken aan de tijd van de Glide api. Dat was voor developers helemaal een ramp, moest je meerdere api's ondersteunen in je spel.

Verder is DirectX zuiver op games gericht, terwijl OpenGL op de professionele markt gericht is.
Die belangen liggen gewoon niet gelijk, en daarom gaat de ontwikkeling van game-features in OpenGL gewoon trager.

Als laatste wordt DirectX niet door een handjevol mensen bij Microsoft ontwikkeld, maar in samenwerking met de belangrijkste spelers in de industrie. (ATI, Nvidia, Intel etc).
Daarom sluiten de features van DX9 bv heel goed aan bij de wensen van de developers.
Ja, de pr0n-industie gaat verder op DirectXXX :+
Ik zie het probleem niet zo. Een universele standaard is ieders belang en levert alleen maar betere spellen op. In dit geval ben ik voor MS als monopolist.
Zoals onze cultuurfilosoof al zei: "Elluk nadeel hep se voordeel. "
Een universele standaard is ieders belang en levert alleen maar betere spellen op
Dat zou mooi zijn maar in dit geval is het Microsoft en die houden hun standaarden veel te gesloten om het nog universeel te kunnen noemen. Resultaat: het werkt maar op 1 OS.
Liever OpenGL, dan hebben zij die geen Windows gebruiken er ook nog wat aan.
In dit geval ben ik voor MS als monopolist.
Ik ben het er niet mee eens als je 't niet erg vindt. ;)
Dat is helemaal niet waar.
Zie http://www.macdx.com, DirectX is ook beschikbaar voor de Mac. Op deze manier worden veel populaire PC-spellen naar de Mac geport.

Waarom DirectX er niet voor andere OSen is, blijft gissen. Ik kan wel wat bedenken... Bijvoorbeeld dat het op die OSen helemaal niet interessant is om DirectX te implementeren, omdat die OSen toch niet voor spelletjes gebruikt worden, maar als servers ed.
Of dat mensen DirectX willen mijden omdat het nu eenmaal van Microsoft is, en alles van Microsoft is vies.

Maar als iemand zin heeft om DirectX voor linux oid te implementeren, dan is dat geen probleem. In de DirectX SDK en de DDK staat alles wat je moet weten om een werkende implementatie te maken.
Naar fabrikanten is DirectX ook compleet open, dat mag duidelijk zijn, iedere fabrikant ondersteunt DirectX op zijn hardware, zonder uitzondering.

Zo is er ook iemand die zijn eigen Direct3D-compatibele software renderer ontwikkelt (weliswaar voor Windows, maar zou naar ieder OS geport kunnen worden): http://sw-shader.sf.net
Of dat mensen DirectX willen mijden omdat het nu eenmaal van Microsoft is, en alles van Microsoft is vies.
Ik kan me daar wel wat bij voorstellen, maar aan de andere kant, op Linux gebruikt men ook C#, dat is hele taal die door MS ontworpen is. Als men dat wel wil, waarom een API dan niet?

Op de Mac gebruiken veel mensen office. Gedeeltelijk noodgedwongen, maar als men echt uit principieele redenen niet wilde had Open Office wellicht wat meer navolging gehad op de Mac.
Ik had eigenlijk ook wel iets verwacht (of willen horen) over een eventuele uitbesteedde Physics Engine (zoals die add-on kaart, zoals hier genoemd wordt: http://www.tweakers.net/nieuws/36510 )

Aan de andere kant (als ik het goed lees) vinden ze dat er meer gebruik gemaakt moet worden van de CPU, dus dan gaat het weer niet op.

Maar er wordt toch vooral ingegaan op de grafische kant, over andere dingen (geluid en netwerkplay) zeggen ze helaas niets, terwijl een nog lagere lag of verschillende geluids-'levels' voor stemmen, muziek en geluidseffecten ook bij kunnen dragen aan een fijner, soepeler spel.
De PhysX PPU maakt gebruik van de NovodeX API.
Die is beschikbaar voor verschillende platforms.

Het zal ervanaf hangen wat de eventuele andere fabrikanten van PPUs zullen gaan doen, denk ik. Als iedereen de NovodeX API gaat gebruiken, dan is er in principe geen DirectX-toevoeging meer nodig.
Mocht het zo zijn dat het een chaos van extensies en gebrek aan goede support van nieuwe features wordt, zoals bij OpenGL, dan zijn er kansen voor alternatieve APIs, en dan zal het zeker interessant zijn om iets in DirectX te hebben.
Ze vinden juist niet dat er meer gebruik moet worden gemaakt van de CPU, juist dingen als displacement mapping en shading, dat zijn dingen die puur op de GPU worden gedaan. En ja, het genereren van die displacement maps wordt door de CPU gedaan, maar een engine die dat on the fly doet (met uitzondering van ... procedurele displacement maps, wat me wel erg extreem lijkt) zal slecht presteren.
verwijderd...niet goed gelezen..
DirectX wordt dus Windows Graphics Foundation. Is het niet logischer om alleen het graphics-onderdeel (Direct3D) te hernoemen. Voor zover ik weet zit er in DirectX ook dingen als DirectSound, DirectInput e.d. Het lijkt me bijzonder onduidelijk als je straks bij het configureren van een muziek/geluidsprogramma als bron een "Windows Graphics Foundation" moet kiezen :?
Ik stel voor : Windows Totall Foundation; WTF ;)
ok, over 4 jaar heeft dus iedereen een xbox controller naast hun pc om dat die 100% compatible met alle spellen zijn |:(
Over 4 jaar hang je gewoon een tft schermpje, toetsenbord en muis aan je xbox en draai je office 14, windows blackcomb(of hoe heet de versie na longhorn?) en windows media player 13...
nooooooooooooooooo...... een console moet een console blijven g*dverd*mme geen PC-shit, geen toetsenbord, geen muis, geen media shit, geen office...maar een controller en goede games!
Ik, en heeeel veeeeel mensen met mijn willen een 3D FPS echt NIET spelen met een controller hoor ;) Wat dat betreft is WSAD+Muis niet te verslaan :)

Een controller voor een 3D FPS is gewoon not done.
dan moet je maar geen console kopen :+
ik speel al jaren FPS op een console en het gaat prima, als jij dat niet kan dan blijf je toch lekker op je PeeCeetje gamen. oh en WASD + muis niet te verslaan? ooit eens Metroid Prime op DS gespeeld?

en BTW: integenstelling tot de PC komen er op de consoles ook nog weleens andere spelletjes uit dan die eeuwige FPS's :+ :+ en die besturen zich zowiezo al veel beter met een controller.
Ik vind dat persoonlijk ook best een issue, een muis en toetsenbord ga ik echt niet aan een console hangen, dat zit ook voor geen meter op de bank met dat spul.

Nou had ik een idee...
Hoewel ik geen fan van het "trackball" principe ben, weet ik dat er genoeg gasten zijn die daar perfect FPS'en mee kunnen spelen en daarbij ook nog eens goed presteren :P

Mij lijkt het een super idee, al is het puur voor mezelf dat er een gamepad wordt gemaakt waarbij de rechter analoge stick bijvoorbeeld een trackball is. Hiermee zou je dan al heerlijk een cursor kunnen bedienen en na eventjes oefenen ook best lekker kunnen FPS'en denk ik. RTS'en zullen dan ook perfect speelbaar worden, want hier zie je nog maar weinig van op Consoles.
Je kunt in elk geval heel precies richten etc. Nu vind ik het echt geen doen met zo'n analoge stick, in 0.01 seconde een kwart slag draaien en iemand in zijn porem schieten is er echt niet bij...

Bij een Xbox controller zou je dan alsnog de 2 analoge triggers overhouden, voor gas/rem en schieten enzo.. eigenlijk heb je die rechter analoge stick nauwelijks nodig toch. Maak daar aub een trackball van :D

Het belangrijkste van dit alles is nog wel dat er 1 enkele controller blijft waar alles goed mee te doen moet zijn. Het gaat absoluut niet in de smaak vallen als er van alles aan je console komt te hangen. Het ging om de eenvoud en dat moet wel zo blijven.
Sterker nog ik heb nu en xbox controller op mn pc, het ding is gewoon een usb apparaat er zit alleen een andere stekker op.
Ik heb mijn GC controller aan mijn PC hangen O+

en ja, ook die is USB met een andere stekker.
En ik heb een PSX controller aan mn pc hangen ;)
Adapters kan je kopen op http://www.hotbit.nl/index.php?cPath=28&osCsid=d383a23c8930fbf3421f863 0013a603c
Sorry voor de lange url, maar als ik t verkort kom ik bij "illigale shit" uit
Tjah, ik heb ene xbox controller-s ook aan mijn PC hangen.
Dat het apparaat gewoon USB was wist ik wel, maar goeie "3rd party" drivers lieten nog wel even op zich wachten. Deze zijn momenteel echt helemaal super, je kunt nu echt alles configuren. Met al die drukgevoelige toetsen en analoge triggers kun je superleuke dingen doen btw. Ik vind dat ze echt een supercontroller hebben gemaakt, vrijwel alles wat voor de pc te krijgen is gaat veel sneller stuk en heeft veel meer last van verouderende potentiometers. Deze Xbox controller kan echt een hoop hebben is op gebied van technologie zeer modern tov andere controllers zoals ps2/gc

Ik hoop dat ze bij de volgende Xbox weer zo innovatief weten te zijn. Ok, die Standaard controller was mij wat te groot, maar die S versie is toch echt smullen :P
In hoeverre komen dan nog games voor Linux uit?

Als je DirectX of WGF gaat gebruiken als ontwikkelaar heb je enkele voordelen, maar gebruikers blijven gebonden aan Windows. Voor Linux moet je dan weer iets aparts gaan programmeren, wat meer geld kost (wat weinigen ervoor over hebben).
Of gaat WGF ook naar de Linux desktop toe :? :)

Wat een betere positie zou zijn, dat er een Linux gebaseerde console zou verschijnen. Waar draat de PS2 of PS3 op?
De api's zijn niet het probleem voor linux, zoals met SDL of opengl.

waar opengl alleen met direct3d vergeleken kan worden.

Het probleem is de vraag naar/ afzetmarkt op de linux games. En dan is nog het 2e probleem support.

Als linux goed op de desktop doorbreekt komt de rest vanzelf, in de tussentijd hebben we maar met winex(cedga) van transgaming te leven...
Ook hardwarematig 'tessellating', een technologie waarbij een object met relatief weinig hoekpunten doorgestuurd wordt en de extra geometrie on the fly gecreŽerd wordt, kan bandbreedtebesparend werken. Een hardwarematige oplossing lijkt dan ook voor de hand liggend
Die is er toch al een paar jaar in de vorm van ATI's TRUFORM en NVidia's N-Patches?
Ik denk dat er zoiezo weinig boeiends nieuws vanuit DirectX komt, tenslotte ondersteund nVidia ook al Displacement Mapping op hun GeForce 6 serie :).
Weet je zeker dat dit geen dispacement mapping is? (johnwoo)
@BitBooster
Nee, dat is heel zeker geen displacement mapping.

Wel is tessellation een voorwaarde om nuttig gebruik te maken van displacement mapping.

Om het simpel uit te leggen.

1. Met tesselation ga je een een object met weinig hoekputen extra hoekputen geven. Dus een driehoek ga je bv opdelen in 4 driehoeken.
(Inderdaad een onderdeel van Truform)

2. Die extra driehoeken liggen dan nog in het vlak van de oorspronkelijke driehoek waar ze uit gemaakt zijn. Maar daar heb je nog niets aan. Je wilt ze andere coordinaten geven. Maar hoe kom je nu aan nieuwe coordinaten? Dat doe je bv met de normalvectors om zodoende een bol op die manier mooier rond te maken. (ook weer een onderdeel van Truform)


3. Displacement mapping is eigenlijk een ander manier om die extra driehoeken nieuwe coordinaten te geven. Maar ipv dat je realtime nieuwe coordinaten berekent uit de normalvectoren doe je dat uit een map.

1 en 2 zijn gewoon niks meer of minder dan Truform.
Nvidia's N-patches is alleen 2. Het grote probleem bij de nvidia kaarten was dat je in de praktijk geen tesselation had. En zonder dat je die extra driehoekjes creeert heb je ook geen extra detail. En daar doe je dit alles nou juist voor.

Wat er nou nog bij is gekomen in TruformII is dat die extra geometrie die on-the-fly gecreŽerd wordt, alleen wordt gemaakt als het ook nut heeft zichtbaar is. Dus als een voorwerp erg dichtbij is. (of zelfs maar een gedeelte van dat voorwerp)

Wat dat betreft is alles wat daar besproken wordt inderdaad al aanwezig in Truform, maar in de R300 is het lang niet allemaal hardwarematig.

Maar dat wordt natuurlijk pas weer de moeite waard als spellen het gaan gebruiken, en dat gebeurd pas weer als zowel ATI als NVidia het hebben.
Dus als al die bovenstaande opties in DirectX zitten. Dus de volgende DX versie.
Ik denk eerder dat ze iets bedoelen zoals subdivision surfaces... :)

Als dat idd zo is, snap ik trouwens niet echt waarom ze de implementatie een probleem vinden, aangezien de meeste modelleerprogramma's alleen ondersteuning bieden voor het Catmull-Clark schema en deze ook het meest nuttig is vergeleken met andere mogelijke implementaties zoals bv. Butterfly of Doo-Sabin (wordt afaik alleen gebruikt in SoftImage|XSI [1]).

Het zou trouwens erg tof zijn wanneer dat in de toekomst via de hardware wordt ondersteund! Dat zou de 3d modellers onder ons ook de kans geven om nog meer polygonen te gaan gebruiken :9 (mits het gebruikte modelleerprogramma het ondersteund).


[1] Zie: http://www.iro.umontreal.ca/~roys/softimage/html/model/subdivs.html
Ik denk toch echt dat ze Truform achtige technologien bedoelen en geen subdivision surfaces.

Dat blijkt wel niet zo duidelijk uit de tekst, maar als je subdivision surfaces wilt toepassen dan moet je je hele gpu gronding overhoop halen.
En dan is het nog maar de vraag of dat niet zoveel transistors kost, dat het niet meer rendabel is om zowel oude als nieuwe spellen te ondersteunen.

En daar wordt je als consument dan niet zo vrolijk van.
@Johnwoo: Trueform en N-Patches zijn allebei van ATI. En inderdaad, dat bestaat al een tijdje. Maar het zal nu dus in een Windows standaard opgenomen worden, i.p.v. proprietair.
Nu wordt trueform nog nergens gebruikt. Hopelijk gaat dat dus in de toekomst veranderen.

Verder bestaat tesselation bestaat in meerdere vormen. De eerste ATI implementatie deed tesselation op alle tesselation objecten in het blikveld. Nieuwe versies zullen alleen tesselation toepassen op objecten die dichtbij staan, zodat je render kracht bespaard.
Verder zijn er nog een paar render problemen voor speciale objecten, zoals bijvoorbeeld een cilinder. Daar moet de omtrek met tesselation rond gemaakt worden, maar de bovenkant plat, zonder dat er gaten ontstaan. Dat is met de huidige tesselation nog niet goed mogelijk.

@Bitbooster
Je zou displacement mapping als een vorm van tesselation kunnen zien. Bij de typische tesselation wordt er puur uit het object nieuwe punten gemaakt. Bij displacement mapping, voeg je extra informatie toe.
TruForm en N-patches is in wezen hetzelfde. TruForm is de marketing-naam van ATi, net zoals ze hun SM2.0 SMARTSHADER noemen.
Maar op de GF3 zat iets dergelijks, wat RT-patches heette in D3D.
In beide gevallen hebben de fabrikanten echter de support stopgezet. TruForm kun je eventueel nog aanzetten op Radeons, maar het is nog steeds het R8500 niveau, en schijnt zelfs in software geemuleerd te worden op de nieuwere Radeons.

Beide technieken waren echter een soort subdivision surfaces, geen displacement mapping. Displacement mapping bestaat al een tijdje in D3D, maar is nog erg beperkt. Met SM3.0 is het wat krachtiger geworden omdat je nu in de shader de displacement map kunt samplen, en dan verder zelf implementeren hoe de displacement gedaan moet worden.
Nadeel van displacement mapping is dat je bestaande vertices verplaatst... Het zou handiger zijn om nieuwe vertices toe te voegen aan de geometrie, en dan liefst alleen daar waar het ook zichtbaar is (LOD).

Het idee is dus nu om hier een compleet nieuwer programmeerbare shader voor te maken, zodat de programmeur zelf de vrijheid heeft om displacementmapping en/of subdivision te implementeren zoals hij dat wil. Het probleem wordt dus om een ontwerp te maken dat zowel flexibel als snel is. Er zullen wel een aantal shader-versies overheen gaan voordat het echt volwassen is, net als bij de eerdere shaders.
Je haalt een paar zaken door mekaar.

N-patches is een onderdeel van Truform.
Truform is in weze n-patches en tesselation samen.

Dat je bij displacement mapping alleen bestaande vertices verplaatst is niet waar. (Dat is een nvidia beperking) Dan is displacement mapping ook zinloos, want je bespaart er niks mee.
In de displacement mapping zoals die op de R300 gedaan kan worden gebruik je displacement mapping in combinatie met tesselation. En dan verplaatst je dus de on-the-fly gecreerde vertices.

En dan bespaar je dus inderdaad bandbreedte.

En dat je een nieuwe shader nodig hebt en dat het een aantal versie zal duren ben ik het niet mee eens. Je hebt alleen een standaard nodig waar het in gedefinieerd wordt. Truform1 in hardware was al razendsnel. TruformII in hardware zal ook snel zijn. En dan heb je al alle features die je wenst.
Ik denk niet dat het nuttig is om over stricte definities van N-patches en displacement mapping te gaan discussieren.

N-patches en RT-patches zijn twee technieken voor subdivision (tesselatie dus) in D3D. Of je dan de tesselatie er wel of niet bij rekent, lijkt me niet zo nuttig. Voor zover het D3D betreft zijn N-patches de manier om TruForm te gebruiken.
Zie ook de FAQ: http://www.ati.com/developer/truform_faq.html

Over displacement mapping kan ik ook kort zijn. Tesselation hoort net zo min bij displacement mapping als (steep) parallax mapping bij bumpmapping hoort.
Het zijn nuttige uitbreidingen, maar behoren niet per definitie tot de basistechniek.
En zoals ik zelf al zei, is inderdaad displacement mapping zonder enige vorm van LOD niet bijster interessant.

En dat TruForm II... ik heb er zelf weinig van gezien, apart van de animaties op de ATi website ten tijde van de introductie van de R300. Volgens mij is er net zoveel van overgebleven als van hun befaamde F-buffer.
Als je m'n reactie goed leest dan zie je dat ik ook helemaal niet zeg dat Tesselation onderdeel is van techniek displacement mapping.

Maar zonder dat is displacement mapping gewoon totaal zinloos in spellen. Het levert je namelijk geen winst op. Dus waarom zou je dan doen?

En als je nou je LOD op je tesselation zet (zoals bij TruformII) dan heb je dat daarmee ook meteen voor je displacement mapping gefixed.


Inderdaad is er niet veel van TruformII overgebleven. Simpelweg omdat spellen het niet supporten.

En dat zou ik zelf al game-developer ook niet doen. Het is namelijk een prachtige techniek, maar je kan wel leuk een spel maken dat er prachtig uit ziet met TruformII, maar als het vervolgens traag en lelijk is om een kaart die dat niet ondersteunt, dan verkoopt het niet.
En als je een spel maakt dat er geweldig uitziet op die andere hardware, waarom zou je dan nog extra geld investeren om TruformII effectief te ondersteunen?

Daarom nogmaals: pas als de functionaliteit van TruformII in DX zit zal het pas gebruikt gaan worden door de developers.
Je zei dat het niet waar was dat je alleen vertices verplaatst. Ik kan dat niet anders interpreteren dan dat het dus ook het toevoegen van vertices inhoudt.
Maargoed, dat zal allemaal wel. Er zijn zoveel definities in computergraphics die niet eenduidig zijn, dan kan deze er ook nog wel bij.

Over TruForm II, daarbij bedoelde ik dus dat het net als bij de F-Buffer ook niet via een OpenGL extensie te gebruiken is. Ik weet niet of het nog steeds zo is, maar in dat geval is het dus helemaal niet bruikbaar voor programmeurs, op welke manier dan ook. De vraag is eerder of de functionaliteit uberhaupt bestaat en/of bruikbaar is.
Het lijkt er op dat we een misverstand hebben.
Je zegt:
Je zei dat het niet waar was dat je alleen vertices verplaatst. Ik kan dat niet anders interpreteren dan dat het dus ook het toevoegen van vertices inhoudt.
Maar dat heb ik niet gezegd. Ik heb gezegd dat het niet waar is dat je alleen bestaande vertices verplaatst.

Ik heb gereageerd op deze bewering van je:
Nadeel van displacement mapping is dat je bestaande vertices verplaatst... Het zou handiger zijn om nieuwe vertices toe te voegen aan de geometrie, en dan liefst alleen daar waar het ook zichtbaar is (LOD).
En daarop heb ik dus gezegd dat het helemaal niet zo is dat je met displacement mapping alleen die bestaande vertices verplaatst, maar dat dat alleen bij Nvidia het geval is.

Met ATI hardware kun je immers precies doen wat jij daarin zelf al aangeeft wat handiger is: namelijk nieuwe vertices toevoegen en die verplaatsen.
(en dan ook nog alleen daar waar het zichtbaar is)

Dat TruformII werkt is door ATI in tech-demo's wel bewezen. Maar persoonlijk weet ik ook niet hoe je het moet activeren. Wellicht wel even simpel als Truform1 (In Morrowind is truform geactiveerd door fans van het spel. Nog steeds is dat de mooiste demonstratie die ik ken van het net van truform)
Maar hoe het te activeren is doet er wat mij betreft eigenlijk niet toe, als developers zowiezo niet van plan zijn het te gaan gebruiken.
03/09/2005

"IBM today announced 'first-of-a-kind' technology solutions designed to help online game developers and game publishers create, manage and distribute game content faster, easier and at lower costs. IBM said that as the online game market industry continues to grow at unprecedented rates, game developers and publishers need to reduce development time and costs by utilizing flexible technology and solutions that will allow them to launch and manage their games on demand with a comparatively small investment in hardware, software and services."

http://www.ebizq.net/news/5703.html
Ik denk dat de nadruk ook op efficientie ligt bij microsoft. De manier waarop shader calculaties worden uitgevoerd zijn wel snel, maar nog lang niet zo efficient als dat ze kunnen zijn. Een gevoel wat ik al langer had.

Een manier van werken, waar ze in de film industrie al lang achter zijn: Het beeld hoeft niet perse 100% correct gecalculeerd te zijn, zolang het er maar goed uit ziet.

En daar mag je dan best een paar smerige truuks voor uithalen waardoor het lijkt dat er heel indrukkwekkend gerekend wordt. Een voorbeeld hiervan is normal mapping waardoor het lijkt dat het er heel veel poly's gebruikt worden terwijl het helemaal niet zo is. Of in plaats van echte Global Illumination gewoon spelen met lightdomes en shaders om het effect te simuleren. Want echte GI is heel wat zwaarder. De DirectX SDK had al zo'n sample applicatie die zo'n truuk gebruikt, waarbij het lijkt, dat een soort van beeldje van een azteekze god ofzo, wordt belicht door middel van GI terwijl dit niet zo is. (edit: sorry voor de beetje kromme zin ... formulering is niet al te best |:()

Op dit item kan niet meer gereageerd worden.



Populair:Apple iPhone 6Samsung Galaxy Note 4Apple iPad Air 2FIFA 15Motorola Nexus 6Call of Duty: Advanced WarfareApple WatchWorld of Warcraft: Warlords of Draenor, PC (Windows)Microsoft Xbox One 500GBTablets

© 1998 - 2014 Tweakers.net B.V. Tweakers is onderdeel van De Persgroep en partner van Computable, Autotrack en Carsom.nl Hosting door True

Beste nieuwssite en prijsvergelijker van het jaar 2013