Nvidia Officially announces Cg

[anoniem]

Maar dat is juist mijn punt, die mogelijkheden waren er altijd al.

[anoniem]

[quote:9d3e3183e0="BA"]Maar dat is juist mijn punt, die mogelijkheden waren er altijd al.[/quote:9d3e3183e0] hoezo waren die er altijd al, in Cg kan je toch veel sneller en makkelijker programeren dan in de SDK van Dx8.1 en 9. ik bedoel met te zeggen dat er nu de mogelijkhied is om sneller een product neer te zetten met nieuwe features omdat het makkelijker is om te implementeren met CG ga alsjeblieft nu is die link lezen die ik in de 2e post geef dat scheelt een hoop uitleggen :wink:

[anoniem]

Ik bedoel dus dat het wel leuk is dat ze het sneller programmeren kunnen, maar als ze dat domweg niet doen, net als bij DX8 software, dan schieten wij daar dus helemaal niks mee op. Kijk naar de MAX-FX engine van Max Payne en 3DMark, die hadden allang DX8 features, kijk maar naar 3Dmark 2001. Toch zaten er geen DX8 features in Max Payne, en nu een jaar later zijn de DX8 games bijna nog steeds op 1 hand te tellen. Wel leuk dat nV zegt dat het sneller kan, maar dan moeten ze dat dus wel doen.

[anoniem]

Het grote probleem is de optimalistaties die de verschillende hardware nodig heeft om goed te presteren. Om je even op te frissen, ATI is met de programmable shader en vertex engine niet compatible met nVidia. Dit komt omdat beide bedrijven hun eigen technologie gebruiken. Dit is een reden dat bepaalde technieken niet of nauwlijks gebruikt zijn. Cg zou een brug moeten slaan tussen de verschillende hardware. DirectX doet dat namelijk niet... DirectX 8 of 8.1.... Het is juist heel goed om los te komen van Microsoft. Microsoft is als een molensteen die om de nek hangt van ATI en nVidia. Met Cg kun je programmeren voor de XBox, GameCube, Playstation, de PC en wat je verder nog denkt te willen uitbrengen. Het gaat erom dat je de juiste compiler levert voor Cg. En dit is dus de taak voor Sony, Microsoft, Matrox, ATI en wie nog meer. Dat is met wat ik bedoel dat andere bedrijven moeten inhaken. In het begin zal nVidia hier de meeste voordeel bij hebben omdat zij nu eenmaal de maker zijn van Cg en hierdoor een aantal maanden voorsprong hebben. Je moet Cg daarom ook zien als een software produkt van nVidia waar andere bedrijven ook gebruik van kunnen maken. nVidia heeft al die anderen wel nodig om dit tot een succes te maken. In mijn ogen heeft dit absoluut niks te maken met monopoly willen hebben, maar gewoon een extra injectie voor de software ontwikkeling. Die loopt op het moment zover achter op de hardware dat elke verbetering zeer welkom is. Als DirectX zo geweldig was geweest dan was het wel gebruikt, maar het is gewoon te ingewikkeld voor de meeste programmers.

[anoniem]

Ik dacht dat DX juist 1 instructieset was, die alles ondersteunde? Niet zoals OGL, waarbij alle fabrikanten dus hun eigen extenties hebben. Maar bij Cg hoeven bedrijven als ATI en Matrox dus alleen maar hun eigen compiler te leveren, en alles komt er uitgerold in OGL en D3D en ook nog eens voor hun hardware geoptimaliseerd? En hoe zit het dan met features als TruForm, kunnen die dan ook gebruikt worden in Cg?

[anoniem]

In principe wel, ware het niet dat Truform zuigt en niet van deze tijd is. Dus ik denk niet dat ATI daar veel effort in zal stoppen.

[anoniem]

Jaja, maar het was maar een voorbeeld. SS2 met TruForm ziet er trouwens best goed uit, als de implementatie beter zou zijn. Dus geen machinegun lopen die bol zijn :D

[anoniem]

In principe zou je met Cg wanneer je er bijvoorbeeld een GF4Ti compiler in zou stoppen gewoon een hogere polycount kunnen gebruiken waardoor je bijvoorbeeld meer detail hebt. Nu is het zo dat met moderne spellen rekening gehouden moet worden met bijvoorbeeld TNT2's.... Ik denk dat voor SAM de drempel op een TNT2 ultra ligt. Een Matrox G550 wil al niet meer, mede door de slechte OpenGL ondersteuning van Matrox.

[anoniem]

Hoe bedoel je dat? Je zou een spel dus zo kunnen compilen dat bijvoorbeeld een GF4 models gebruikt met veel hogere polycounts? Maar dat is dan toch juist weer veel meer werk? dan moet je voor elke kaart andere models maken. Is wel weer leuk als je toevallig een GF4 hebt natuurlijk :D

[anoniem]

Nee, juist niet!!! Dat is het hele principe van Cg. Je programmeert 1X daarna ga je met de verschillende Compilers aan het werk. En dat gaat automatisch :) dus geen coding meer..... Je moet het zien als een Tree. Boven aan de code met daaronder alleen maar compilers naar de verschillende hardware. Dus veel minder werk voor de programmer

[anoniem]

Op die manier. Dus omdat je maar 1 keer hoeft te coden, kan je nu verschillende moduels gebruiken. Want volgens mij gebruiken de huidige games altijd hetzelfde model. Dan zou je dus ook andere dingen heel snel kunnen doen, bijvoorbeeld alle enemy's in een spel er net iets anders uit laten zien, door delen te 'husselen' Alhoewel dat met Displacement Bumpmapping ook al kan, door gewoon bij elk model/caracter een andere displacement map te gebruiken.

[anoniem]

Je kunt geen models husselen, je moet altijd uitgaan van het basis model. Met de compiler kun je dan de polycount en de lighting variëren. Maar zoals in Quake 3 zijn echt niet allemaal dezelfde modellen gebruikt. Wel kun je idd een displacement map toevoegen die uitgaat van het basis model. Alleen heb je in dit geval niet 1 model omdat je meerdere modellen reeds in je code hebt staan vanwege de kaarten die geen HDM hebben. Maar in principe is het dan niet meer nodig om een highpolycount model te compilen wanneer je HDM gebruikt.

[anoniem]

Het zou dus ideaal zijn als je maar 1 model hoeft te gebruiken, maar je zit dan dus weer met de beperkingen van oudere kaarten :( Maar dan zou je dus wel in een game 1 basismodel kunnen gebruiken wanneer een kaart wel HDM ondersteund, en voor de rest niet. Op die manier zou je wel geheugenruimte kunnen besparen. Voor de niet HDM kaarten kies je dan voor de aanpak met meerdere models. Slashhead, wanneer ga jij voor ID werken? ;)

[anoniem]

Hehe, ik aas op een plekkie bij Talon :o Geheugen ruimte besparen door op models te knijpen zal niet echt helpen. De basis models zijn te verwaarlozen t.o.v. het tesselated model. Wel moet je natuurlijk in de bron code rekening houden met de displacement mapps. Die moet je dus wel maken, want die komen niet vanzelf..

[anoniem]

// hoezo waren die er altijd al, in Cg kan je toch veel sneller en makkelijker programeren dan in de SDK van Dx8.1 en 9. En heb je hiervoor een bewijs dan dat *niet* uit de reclamefolders van nVidia afkomstig is ? Van zo'n beetje iedere library wordt beweert dat het 'programmeren sneller is dan library X van de concurrent'. Het enige echte voordeel dat Cg heeft is dat ze geen ondersteuning voor 'legacy'-routines hoeven te leveren. M$ kan namelijk niet eventjes het hele systeem omgooien zodat het laatste nieuwe feature wordt ondersteund. Ze proberen het wel, maar doordat ook de hardwarefabrikanten het nooit eens zijn over 'de' manier om iets te ondersteunen (beter gezegd : niet eens willen zijn vanwege de kosten van patenten en het 'not developed here'-syndroom) verloopt dat niet altijd even soepel, met als gevolg de 'trage' ondersteuning door de spellen/software. Kijk maar naar de 'pixelshaders'-tech: M$ heeft zowel nVidia als Ati tegemoet 'moeten' komen en pas toen kon men een 'gezamenlijke' aanpak gaan bedenken ... Tenzij de andere fabrikanten tegelijk met nVidia de ondersteuning voor cG regelen (en dat is IMHO 'not bloody likely') hebben we hier gewoon te maken met het verstevigen van nVidia's monopolie-positie ... Met andere woorden : als de softwarehuizen dit overnemen (denk maar niet dat ze zo maar ff op een nieuwe tool overstappen !) dan wordt de rest van de hardware-fabrikanten in een klap op een gigantische achterstand gezet. Want welke hardware-fabrikant heeft genoeg mensen in dienst om naast de drivers nog een of andere 'compiler' te schrijven & testen ??? Zeker als die compiler een hele andere filosofie aanhangt dan de hardware die je zelf aan het ontwikkelen bent ? Eerlijk gezegd vind ik het enige voordeel van het verplaatsen van dit monopolie van M$ naar nVidia het feit dat ondersteuning door andere OS'en op gelijkwaardig niveau kan komen. Maar hebben we daar eigenlijk niet het redelijk hardware & software 'onafhankelijke' OpenGl voor ?

[anoniem]

Als jij de interviews gevolgt hebt met de verschillende software makers dan weet je dat programmeren in DirectX 8 een groot probleem is en ten grondslag ligt aan het feit dat we nu amper software hebben. Mijn verhaal over Cg gaat daarom ook uit dat het open source is en dat andere fabrikanten compilers kunnen leveren. Anders dan heb je er niks aan zoals ik al in een eerdere post melde.

[anoniem]

Vind je het gek ? nVidia doet hetzelfde met Cg vs DX als MS met z'n C# vs Java. Gewoon alle 'goede' onderdelen verzamelen (ie alles wat in hun straatje past) en alles wat 'slecht' is (ie alles dat niet op hun hardware past) er uit gooien. Geen wonder dus dat Cg 'beter' functioneert (of in ieder geval volgens nVidia beter dan DX). Dat ze er een 'open source' versie van maken is meer een marketing-issue omdat DirectX zo algemeen geaccepteerd is dat je een nieuwe 'Glide'-Api niet meer zou kunnen verkopen aan de programmeurs. Maar daarentegen een of ander 'magisch' utility dat alle problemen oplost ... is zo'n beetje de 'holy grail'. Eerlijk gezegd vraag ik me echt af waarom nVidia denkt iets wel te kunnen dat M$ niet gelukt is (namelijk een 'simpele' hardware-onafhankelijke interface voor grafische kaarten). Door de verantwoordelijkheid van de hardware-specifieke compiler door te schuiven naar de andere makers ontlopen ze gewoon de problemen die MS wel tegenkwam bij het opzetten van de DX-interface.

[anoniem]

De toekomst zal laten zien of het werkt. Niks doen aan de huidige situatie is in ieder geval geen optie.

[anoniem]

DirectX 9 zal toch enige verbeteringen brengen (ik hoop tenminste dat M$ zich wat van de 'klachten' over DX 8.x heeft aangetrokken) ... maar dan nog. Het laatste waar we op zitten te wachten (als consument) is een hardwarefabrikant die echt alles voor het zeggen heeft. Ik ben tenminste maar wat blij dat je voor CPU's de keuze hebt uit Intel & AMD ... voor grafische kaarten is die keus/concurrentie nog lang niet op dat niveau (probeer maar eens iets anders dan nVidia te vinden in de 'normale' computerwinkel ... ) en met Cg zou dat nog erger kunnen worden :(

[anoniem]

IMHO heeft Cg potentieel voor toekomstige en moderne hardware. Alleen zal nVidia in het begin er de meeste baat bij hebben omdat ze het ontwikkeld hebben en daardoor een x-aantal maanden voorsprong hebben op de rest. Tenslotte is het ook in het voordeel van de andere fabrikanten wanneer hun hardware beter ondersteund wordt. En als ze daar middels een eigen compiler de hand in hebben zou dat gunstig kunnen uitpakken. Wat Microsoft betreft, is de hele toestand rond DirectX en de verschillende versies die daaruit voortkomen omdat fabrikanten het toch weer anders willen (DX 8.1 bijvoorbeeld) een grote belangen verstrengeling. We mogen idd hopen dat dat bij DirectX 9 anders gaat, maar de eerste berichten daarover zijn nu niet bepaald hoopgevend. Ik hoop dat middels Cg, de hardware fabrikanten hun eigen koers kunnen varen en helemaal los komen van Microsoft. Deze laatste wil namelijk ook niks anders dan openGL de nek omdraaien.