Intel stelt Havok-software gratis beschikbaar

Intel stelt zijn Havok Complete-software, waarmee physics en animaties voor games ontwikkeld kunnen worden, in het voorjaar gratis beschikbaar voor niet-commerciële toepassingen.

De software, bestaande uit de Havok Physics-engine en het animatieplatform Havok Animation, komt volgens Havok in mei als download beschikbaar. Het bedrijf, dat afgelopen september in handen kwam van Intel, stelt dat zijn software vooral geschikt is voor het ontwikkelen van crossplatform-games. De technologie zou reeds in tweehonderd commerciële titels zijn toegepast, waaronder Halo 3, Bioshock en Half Life 2: The Orange Box.

Behalve voor niet-commercieel gebruik maakt Havok zijn softwarepakket ook gratis beschikbaar aan een aantal niet nader genoemde pc-ontwikkelaars. Developers die het Havok Complete-platform willen inzetten voor het bouwen van consolegames moeten echter nog wel licentiegelden aan de firma afdragen, zo benadrukt Havoc.

Havok leek met de plannen voor zijn Havok FX-engine aanvankelijk een concurrent te worden voor de hardwarematige physics-versneller Physx van Ageia. In tegenstelling tot Ageia's Physx-insteekkaart, die een aparte physicsprocessor gebruikt, koos Havok ervoor om de rekenkracht van de gpu te gebruiken. Maar ook in dit marktsegment moest Havok het opnemen tegen het door Nvidia ingelijfde Ageia; met het gpgpu-systeem Cuda van Nvidia wordt het voor ontwikkelaars mogelijk om physicsberekeningen door de gpu uit te laten voeren.

Door de overname van Intel is het echter stil geworden rondom de Havok FX-engine; de firma lijkt zich nu vooral te willen richten op het doorontwikkelen van zijn software development kits. Zo introduceerde het bedrijf deze week nog de Havok Cloth- en Havok Destruction-sdk's, waarmee kleding voor karakters en kwetsbare objecten ontworpen kunnen worden.

Reacties (52)

[Meelobee]

Waarom wordt het berekenen van Physics zo gepushed naar de Grafische kaarten?
In mijn systeem is m'n videokaart in nieuwe spellen (UT3 bijvoorbeeld) behoorlijk druk met het op het scherm toveren van de beelden, terwijl m'n Q6600 slechts 2 van de 4 cores op 40% belast. Zou het dan niet slimmer zijn om de physics door de CPU te laten berekenen?

[Verwijderd]

nee, gpu's (die dingen op beeldkaartjes dus) kunnen ook die physics berekeningen veel efficienter maken dan een x86 cpu die op veelzijdigheid is gebouwt. Vooral Nvidia kaarten vanaf die 8 serie hebben hier extra technologie onder andere in de vorm van instructiesets voor aan boord.

edit, meer nuttige info erbij gedaan

[Reactie gewijzigd door Verwijderd op 24 juli 2024 05:54]

[chrisO]

Maar voor de meeste pc's is de grafische kaart toch echte de beperkende factor bij het spelen van games...terwijl be de meeste pc's met dualcores/quadcores 1 of meerdere cores lopen te niksen... Dat een grafische kaart beter physics kan berekenen dan een cpu is leuk....maar wat is het nut om de beperkende factor nog meer de beperkende factor te laten zijn?

En een oude gpu/videokaart gebruiken als kaart voor physics zal slechts door een klein percentage van gamers gedaan worden....

[Zarkov]

Vraag je nu echt wat het nut is voor een grafische kaarten fabrikant om zijn/haar grafische kaarten nog zwaarder te belasten? Ik snap dat het voor de multi core bezittende consument niet handig is. Echter Nvidia zal echt alleen maar lachen als men besluit een zwaardere grafische kaart te kopen om dat ene extra blikje bonen op een realistische wijze te zien kreukelen in generic over the top FPS nr 147.

[QkE]

Je moet net als die man met de gouden boot GROOT denken of in dit geval aan de toekomst. Waarschijnlijk wordt het steeds normaler om 2 videokaarten in je systeem te hebben (eventueel 1 ingebouwde). Net zoals videokaarten zelf vroeger alleen voor de happy few was weggelegd denk ik dat ook deze ontwikkeling zich snel zal verspreiden onder de mensen die minder geld kunnen of willen besteden aan dit soort onzin.

Mooie toekomstvisie (bonus): Windows dat gebruik maakt van physics Een window dat in particles uiteenvalt en in een 3D wervelwind verdwijnt naar de taakbalk.

[Reactie gewijzigd door QkE op 24 juli 2024 05:54]

[Fireshade]

Waarschijnlijk wordt het steeds normaler om 2 videokaarten in je systeem te hebben

Sterker nog, het wordt al sneller normaler om 1 videokaart met multiGPU of zelfs multicore in je systeem te hebben.
Over een paar jaar is physics in je office PC net zo normaal en voor de hand liggend als erop DVD'tjes kunnen afspelen. Dus waar malen we nou om?

[Reactie gewijzigd door Fireshade op 24 juli 2024 05:54]

[Verwijderd]

Physics op je homepc ok, maar op een office pc? Denk 't zomaar van niet. Sommige bedrijven willen niet eens een geluidskaart (als ie al niet onboard zit).

[Verwijderd]

Daar is voor office toepassingen ook geen reden voor.

Voor een PPU volgens mij ook niet maar misschien kan iemand er binnenkort een goede toepassing voor verzinnen.

[Verwijderd]

De CPU's die lopen te niksen worden niet benut door de game of programma. Singlecore progsels zijn er zat, multi helaas minder dan dat er x64 bit drivers beschikbaar zijn.

[Verwijderd]

nee, gpu's (die dingen op beeldkaartjes dus) kunnen ook die physics berekeningen veel efficienter maken dan een x86 cpu die op veelzijdigheid is gebouwt.

Veelzijdigheid is een voordeel, geen nadeel. Het maakt de CPU niet minder efficient, in tegendeel. Kijk even naar GPGPU projecten en je ziet dat CPUs zéér regelmatig de GPU verslaan (zeker sinds de opkomst van multi-core). De GPU is juist niet-veelzijdig, en maakt enkel brokken met grafische toepassingen of zaken die daar onmiddelijk van afgeleid zijn. Dit is dankzij z'n texture sample units. Voor physics is hij daar echter niks mee.

Vooral Nvidia kaarten vanaf die 8 serie hebben hier extra technologie onder andere in de vorm van instructiesets voor aan boord.

Je laat je vangen door marketing-praat. De SSE vectorinstructieset van x86 CPUs is vergelijkbaar met die van Shader Model 4.0. Er ontbreekt geen enkele instructie om efficient physics te berekenen. Of heb jij er dan een gevonden?

[ocdaan]

Een GPU is daar vele malen beter geschikt voor zover ik weet, mede door de hoge floating point berekeningen....

Persoonlijk vind ik het wel een goed idee, straks een ouwe gforce (of radeon) ernaast speciaal voor de physics!

[Reactie gewijzigd door ocdaan op 24 juli 2024 05:54]

[.oisyn]

Niet door de vele floating point berekeningen an sich, maar door het feit dat er heel veel dezelfde berekeningen gedaan moeten worden. Daar is een GPU uitermate geschikt voor, omdat hij met veel stream processors (threads) dezelfde shader (programmacode) in parallel uitvoert.

Was het echter één grote berekening geweest waarvan verschillende delen niet goed parallelliseerbaar zijn, dan is een hedendaagse x86 CPU daar veel beter in dan een GPU. Het gaat dus echt om de parallelliseerbaarheid waardoor de GPU het uiteindelijk wint van de CPU.

Een GPU kan dus doorgaans meer FLOPS (Floating point operations per second), maar een enkele FLOP is op een CPU wel sneller dan op een GPU

[Reactie gewijzigd door .oisyn op 24 juli 2024 05:54]

[Verwijderd]

Een GPU is daar vele malen beter geschikt voor...

Helemaal niet. Een GPU is enkel geschikt om zeer veel onafhankelijke elementen te verwerken. En bij physics gaat het juist om de interactie.

...mede door de hoge floating point berekeningen....

Een 3 GHz Core 2 Quad kan meer floating-point berekeningen dan een GeForce 8600 GT. Dus ook voor de rekenkracht hoef je physics niet op de GPU te doen (een GPU is alleen véél sneller voor graphics dankzij de texture samplers).

[SG]

Juist daar is de PPU beter in. De interne bandwidth is zelfs veel groter dan die van de CELL CPU. Ideaal voor Physics.
CPU valt af aangezien parralelisatie maar tot 4 is.
GPU van 64 tot 320 shaders als we budged en high-end en ATI ook bij betrekken.
GPU beat CPU al op parralellisatie.
Branching is de b

De Extreem edition moet dus (128 div 4) maal zo krachtiger zijn per Core tov een unified shader. Om 'n G80U te kloppen

[Snoitkever]

Zeggen dat het aantal parallele berekeningen bepaalt hoe goed een platform is voor physics is hetzelfde als zeggen dat de hoeveelheid MHz waarop een chip draait bepalend is voor de mogelijkheden.

Er zijn zo vreselijk veel verschillen tussen CPU, GPU en PPU dat je niet zomaar een vergelijking kan gaan maken. Elk gaat anders om met geheugen, clocksnelheden, operaties per clock, threads per core, communicatie tussen cores, etc.

[Verwijderd]

CPU valt af aangezien parralelisatie maar tot 4 is.

Da's een overhaaste conclusie. De kloksnelheid van de CPU is vele malen hoger dan die van AGEIA's PPU. Bovendien heeft Intel al roadmaps tot 32 cores. Enig voordeel van andere architecturen is van relatief korte duur.

[Innsewerants]

wat is nou sneller voor de physics een tweede geforce 8 series (niet zo dol op dat idee tbh)
of zo'n physx dedicated kaartje van ageia (120,- pricewatch)?

[Verwijderd]

Een Geforce 8 is veel sneller dan zo'n Ageia kaart.

ATI heeft al een keer gedemonstreerd dat hun X1600 enige malen sneller is dan die Ageia kaart... En de X1600 is nou niet bepaald een snelheids monster meer...

[SG]

Welke test?

Appels met peren vergelijken.

Met 768mil vs 125 transistoren heeft G80 natuurlijk de upperhand.
Alleen Dit kan tot op heden niet direct getest worden. Alleen geschat worden.

Zodra GPU support in PhysX zit en PPU support gebleven is kan je dat 130nm ding vergelijken direct in de zelfde app met diezelfde load. met dezelfde neven balast tegen 'n nV G92 op 65nm.

Dat lijkt mijn zeer interreresant.

Afhankelijk hoeveel transistoren die 128shaders in nemen en controle logic.
schat in zo'n 350mil uit 680mil en 3x zo hoge clock.
Verwacht je raw zo'n 6x de performance.
Als het 2x blijk te zijn is GPGPU toch wel de mindere.

Zou dus eerst willen weten hoe PPU vs GPU maar ookj vs CPU vs CELL verhoudt.

[Verwijderd]

Wie zegt dat een andere PPU sneller moet zijn dan zo'n Ageia kaart? Nu de markt nog zo weinig voorstelt (incl. gebruik van physics in games) hebben we nu echt wel genoeg aan zo'n Ageia kaart. Dus laat die specs maar achterwege denk ik dan.

[Verwijderd]

Een Core 2 Quad.

[SG]

PPU beats CPU en G80/G92 beats PPU.
Nog beter 'n 9800gtX2 voor renderen en 'n 9800gtX2 voor PhysX.
Vraag me af PhysX ook SLI PhysX ondersteuned.

Waarbij de PPU de betere oplossing is.
Alleen niet in 45nm 1miljard transistoren en 2GB versie niet lever baar.
Zal door nV overname dus ook nooit komen.
Alleen 1,5 jaar oude 130nm 125Miljoen chipje. Kwa procede tegen hanger van T-bred of Northwood, Tulatin, nV40

[Verwijderd]

In UT3, als je geen gebruik maakt van een Ageia kaart, dan word het softwarematig gedaan dus dan heeft je videokaart en CPU het er maar druk mee. Overigens op een dual core CPU is de belasting continu 100% en dat blijft een uurtje leuk draaien maar daarna krijg je al objects die onzichtbaar worden. Moet er wel bij zeggen dat het op een 8800gts320 gebeurd dus het is geen super game PC maar de belasting is erg hoog, met details ingame een tandje teruggeschroefd. De bitmaps zien er dan ook niet echt uit.

Maar goed om te zien dat Intel het vrijgeeft, zo kan je dus ook in gewone software misschien wat meer kanten op en word het voor developers wat goedkoper om het te implenteren/tweaken

[Verwijderd]

Dat Intel het vrijgeeft zal meer in het kader van meer gerelateerde verkoop zijn. Vaak betekent naamsbekendheid meer verkoop in de commerciële wereld. Dus Intel heeft er meer dan een beetje baat bij dat dit vrij wordt gegeven voor niet-commercieel gebruik.

[R-O-Y]

Een GPU of PPU kan tot wel 40000 objecten tegelijk uitrekenen. Een CPU niet. Kijk maar naar bvb de 3dmark cpu test. Een cpu is general purpose en dus niet erg geschikt voor physics.

[Verwijderd]

Een GPU of PPU kan tot wel 40000 objecten tegelijk uitrekenen.

En dat noem je veel? Een 3 Ghz Core 2 Quad kan 96 miljard floating-point bewerkingen per seconde. Die 3DMark test is totaal ongeoptimaliseerd voor moderne multi-core processors.

Een cpu is general purpose en dus niet erg geschikt voor physics.

Een CPU heeft SIMD floating-point eenheden, net zoals de PPU en GPU. Er is niks dat ontbreekt om physics te doen. Of ken jij een speciale bewerking die een PPU of GPU sneller kan door special-purpose rekeneenheden?

[Verwijderd]

Kan je er meteen even bij vermelden hoeveel floating point operations een beetje physicsberekening is? Anders slaat je vergelijk van 40.000 objecten (zonder tijdseenheid) en de 96 miljard FLOPS helemaal nergens op.

En een PPU of GPU is niet sneller doordat er speciale rekeneenheden in zouden zitten oid maar doordat er tientallen/honderden eenheden parallel werken in plaats van 4.

[Verwijderd]

Kan je er meteen even bij vermelden hoeveel floating point operations een beetje physicsberekening is?

Véél minder dan 2400000.

En een PPU of GPU is niet sneller doordat er speciale rekeneenheden in zouden zitten oid maar doordat er tientallen/honderden eenheden parallel werken in plaats van 4.

Kijk even verder dan enkel het aantal cores man. Een Core 2 heeft drie vectoreenheden per core en een meer dan dubbel zo hoge kloksnelheid. Een GeForce 8600 GTS heeft 32 scalaire shader units. Kijken we naar het aantal multiply-add bewerkingen dan komt een 3 GHz Core 2 Quad op 96 GFLOPS en een GeForce 8600 GTS op 92.8 GFLOPS.

Reken daar nog even bij dat een GPU gebonden is aan tientallen threads die synchroon dezelfde bewerking moeten uitvoeren, en geen ondersteuning heeft voor een scatter bewerking, en je ziet snel in dat de CPU veel beter geschikt is voor physics.

[OruBLMsFrl]

Blijft natuurlijk de vraag of je 40.000 objecten nodig hebt om je spel meer realisme mee te geven. In de ene hoek heb je nu erg simpele modellen die op de CPU nauwelijks tijd vragen en in de andere hoek zeer complexe modellen waar een aparte kaart voor nodig is. Ik denk dat met een extra core wel degelijk wat mooiere en realistischere physics op het scherm te toveren vallen dan nu het geval is.

[Verwijderd]

Sure, altijd handig. Die limieten zijn altijd te doorbreken. Bv. dan met veel beter gesimuleerd water. Vele particles.
Ik geloof wel dat het voornamelijk in dat soort dingen moet zitten; kleine extra zoals rondvliegende puinstukken, regen, sneeuw, rook, water, vuur etc. Voor animatie is de GPU ook wel bruikbaar maar of dat nou allemaal zoveel winst oplevert...
Ben zelf met een game bezig en daar is ondanks 1000Hz physics en vele sinussen etc toch echt de gfxcard de dikke bottleneck met meestal 90% tov 10% CPU.

[Tiny]

Wat het als mogelijkheid bied is bijvoorbeeld een muur te maken die echt uit losse objecten bestaat, ipv. een voor gedefineerde waar je door heen kunt breken.

[elmuerte]

Een GPU of PPU kan tot wel 40000 objecten tegelijk uitrekenen.

Daar geloof ik dus absoluut niks van. Het is al een prestatie als een synchrone processor 2 berkeningen tegelijk kan verwerken per cycle.

[Mitsuko]

Dat is het punt ook juist, al die shaders die GPUs hebben zijn een soort van mini-processors. Zeker met de nieuwste generaties kaarten kunnen ze behoorlijk veel, en zijn ze dus uitermate geschikt voor physics rendering. Natuurlijk is een dedicated PPU waarschijnlijk nog beter, maar met hybrid SLI enzo wordt het steeds makkelijker om je GPUs ervoor in te zetten.

[R-O-Y]

Kijk hier maar:

http://www.xbitlabs.com/a...isplay/ageia-physx_2.html

"Up to 533 thousand of more complex collisions"

Zijn er zelfs nog meer dus Het zijn zeer specifieke dingen waar een GPU of PPU uitermate geschikt voor is.

[SlasZ]

Je vergeet het belangrijkste: per seconde.
Dat is dus niet simultaan.

[R-O-Y]

Klopt, maar het zijn er ook een stuk meer dan 40000 Het punt is dat een PPU hier echt vele malen sneller in is. Dan praat je niet over 10x zo snel als een CPU maar gewoon een stuk meer. Dat is dus erg leuk om heel erg realistische spellen te maken. Ik hoop ook dat er binnenkort spellen komen waarbij je met een extra videokaart physics kan uitrekenen Lijkt me erg leuk om te zien.

Hoe vaak wil je hetzelfde object eigenlijk uitrekenen per seconde? Dat vraag ik me nu eigenlijk wel af. Net zo vaak als de framerate?

edit: ik weet wel hoe je aan je framerate komt hoor. Stel je hebt 60fps. Wordt elk object dat de PPU uitrekent dan ook 60 keer per seconde berekend? Dat is meer wat ik me afvraag. Dan zou je namelijk heel makkelijk aan dat grote aantal objecten kunnen komen.

[Reactie gewijzigd door R-O-Y op 24 juli 2024 05:54]

[SlasZ]

Dan heb je het verkeerd voor.
Ziehier hoe een game werkt (simpel):

a) vraag aan de PC wat de gamer als invoer geeft (bewegen muis, ...)
b) bereken de dynamische eigenschappen van de wereld (bewegende objecten, physics, ...). Dit gebeurt nu op de physics processor in parallel.
c) Het spel wacht op de resultaten van die physics processor, intussen doet het andere dingen (zoals geluid, ...)
d) Bereken hoe de wereld er nu uit ziet afhankelijk van de invoer (beweeg camera, vuur kogel...)
e) doe texturing, shading, ...
f) toon het resultaat op het scherm.
g) ga terug naar a) tot het spel stopt.

Ik heb al lang niet meer aan games geprogrammeerd maar zo iets zal het zijn.
Hoe sneller je van a) naar f) kan gaan hoe hoger je fps.

[Reactie gewijzigd door SlasZ op 24 juli 2024 05:54]

[Punkie]

@SlashZ
Er zijn ook modellen waarbij de gehele gameloop zoals jij die beschrijft, opgesplitst wordt in 2 welke asynchroon tov lopen. De eerste loop berekent de wereld, de 2e berekent het uitzicht op de huidige wereld (de output) en tevens ook de input). De eerste loop heeft prioriteit en wordt gegarandeerd x maal uitgevoerd per tijdseenheid. Dit model geeft garanties dat de wereld altijd synchroon wordt gehouden en gemakkelijker te berekenen valt ondanks de haperingen in de schermtoevoer/inputlag, netwerk instabiliteit,...

@roy
een cpu doet amper 2 instructies per cycle, met miljoenen cycles per seconde. Een GPU kan veel meer instructies (architectuurafhankelijk, vb200) per cycle doen op eenzelfde frequentie. Daarom is het berekenen van de physics op een gpu gemakkelijk een factor 100 sneller. Je gpu 1% minder belasten zou de cpu overbelasten.

[Reactie gewijzigd door Punkie op 24 juli 2024 05:54]

[SlasZ]

Kan goed zijn
Punt is dat de physics processor niet gaat kijken hoeveel FPS er nu gehaald worden en aan de hand daarvan dan bepaald hoeveel keer hij de dingen moet berekenen.

[.oisyn]

edit: ik weet wel hoe je aan je framerate komt hoor. Stel je hebt 60fps. Wordt elk object dat de PPU uitrekent dan ook 60 keer per seconde berekend? Dat is meer wat ik me afvraag. Dan zou je namelijk heel makkelijk aan dat grote aantal objecten kunnen komen.

Nou is het ten eerste niet raar om de physics timestep onafhankelijk te laten zijn van de render timestep (dus 60 FPS wil niet per se zeggen dat de physics engine ook 60 keer per seconde z'n berkeningen doet - hij kan ook op solid 20 FPS werken met interpolaties tussen de "physics-frames" voor rendering), maar 't is natuurlijk ook een beetje marketing-gewauwel. Net als dat een renderer niet alle objecten tekent die in de wereld zijn maar alleen dat deel waarvan hij snel kan bepalen dat ze mogelijk zichtbaar zijn, rekent een physics engine ook alleen maar collisions uit voor objecten die mogelijk gaan colliden. Dus bijvoorbeeld tussen twee objecten in beide uiteinden van je wereld zullen geen collision berekeningen worden gedaan. Op die manier is het mogelijk om duizenden zoniet miljoenen objecten in de wereld te hebben zonder dat het echt een gigantische performance bottleneck wordt. Het wordt natuurlijk wat anders op het moment dat die objecten zich allemaal ongeveer op dezelfde plek bevinden

[Reactie gewijzigd door .oisyn op 24 juli 2024 05:54]

[Ruben314199]

@R-O-Y

Hoe vaak wil je hetzelfde object eigenlijk uitrekenen per seconde? Dat vraag ik me nu eigenlijk wel af. Net zo vaak als de framerate?

Dat hangt helemaal af van de hoeveelheid botsingen en interacties tussen de objecten en het gebruikte intergratie schema / botsing detectie.

Voor een simpele vallende kist heb je genoeg aan 25 stappen per seconde.

[Reactie gewijzigd door Ruben314199 op 24 juli 2024 05:54]

[SlasZ]

De framerate wordt bepaald door wat je allemaal berekent en hoe snel die zijn...
Hoe meer je berekent hoe lager de framerate.

[Reactie gewijzigd door SlasZ op 24 juli 2024 05:54]

[Verwijderd]

Waarom wordt het berekenen van Physics zo gepushed naar de Grafische kaarten?

Omdat NVIDIA hopeloos op zoek is naar zogezegd rekenintensieve zaken waardoor mensen een krachtiger (duurder) grafische kaart zouden kopen. De algemen trend is echter dat meer en meer mensen tevreden zijn met een geïntegreerde GPU (van Intel onder andere) of een low-end kaartje, en single-core CPUs zo goed als van de markt verdwenen zijn...

Zou het dan niet slimmer zijn om de physics door de CPU te laten berekenen?

Ja. Daarom juist dat Havok zich tot de CPU blijft beperken.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 05:54]

[roy-t]

Hmm Havok icm XNA (zie andere nieuwsitem) scheelt je meteen je eigen physisc coden :-)

[Verwijderd]

Dat hoefde je sowieso al niet te doen, er waren al aardig wat physics libraries beschikbaar, sommige zelfs open source (zoals ODE). Maar meer keus is natuurlijk altijd beter.

BTW waarom staat er een plaatje van die nvidia chick bij dit artikel op de frontpage? Het gaat over een concurrerende physics library, niet Aegia/NVidia.

[WeeJeWel]

Niet voor game devs die hun spel daadwerkelijk uitgeven. Dit is voor non-commercial doeleinden

[Reactie gewijzigd door WeeJeWel op 24 juli 2024 05:54]

[Daikiri]

Terugkomende op de nodige berekeningen voor physics, .

zoals hier als werd genoemd, de physics kunnen en zijn ook al gewoon fps onafhankelijk.

standaard in 3d aplicaties staat dit op 1x per frame, je kan het ook nauwkeuriger laten berekenen, . Maar je kan er vanuitgaan dat men gewoon 20 of 25 fps hiervoor zal hanteren. Meer fps leverd gewoon niet echt veel beters op, en is daarom dus geheel onnodig.

Het is belangrijker om zoveel mogelijk collisions aan te kunnen.
Nu is het nog wachten op een enkel ding in video gymes, en dat is realtime fluid symulatie.

Dan gaan we allemaal games met water krijgen

[Verwijderd]

Intern moet je wel wat meer dan 25Hz draaien wil je dingen als collisions normaal resolven. Grand Prix 4 deed dan misschien z'n physics op 25Hz, maar tegenwoordig moet je al snel richting 100Hz voor het leukere spul.

[Verwijderd]

De source graphics engine, de havok physics engine.