Japans bedrijf ontwikkelt real-time ray-tracingsysteem

Het Japanse bedrijf Tops Systems Corporation heeft een systeem aangekondigd met negen chips, die elk 73 cores bevatten. Het desktopsysteem wordt ontwikkeld voor real-time ray-tracing en zou een rekencapaciteit van 800 teraflops leveren.

Het Japanse Tops Systems werkt samen met Unisys en Toyota aan de ontwikkeling van het systeem, dat in elk geval in de auto-industrie gebruikt zal worden. De rekencapaciteit van 800 teraflops kan uitsluitend voor real-time ray-tracing worden ingezet. Het systeem bestaat uit negen speciaal ontworpen chips met elk acht clusters. Zeven van de acht clusters hebben negen cores; de laatste cluster bestaat uit een enkele risc-processor, die de taken over de andere kernen verdeelt. De chips zouden met 45nm-procestechnologie worden gebakken en het gehele systeem zou ongeveer 1000W verbruiken.

De chips zijn zo ontwikkeld dat er direct ray-tracing op gekromde oppervlaktes uitgevoerd kan worden, zonder dat daar polygonen aan te pas komen. Door geen gebruik te maken van polygonen is de uiteindelijke afbeelding nog waarheidsgetrouwer. Om het beste resultaat te krijgen, worden de lichtstralen in 35 frequenties opgedeeld, waarna onder andere spiegeling en breking voor elke frequentie individueel worden uitgerekend. De negen cores van elke cluster hebben daarbij elk een specifieke eigen taak. De makers zeggen dat de analyse van het parallellisme van hun ray-tracingalgoritme zo goed als af is en dat de productie van de chips binnenkort kan beginnen.

Lees meer

Reacties (64)

d-snp 7 juli 2009 14:44

Real time raytracing op curves in plaats van op polygonen, niet erg interessant voor games dus. En in de film CG industrie houden we ook al niet echt van curves.

Curves in CG en games worden omgezet in polygonen (tesselation) en daarna op de rasterization of raytracing manier gerenderd. Misschien dat het andersom doen, dus de polygonen omzetten in curves, en die dan met deze raytracer renderen uitkomst zou bieden. Maar dan krijg je wel problemen met dingen die hoekig moeten zijn. (Opzich is dat niet heel erg, want maar weinig dingen zijn echt heel hoekig).

Maar ja, dit ding zal wel een enorme kast zijn met een prijskaartje waar zelfs de grote renderfarms van zullen schrikken.

[Reactie gewijzigd door d-snp op 22 juli 2024 20:36]

Zoijar @d-snp • 7 juli 2009 15:12

Polygonen worden alleen gebruikt omdat die snel door hardware getekend kunnen worden. Het is vaak veel efficienter om geometrie als patches/curves op te slaan. Indien er hardware bestaat die in real-time patches kan raytracen, dan is dat ontzettend interessant, ook voor games. Je zegt het zelf al: curves worden omgezet in polygonen, maw men maakt een benadering van de surfaces met polygonen om sneller te kunnen renderen. Hoekige objecten kan je overigens ook prima met curves beschrijven.

Pinkys Brain @Zoijar • 8 juli 2009 03:49

Patches zijn efficient voor opslag, maar de intersectie testen zijn erg duur ... voor kwaliteit per rekentijd denk ik niet dat het altijd een goed idee is.

Noxious @d-snp • 7 juli 2009 17:40

Maar ja, dit ding zal wel een enorme kast zijn met een prijskaartje waar zelfs de grote renderfarms van zullen schrikken.

Lees nog eens

hij past in een desktopbehuizing.

hiostu 7 juli 2009 14:50

De ontwerpers gebruiken ray-tracing op basis van rasterization in plaats op basis van polygonen.

Klopt deze zin wel? Rasterization is toch juist een andere manier van renderen dan Ray-Tracing. Waarbij Rasterization op dit moment juist bij spellen gebruikt wordt en ray tracing bij renderen voor films. Over het algemeen maken beide gewoon gebruik van objecten gebasseerd op polygonen.

Wellicht dat een van de 3d programmeurs die hier rondhangen iets meer over kwijt wil

Zoijar @hiostu • 7 juli 2009 15:15

Als "3d programmeur" snapte ik die zin ook niet. Raytracing op basis van rasterization betekent voor mij dat ze de eerste orde hits bepalen door polygonal models te renderen op klassieke hardware.

D1rk @Zoijar • 7 juli 2009 16:38

Ik vind die zin ook vaag maar dan vooral door dit stuk:in plaats van op basis van polygonen. Voor zover ik weet gebruik je bij zowel raytracing als rasterization polygonen.

Dit suggereert bijna dat ze voxels gebruiken i.p.v. polygonen.

Het zou kunnen dat ze die voxels krijgen door een model op basis van polygonen te rasterizeren en dat ze die weergeven met raytracing. Maar volgens mij gebruik ik dan de term rasterizatie verkeerd...

.oisyn Moderator Devschuur® @Zoijar • 7 juli 2009 20:35

http://gathering.tweakers...message/32223134#32223134

Snoitkever

@hiostu • 7 juli 2009 17:15

Nee, volgens mij is dat een interpretatiefout aan de kant van Tweakers, hoewel ik er bij moet zeggen dat ik het originele artikel vrij onduidelijk vind op dit punt. Zie deze tekst:

GPUs have been evolving into general-purpose devices, but based on the assumption that polygon rendering is used.

The rendering method used is rasterizing*, used in most games, and not the ray tracing method that precisely simulates light reflection and other characteristics. As a result, researchers decided that freely-shaped surfaces were not a good choice for direct ray tracing.

Volgens mij verwijst "the rendering method used" naar de paragraaf erboven, en dus naar GPUs, terwijl Tweakers dit kennelijk interpreteerde als een verwijzing naar de manier van renderen van deze nieuwe chip. Wat denken jullie?

Lamer_Deluxe 7 juli 2009 20:57

Raytracing is al een behoorlijk oude techniek, populair in de jaren 80. CPU's en ook GPU's kunnen al een tijdje realtime raytracen. Het algoritme is vrij eenvoudig. Maar niet met curved surfaces, zoals die inderdaad in de auto industrie veel worden gebruikt.

Raytracing is leuk omdat je pixel precies reflecties, refracties en schaduw kunt berekenen. Het nadeel bij raytracing is dat deze te scherp zijn omdat ze niet diffuus worden berekend. Ook is wordt er alleen maar direkt licht berekend. Er worden stralen vanuit de camera de scene in geschoten, als er een oppervlak geraakt wordt dan wordt er gekeken door welke lichtbronnen deze verlicht wordt (en voor schaduw, of er polygonen in de weg zitten), ook kan er een volgende ray gebruikt worden voor berekening van reflectie of refractie (dit kan een aantal keer gebeuren).

Voor indirekte lichtval, diffuus licht weerkaatst door een oppervlak, werd er daarna radiosity uitgevonden, maar dit is een nogal reken intensief systeem. De geometrie wordt onderverdeeld in een heleboel punten waar het weerkaatste licht van alle lichtbronnen wordt berekend. Als je deze informatie opslaat kun je wel realtime met een camera door de scene bewegen, iets dat ook al in oudere FPS games wordt gebruikt.

Tegenwoordig is er een systeem dat Global Illumination heet. Hierbij schiet je een aantal rays uit elke lichtbron, elke keer als je een oppervlak raakt schiet je weer meerdere rays, totdat je in de camera terecht komt. Hier moet je veel truuks toepassen om het sneller te maken en de uitkomst is een benadering (monte carlo sampling), hoe meer stralen je gebruikt, hoe precieser het resultaat. Hiermee krijg je prachtig realistisch diffuus licht en mooie softshadows.
Ook kun je nu doffe reflecties (metaal en zijdeglans e.d.) en refracties (matglas) berekenen.

Dan kun je ook nog lichtval van reflecterende en glazen objecten berekenen (caustics), denk aan reflectie van water op een muur bijvoorbeeld, lichtbreking met een kleurenspectrum, anisotropic materialen (met zeer fijn relief) etc.

Als je pixels meerdere keren berekend met een klein semi-willekeurig tijdsverschil krijg je motionblur, als je de camera positie per pixel meerdere keren berekend met een kleine verschuiving krijg je scherptediepte. Bereken je elke pixel een aantal keer met een kleine ray offset dan heb je anti-aliasing.

Global Illumination kan voorberekend worden en dan met truukjes op een GPU in realtime worden gebruikt. Er zijn al meerdere spellen die deze techniek gebruiken voor een veel natuurlijkere lichtval. Bij 3D animatie programma's heb je bijvoorbeeld Mental Ray, Final Render en Brazil die met Global Illumination werken.

Verwijderd @Lamer_Deluxe • 7 juli 2009 22:13

Tegenwoordig is er een systeem dat Global Illumination heet. Hierbij schiet je een aantal rays uit elke lichtbron, elke keer als je een oppervlak raakt schiet je weer meerdere rays, totdat je in de camera terecht komt.

Even ter correctie... dit gaat alleen op voor Photon Mapping en GI technieken die 'gestuurd' worden door soortgelijke systemen.

Het gros van de GI systemen (zoals QMC) gaan net als raytracen 'achteruit' te werk. Dus een 'ray' schiet vanuit het zichtveld (de camera) de scène in, en op het moment dat die iets raakt worden van daar uit in een halve bol weer nieuwe rays de scène ingestuurd, net zo lang tot het maximaal aantal 'weerkaatsingen' is behaald.

Zou je dit -puur- op deze manier doen, dan moet je vaak veel geluk hebben wil je een lichtbron raken (moet dan ook een echt object zijn). Vandaar dat meestal 'het eerste licht' vanuit de lichtbronnen zelf wordt gedaan, zodat zo'n ray van zegge een muur het licht op de vloer oppakt, zonder dat daarvandaan weer nieuwe rays moeten worden berekend en daarvan dus toevallig een paar die lichtbron zouden moeten raken.

Photon Mapping gaat nog weer een stukje verder door rays vanuit de lichtbron de scène in te sturen, en deze rond te laten stuiteren, en bij elke 'stuiter' als het ware een lichtvlek achter te laten. Doe dit met genoeg* rays (photons) en je krijgt vanzelf ook weer een goede (indirect) licht invulling.

* Helaas doel ik met 'genoeg' op ettelijke miljarden, wat dan weer problemen qua beschikbaar geheugen oplevert, etc. Vandaar dat de meeste moderne GI systemen een combinatie van de 2 of soortgelijke systemen zijn. 'eerste licht' + een grove schatting vanuit photons en daar dan bovenop QMC (die dan dus al een gedeelte weerkaatst licht op pikt).

Faust 7 juli 2009 16:42

ps3 doet en kan al heel lang raytracen:
http://www.youtube.com/re...tracing&search_type=&aq=f

vergelijkbaar met dit systeem, wellicht nog krachtiger/efficienter.
Cell is namelijk geschikt/ontworpen voor (onder andere) dit soort taken. 2 miljard heeft de ontwikkeling van die chip gekost. Ben nu wel benieuwd naar de ware specs van het systeem uit dit artikel..

mjtdevries @Faust • 7 juli 2009 17:47

ELKE cpu kan raytracen.

Er zit een groot verschil tussen realtime raytracen en realtime raytracen.

Het wel of niet realtime zijn van raytracen hangt van een paar zaken af:
Hoeveel rays gebruik je
Hoeveel objecten heb je
Hoeveel reflecties laat je doorrekenen
Ga je refracties doorrekeken en zo ja, hoeveel.
Ga je radiosity doorrekenen en zo ja, hoeveel rays?

De workload voor die PS3 is vrij simpel. Weinig objecten in beeld. Gewoon wat simpele reflecties en wat simpele schaduwen.

Waarom zeg ik dat die reflecties simpel zijn? Welnu: als je een "ray" gaat doorrekenen dan betekent een reflectie simpelweg dat die ray in 1 bepaalde richting weerkaatst wordt en je daar verder gaat rekenen.
Je kan dan bepalen of je 'm 1 keer laat reflecteren voor je stopt met tracen, of dat je 'm meerdere keren laat reflecteren. In dit voorbeeld op youtube zo te zien maar één keer. Dat scheelt heel veel rekenkracht.

Laat ik dan meteen maar doorgaan naar het meest afgrijselijke wat je voor raytracing kan bedenken: Radiosity!
Radiosity betekent dat je reflecties gaat doorrekenen aan een oppervlak wat een diffuse reflecie heeft. Denk bv aan een blad wit papier.
Een spiegel reflecteert licht maar in 1 richting. Eén inkomende ray die je "traced" levert maar één uitgaande ray op.
Een blad papier reflecteert licht in ALLE richtingen. Eén inkomende ray die je "traced" levert een oneindig aantal uitgaande rays op in alle richtingen. In het val van een vel papier een halve bol.

Uiteraard kun je geen oneindig aantal uitgaande rays berekenen, dus ipv daarvan gebruik je bv 18 rays verdeeld over die halve bol.

Vervolgens heb je naast dat blad papier een witte muur, die ook diffuus reflecteerd. Een groot deel van die rays van dat papier weerkaatsen tegen die witte muur en leveren per stuk opnieuw 18 nieuwe rays op.

Je begrijpt dat het aantal stralen dat je moet berekenen gigantisch explodeert met radiosity.

Maar radiosity is wel wat het verschil maakt tussen een raytraced plaatje wat er levensecht uit ziet, en een fake plaatje.

Om een leuk voorbeeld te geven:
http://hdri.cgtechniques.com/~sponza/show.php?id=408
Ga maar eens kijken hoe de reflecties van het zonlicht lopen. En ga je dan eens afvragen hoe de gallerij aan de rechterkant verlicht kan worden. En de gallerij op de eerste verdieping. Met gewoon simpele reflecties krijg je dat effect niet.

Faust @mjtdevries • 7 juli 2009 18:40

bedankt voor de uitstekende toelichting.

Ik haalde de ps3 aan omdat dit ook een real-time raytracing systeem is.
Normaal is het een cluster van computers.
Uiteraard: hoe meer lichtstralen en weerkaatsingen hoe meer cpu's nodig zijn.

Verwijderd @Faust • 7 juli 2009 17:41

Uhmm.. tot nu toe was het nog niet echt mogelijk om real-time ray-tracing uit te voeren. EN de Cell processor nu ook weer niet zo barre snel.. Wat wel aan de interessant is aan de Cell processor is dat hij zelf zijn cores kan indelen voor wat hij het gaat gebruiken; Grafische, physics of raw cpu kracht.

Anyway, 1000Watt en 800Teraflops genereren? Heel erg knap..! 1000Watt is een rek van een SuperComputer, dat misschien net 100Teraflops haalt.

svenk91 7 juli 2009 14:42

Kan iemand uitleggen hoe dit in de auto industrie gebruikt wordt?

mooi voorbeeldje van wat met raytracing kan: http://upload.wikimedia.o...e/ec/Glasses_800_edit.png

Niemand_Anders @svenk91 • 7 juli 2009 15:04

Visualisatie van efficientie berkeningen. Dus in plaats van dure windtunnel testen kunnen ze modellen nog beter op de computer narekenen. AutoCad kan de berekening wel maken, maar daar komen alleen maar getallen uit. Nu kan de architect deze natuurlijk wel intepreteren, maar als de computer het realtime kan visualiseren is het effect groter.

De windtunnel test kan dan worden uitgesteld en dat bespaard veel geld. Ook kunnen ze dan de auto virtueel laten rondrijden in een landschap en er zullen nog tal van andere toepassingen mogelijk zijn.

Zoijar @Niemand_Anders • 7 juli 2009 15:20

Windtunnel simulaties kosten niet zoveel processortijd vanwege de visualisatie, maar vanwege de fluid-flow simulaties -- het oplossen van stelsels differentiaal vergelijkingen heeft weinig met raytracing te maken.

Het kan goedkoper zijn om je nieuwe prototype voor een auto eerst realistisch in VR te simuleren, in plaats van een fysiek foam model te maken. Het zal dus idd wel om het design process gaan. Ook zullen realistische useability studies in VR een belangrijke rol spelen, maar dat is een onderdeel van design.

ProfPi @Niemand_Anders • 7 juli 2009 15:25

Visualisatie van het ontwerp zelf ,dus voornamelijk commercieel/marketing gerelateerd.

AutoCad (e.d.) wordt in eerste instantie niet gebruikt voor de berekeningen waar jij het over hebt.

Voor stromingsberekeningen/aerodynamica/efficientie wordt CFD software gebruikt (computational fluid dynamics), zoals bijv. Fluent.

Dan worden er ook nog veel sterkte- en dynamica berekeningen uitgevoerd (trillingen, eigenfrequenties etc). Dit geschiedt met FE software (finite elements).

Die laatstgenoemde twee bieden voldoende mogelijkheden voor visualisatie van de effecten (en is ook niet buitengewoon reken-intensief vergeleken met de berekeningen die er aan voorafgaan). Daar gaat zeker geen raytracing aan te pas komen.

Verwijderd @Niemand_Anders • 7 juli 2009 15:31

OT: AutoCAD can deze berekeningen niet maken en wordt overigens niet zo veel of helemaal niet in de auto industry gebruikt, vaak gebruiken autofabrikanten Catia en/of Pre/Engineer voor het 3D werk.

Daarna wortdt het model overgezet naar een extern programma die deze flow berekeningen wel kan doen.

Grt,
Ries

lowfi @Niemand_Anders • 7 juli 2009 15:37

Autocad? Afaik kan autocad geen surface class a. Denk dat je eerder Alias & Tebis ziet bij die automakers.

Vaudtje @svenk91 • 7 juli 2009 15:22

Een simpel voorbeeld is een prerender van het interieur: weerspiegelt de voorruit het dashboard niet te veel?

YopY @Vaudtje • 8 juli 2009 00:28

Dat zou kunnen, maar dan moet je wel een simulatieomgeving hebben die de specifieke lichtomstandigheden kan nabootsen, én je moet de specifieke eigenschappen (qua licht en dergelijke) van het glas weten. Daar komt nog bij, als je de eigenschappen van het glas kent, weet je ook hoeveel het reflecteert, en aldus of hij het dashboard 'te veel' reflecteert.

Plus, glas is ouderwets, binnenkort zitten we achter een scherm te autorijden

Verwijderd @svenk91 • 7 juli 2009 14:56

Voornamelijk in het designproces lijkt me. Kans op verrassingen achteraf wordt dan nog kleiner.
Weet niet hoe het met de kleurechtheid van dit systeem zit, maar ik kan me voorstellen dat je zo heel realistisch diverse soorten lak kan uitproberen.

Durandal @Verwijderd • 7 juli 2009 21:15

Ik weet het niet maar het lijkt me toch dat een paar liter lak wat goedkoper is dan dit systeem..

Verwijderd @svenk91 • 7 juli 2009 15:20

Is die dit real-time aan het raytracen? plaatje komt super traag binnen.

Ziet er wel erg mooi uit als dit real-time kan.

ElectroDonker 7 juli 2009 14:40

leuk systeem; het lijkt me alleen weinig rendabel om voor één specifieke app. zo een nieuwe monsterchip te ontwikkelen? of wordt dit een tegenhanger van larrabee?

*miereneuken*
9 chips met elk 73 cores..? op het plaatje zie ik: 9 chips, waarbij elke chip 8 clusters van 8 chips behuist (=64 cores, ook iets logischer aantal want een macht van 2)

Decalies

@ElectroDonker • 7 juli 2009 14:43

Er zijn toch heel wat toepassingen te verzinnen waar dit nuttig voor zou zijn. Allerlei productontwikkelingen (industrial design, medische toepassingen?) kunnen hier gretig gebruik van maken.
En voor de entertainment markt zou dit ook wel eens heel wat waard kunnen worden.

YopY @Decalies • 8 juli 2009 00:25

Dat zeg je nu wel, maar die redden zich op het moment immers ook met low-res renders tijdens het ontwikkelen om later een high-res render (evt met ray tracing) te doen? Daar heb je volgens mij geen realtime raytracing voor nodig. Wat dat aangaat denk ik ook dat dit eerder voor demo's is van (bijvoorbeeld) games of gewoon als demonstratie.

J__F__K__ @ElectroDonker • 7 juli 2009 14:43

Er staat dan ook bij:

Nine heterogeneous cores...
64 + 9 = 73

Klopt dus waarschijnlijk wel!

Pmf1971 @J__F__K__ • 8 juli 2009 05:15

nee denk toch een rekenfout.

7 van de 8 clusters hebben 9 cores. 7x9 = 63, plus 1 risc core = 64 cores per CPU.

9 cores, 64x9 = 576 cores.

[Reactie gewijzigd door Pmf1971 op 22 juli 2024 20:36]

Verwijderd @ElectroDonker • 7 juli 2009 14:44

hoezo? in de toekomst gaan we (speculatie) raycasting gebruiken voor 3d, in plaats van rasterization

over 10-15 jaar word dit waarschijnlijk de nieuwe generatie grafische kaart

MrSnowflake @Verwijderd • 7 juli 2009 15:02

Dat is waar, maar ik denk dat hij meer doelt op het feit dat huidige gpu's ook instaat zijn andere berekeningen te doen als alleen grafische toepassingen. Iets wat de larrabee ook kan, maar dit exemplaar niet.

Natuurlijk is het zo dat de eerste 3D versnellers ook alleen maar 3D konden versnellen en dat zal bij dit soort hardware ook wel zo zijn dat een volgende generatie ook voor andere doeleinden gebruikt kan worden.

Rudie_V @ElectroDonker • 7 juli 2009 14:46

Volgens mij is dat hele plaatje 1 CPU. Elke 'core' die je onderaan ziet bestaat weer uit 9 cores. 8*9=72 plus 1 RISC core voor de verdeling van de taken maakt 73.

piderman @ElectroDonker • 7 juli 2009 14:47

8 clusters, 9 cores (0-7 en de memory management), plus nog een losse 64-bit RISC core, 9x8+1 = 73 cores

En met dit soort speciale chips hoef je echt geen tweemacht meer te hebben hoor. Ze stoppen er gewoon op wat ze nodig hebben, wat een beetje op zo'n die past.

Antipater @ElectroDonker • 7 juli 2009 22:45

Die ene specifieke app is wel een vrij prijzige aangelegenheid. Het renderen van animaties gebeurd op speciale renderfarms met niet bepaald goedkope clusters, en duurt dan alsnog vaak weken. Dan heb je nog de hele design wereld en medische toepassingen. Bij elkaar gaat dat om vele miljarden, veel meer dan de gameindustrie bijvoorbeeld. Als ze ook maar een beetje succes hebben zal het echt wel rendabel zijn.

RalphM. 7 juli 2009 14:45

Dus Pixar krijgt binnenkort nóg mooiere films?

QinX @RalphM. • 7 juli 2009 14:51

Ray tracing was het al, het verschil met deze oplossing is is dat het realtime is. Volgens mij worden veel Pixar films al met ray-tracing gemaakt alleen duurt het heeeeeeel erg lang om de uiteindelijke film te renderen.

Deze oplossing maakt het dus alleen sneller en dus makkelijker op ray-tracing toe te passen.

Verwijderd @QinX • 7 juli 2009 14:56

dat klopt, een frame van finding nemo kostte gemiddeld 22 uur om te renderen, en ze gebruikten niet de minste CPU's

Verwijderd @Verwijderd • 7 juli 2009 15:27

lijkt raar maar ik zag deze regel:

Het kostte wel vier dagen om sommige beeldjes van de film te renderen. De oorzaak daarvan is de complexe onderwaterwereld en de lichtinval van de zon, die geheel berekend moet worden.

Oguz286 @Verwijderd • 7 juli 2009 15:05

Is dat niet heel erg veel? Een uur film met 25 fps (PAL) zou dan:
25 * 60 * 60 * 22 = 1.980.000 uur duren en dat zou:
1.980.000 / ( 24 * 365 ) ~= 226 jaar duren. Of ik doe iets fout of je bedoelt per cpu 22 uur (of 22 uur per seconde) geloof ik.

[Reactie gewijzigd door Oguz286 op 22 juli 2024 20:36]

Verwijderd @Oguz286 • 7 juli 2009 15:14

ik zoek de bron wel even op, momentje

edit:
During his keynote here today, Brandeau explained that Cars, which is slated for a June release, has put more strain on his internal systems than any other movie, swallowing up a colossal 2,300 CPU years over the course of the last five years. In other words, in Brandeau's view, a single CPU would have to run for 2,300 years in order to do all the number crunching for this movie.
http://www.byteandswitch..../infrastructure/pixar.php

dit is de goede bron, interessant leesvoer:

http://www.codinghorror.com/blog/archives/001073.html

edit: er staat dat de "juggler", de eerste raytracing demo pas in 2005 realtime gerendeerd kon worden (30 fps)

[Reactie gewijzigd door Verwijderd op 22 juli 2024 20:36]

Verwijderd @Oguz286 • 7 juli 2009 15:23

waarschijnlijk wel per processor (niet per se CPU). Over Transformers 2 - Revenge of the Fallen

A single IMAX shot in the movie (df250) would have taken almost 3 years to render on a top of the line home PC running nonstop. If you rendered the entire movie on a modern home PC, you would have had to start the renders 16,000 years ago (when cave paintings like the Hall of Bulls were being made) to finish for this year's premiere.

J.J.J. Bokma @Oguz286 • 7 juli 2009 16:03

Met 226 computers breng je dat al terug naar 1 jaar.
Met 1000 computers naar een paar maanden. Ze spreken dan ook van een renderfarm.

MrSnowflake @QinX • 7 juli 2009 15:04

Vergeet niet dat pixar films niet gewoon 3d modelletjes gebruikt die ook in Crysis zitten of zo, maar een veel hogere polygon count hebben als die modellen. Althans, dat lijkt me logisch, ik heb hier nl geen bronnen over.

Verwijderd @MrSnowflake • 7 juli 2009 18:35

Dat valt best mee hoor, Pixar's software genaamd 'Renderman' zorgt er tijdens het renderen voor dat er over het gehele object een soort van smoothing komt, lees vertienvoudiging van het aantal polygonen. plus nog normal en displacement maps en je zal niet veel meer polygonen hebben dan een character uit crisis.

questo @QinX • 7 juli 2009 14:57

Dan denk ik nog dat Pixar mooiere films gaat krijgen. Ze zouden op deze manier sneller kunnen ray-tracen. De laatste jaren zagen we bij Pixar steeds dat als het sneller kon, dat het steeds gedetailleerder werd.

ultimasnake @RalphM. • 7 juli 2009 15:25

Zoals ze al zeggen ,ray-tracing deden ze al. Je zou eens de orginele dvd/special dvd editie van Monster inc moeten kijken. Daar zit een special in over de techniek er achter en hoe lang het wel niet duurt. En nog leuker, de fouten die ze soms maakte in hun models/raytracer waar ze dus pas achter kwamen nadat de scene was gerenderd op hun hun farms

SlasZ @RalphM. • 7 juli 2009 15:41

Ik denk dat de renderfarm die Pixar gebruikt toch wel krachtiger is dan dit en dat ze ook real time kunnen raytracen, enkel niet met dezelfde precisie als hun films. Raytracen & raytracen zijn 2, je kan heus raytracen met de huidige GPU's alleen zal het niet zo realistisch zijn als met de PC van het artikel. Maar je kan evengoed scene's maken die met die nieuwe PC niet realtime te tracen is.

Snoitkever

@RalphM. • 7 juli 2009 17:08

Ik weet niet waar iedereen hierboven het over heeft, maar Pixar maakt nog maar sinds kort gebruik van ray-tracing, en gebruikt nog steeds een hybride aanpak, omdat ray-tracing gewoon duurder is dan scanline rendering. Pas bij Cars (2007) zijn ze overgestapt op (hybride) ray-tracing vanwege alle reflecties in die film, maar alle films voor die tijd zijn gewoon scanline rendering.

Jeanpaul145 @RalphM. • 7 juli 2009 15:02

Wat QinX al zei. Pixar maakt dus niet nog mooiere films (ok, misschien wel een klein beetje mooier), maar vooral meer films als ze dit systeem aanschaffen, denk ik.

!null 7 juli 2009 14:47

IBM was toch ook goed mee op weg? IBM werkt hiervoor met Cell processoren. Zo is er een filmpje online, waarbij ook realtime ray-tracing wordt gedaan, maar dan met behulp van 15 PS3's. Even snel rekenend zouden dat ongeveer 105 of 120 cores zijn. Maar dan heb je het over allemaal 2.7Ghz PPC cores (dat zijn de cores binnen een Cell processor).
Dan ga je je afvragen wat hier de cores voorstellen, maar gezien het 'negen' verhaal denk ik eigenlijk aan hetzelfde type Cell processoren. (en daar dus ook weer 9 van)

Snoitkever

@!null • 7 juli 2009 17:20

Volgens mij lijkt dit helemaal niet op Cell. Cell is 1 general purpose CPU met 8 SPUs er omheen die zwaar rekenwerk kunnen uitvoeren maar verder heel primitief zijn. Dit systeem heeft 9 chips, met een volledige 64-bit RISC processor op elke chip en vervolgens 8 clusters met zeer gespecialiseerde cores voor hele specifieke ray-tracing berekeningen. Dit systeem is dus veel en veel complexer, en heeft (afaik) weinig met Cell gemeen, behalve dat het een multicore chip is (en dat zegt tegenwoordig niet veel meer)

Verwijderd 7 juli 2009 14:40

Ik weet nog wel vroeger hoe ik op m'n 486 met povray simpele bollen aan het raytracen was en maar wachten, wachten..... wachten. Was wel altijd spannend hoe de objecten er uit zouden komen te zien.