Go With The Flow: Fluid and Shooter - Q-Gamesfumufumu.q-games.com/gdc2010/shooterGDC.pdf · Go With The Flow: Fluid and Particle Physics in PixelJunk Shooter Jaymin Kessler Q-Games

Go With The Flow: Fluid and Particle Physics in PixelJunk Shooter

Jaymin KesslerQ-GamesTechnology Teamjaymin+gdc@q-games.com

Shooter overview Game designed around mixing of various

solids, liquids, and gassesMagma meets water, cools, and forms rockIce meets magma and meltsMagnetic liquid meets water to form a toxic gas, just

like in real lifeLasers melt ice and rock into water and magmaOther cool effects like explosion chain reactions,

and water turbulence

Video ( for those who haven’t played it yet )

Video ( for those who haven’t played it yet )

Overview

SPU based fluid simulationParallel particle sim algorithms Game design built around mixing of different fluidsUniversal collision detection mechanismParticle flow rendering

Collision detection by distance fieldReal-time SPU and GPU algorithms

Level editing via stage editorTopographical design via templatesParticle placement

Existing fluid simulation algorithms

Smoothed particle hydrodynamicsDivide the fluid into particles, where each has a smoothing lengthParticle properties are smoothed over smoothing length by a kernel functionParticles affected by other particles close bySPH formulation derived by spatially discretizing Navier-Stokes equationsUsed in astrophysics!

What we actually used

Goal: practical application in-gameEase of implementationRapid control responsePhysical accuracyCater to the strengths of the SPUs

No SIGGRAPH framerates

Fluid system developed for Shooter2D particle collision simulation32,768 particles running @ 60fps on 5 SPUs (could have done way more if needed ;) )

Verlet integration

The good4th order accurate ( Euler is 1st )Greater stability than EulerTime-reversibility

The badBad handling of varying time stepsNeeds 2 steps to start, start conditions are crucial

Time-corrected verlet helps

The version we used

Applied to elemental particle sim

location p(t) as a function of time t against velocity v(t) and ext force F(t)

For mass m and sim interval ∆t

p(t+∆t) = p(t) + v(t)∆t + F(t)∆t2 / 2mv(t) = ( p(t) – p(t–∆t) ) / ∆t

!""#$"#$"! %&'()*+,-./0112(3!"#$%%456/75789:;&'( <

!"#$#%&'"()'*&+,"#(-+$."'&+/%

0 1(2+$3"#(4#*"#&(+%&#5*'&+/%(+2('33"+#6(&/(3*/6.,#('%(

#"#$#%&'"(3'*&+,"#(3782+,2(2+$."'&+/%

%=32&>)(.)1>=2&1,.!?"@.&A.('B3(AA(C.=A.=.D+,>2&1,.1D.2&E(.".F.=G=&,A2.H()1>&2I.#?"@.=,C.('2(3,=).D13>(.$?"@

J %=32&>)(.E=AA.%

J /&E+)=2&1,.&,2(3H=).!"J !?"K!"@.L.!?"@.K.#?"@!".K.$?"@!"!.$.!%J #?"@.L.?.!?"@.J.!?"J!"@.@.$.!"

!?"K!"@!?"@!?"J!"@

$?"@#?"@ #?"K!"@

Incompressibility of liquid Liquids don’t compress or expand to fill

volumes, but... In our model, mass and gravity can compress

lower particles Don’t worry! We have a fix

-':6("//&'1

==

Maintaining the incompressibility of liquid

Must maintain constant distance between particles

Particles have an adjustable radius bias Each frame:

Calculate the desired radius biasBased on max ingression of surrounding particles

Lerp from current bias to desired biasTwo different rates for expanding and contractingContraction ~4x faster than expansion

Maintaining the incompressibility of liquid

7>-(,.E31F.>,.>@2+>).?&F+)>2&1,

=>?&@.?&A(

B'C>,D(D.?&A(

Keeping particles apart

Add repulsive force in the space between colliding particles

Force of repulsion proportional to the number of colliding particles

Increasing number of particles creates fluid-like behavior

Keeping particles apart

Simple-ish computation modelAll particles perfectly spherical, but with varying radius sizeHelped with ease of implementation

=13>(.1?.3(@+)A&1,

Not all particles created equal

Different particle combinations have different force of repulsion values

Different chemical reactions simulated when fluids mix

Different massSome have rigid bodies, others don’tParticle types propagate heat differently

i.e. magma cools to form a rock-like solid

Heat propagation

Each particle carried thermal dataWhen particles collide, heat is propagated

Warmer particle to cooler oneSame algorithm we use for force of repulsionParticle types have different thermal transfer

values

!""#$"#$"! %&'()*+,-./0112(3!"#$%%456/75789:;&'( !!

!"#$%&'()$*)&+&,-*.(/0/,#%(1*$(1'2-3/

4 5&6"()&$,-6'#(6&$$-#/(-,/(*7.(,"#$%&'(3&,&

8 9'2-3(1'*7(6"&.+#/(7-,"(,#%)#$&,2$#(&.3(,"-/(-/(&))'-#3(-.:+&%#

4 ;"#.()&$,-6'#/(6*''-3#<("#&,(-/()$*)&+&,#3

8 =#&,(-/(,$&./1#$$#3(1$*%(,"#(7&$%#$()&$,-6'#(,*(,"#(6**'#$()&$,-6'#

8 =#&,(,$&./1#$(-/(6&'62'&,#3(2/-.+(,"#(/&%#(&'+*$-,"%(2/#3(1*$(,"#(

1*$6#(*1($#)2'/-*.(6&'62'&,-*./

8 >#,(?&'2#/(1*$(,"#$%&'(,$&./1#$(1*$(#&6"()&$,-6'#(,0)#

!"! <"! ="! >"!

70(3?@).A31A@B@2&1,

C"! C"!

70(3?@).A31A@B@2&1, DE+&)&F3&+?

One other (mis)use of the particle system

In-game collision detection Characters, missiles, etc. are surrounded by special dummy

particles (interactors)

!""#$"#$"! %&'()*+,-./0112(3!"#$%%456/75789:;&'( !;

!"#$%&'()*"+),-"./.&*0"1$.*2",3"$".'0#)*"(,))'.',3"2*&*(&',3"2*4'(*

5 6'7*)893:";<,,&*%"9.*."&<*"#$%&'()*"+),-"./.&*0"+,%"

0,.&",+"&<*"'3=>$0*"(,))'.',3"2*&*(&',3? @<$%$(&*%.A"0'..')*.A"*&(B"$%*".9%%,932*2"1/".#*('$)"2900/"

#$%&'()*."C'3&*%$(&,%.D"+,%"&<*"#9%#,.*",+"(,))'.',3"2*&*(&',3"

? E<*3"$"(,))'.',3"'."2*&*(&*2"-'&<"$3

'3&*%$(&,%"1/"&<*";6FA"&<*"66F"'."$).,"

3,&'+'*2

5 G*%'&.",+"&<'."$##%,$(<? H,"3**2"&,"'0#)*0*3&"$"2*&*(&',3

#%,(*.."&,"&%$(:"*$(<"(,))'.',3

? I*#*32'3>",3"&<*"),($&',3",+"&<*"

'3&*%$(&,%"#$%&'()*A"#%*&&/"09(<"$3/

(,))'.',3"($3"1*".'0#)/"2*&*(&*2"$32

&%$(:*2

Some benefits include No need to write lots of different

collision detection systems Depending on the location of the

interactor particle, pretty much any collision can be simply detected and tracked

SPURS jobchain (in words)

Yes, we really used SPURS SPU jobchain:

1)Collision detection and repulsive force calc

2)Force unification ( for multi-cell particles )3)Particle update ( verlet )4)Particle deletion, only 1 SPU used5)Grid calc for the next frame

PPU processing:Particle generationJobchain building

SPURS jobchain (in words)

Yes, we really used SPURS SPU jobchain:

1)Collision detection and repulsive force calc

2)Force unification ( for multi-cell particles )3)Particle update ( verlet )4)Particle deletion, only 1 SPU used5)Grid calc for the next frame

PPU processing:Particle generationJobchain building

Collision job

Collision detection between every particle in a cell

Several cells pooled together to make one job

Jobs are divided to help with load balancing

OutputParticle numberForce of repulsion

Force unification job

If a particle is processed in more than one cell, we have to unify the results

Output: Unified force of repulsion, acceleration, and other info by particle number

!""#$"#$"! %&'()*+,-./0112(3!"#$%%456/75789:;&'( <=

!! "#$%&!#'!$&()*+,#-!.((*,&/!0#!&.%1!(.$0,%*&

2 3-!01&!&4&-0!01.0!#-&!(.$0,%*&!+0$.//*&+!5#$&!01.-!#-&!%&**6

7 81&$&!,+!.!-&&/!0#!)-,'9!01&!'#$%&+!#'!$&()*+,#-!,-!&.%1!%&**

2 81&!$&+)*0+!'#$!01&!($&4,#)+!:#;!.$&!)-,',&/!'#$!&.%1!(.$0,%*&!

-)5;&$

7 <'0&$!)-,',%.0,#-=!'#$!.%%&*&$.0,#->.*,?-5&-0!0#!;&!+0#$&/!,-!01&!

@A!01&!:#;!1.+!0#!;&!/&',-&/!;9!01&!$&+0$,%0,#-+!#-!@A!%.(.%,09!

%#5;,-&/!B,01!01&!+%#(&!#'!(.$0,%*&!-)5;&$+C

2 D)0()06!E-,',&/!'#$%&!#'!$&()*+,#-!'#$!&.%1!(.$0,%*&

9+2>+2.?13.@1A<<.203+.@1A<=BC>D32&E)(.,1FG.>1H(3.1?.3(>+)I&1,JK%D32&E)(.,+LA(3I.ED,.A(.M+>)&ED2(M

@1A!<

@1A!!

@1A!; N!"""")N!####

N<"""")N<####

N")N####

*+,-./0123

Update job

This is the BIG one ( in terms of code size )

Particle physics calculations, including verlet integration

PPU notification of interesting eventsLike abrupt changes in fluid direction,

triggering effectsOutput

Updated particle dataParticle deletion info Various other flags

Particle delete job

Only run on one SPUVery few particles deleted, around 10 per

frameTake valid particles off the end, and

overwrite deleted particles as we find them

Particle grid divisionUsed to parallelize workloadO((n/k)2) for k≈1232 cells, or a 44x28 grid

( better than O(n2) )Multiple cells per jobBut what if a particle is on the border

between two cells?

Particle grid division

Particles are processed ( hit test ) with every cell they touch

In the next phase, we unify all forces acting on a particle

After merge, the particle belongs to the upper left most cell it touches

!""#$"#$"! %&'()*+,-./0112(3!"#$%%456/75789:;&'( <"

!"##$%$"&'()*)+*$"&',#-".$*/0%'1,%)('"&'-.$(2%3#$**$&-

4 5,.*$+#)%'#"+,*)('"&'*/)'1".().%'"6','+)##7 5,.*$+#)%',.)'3."+)%%)(',%'3,.*'"6'1"*/'+)##%

7 5,.*$+#)%',.)'.)+".()(',%'/,8$&-'"++93$)('),+/'+)##

7 :"'3.)8)&*'*;"'3,.*$+#)%'1)$&-'.)-$%*).)('*"','09#*$3#)'&901).'"6'

+)##%<'*/)'*"3'#)6*'+)##';$##',#;,=%'*,>)'3.)+)()&+)

=

=

" < !

"

<

!

>"?"@

><?"@

>"?<@

><?<@

)*

;

moved to (0,0)

SPURS jobchain (in pictures)

wait for SPU grid calculations

add particles

kick jobchain

idle time ( fixed in Shooter 2 )

collision detection

unify forces

verlet update

particle deletion

grid calculationswait for SPU

do other stuff!

add particles

kick jobchain

collision detection

idle time ( fixed in Shooter 2 )

PPU SPU

SPURS jobchain (in-profiler)~9000 particles

Painfully obvious optimizations Heavy use of SoA

big win even when converting to and from in the same job

Avoid scalars ( especially multiple writes ) like the plagueOr don’t read/write the same buffer in the

same loop As branch-free as possible Software pipelining and unrolling

But less LS left for particles Favor intrinsics over asm :(

Dylan’s inline asm site Possible through compiler communication

Christer’s© algorithm

Is game too slow?

move onmove something to SPUS

yes no

Fluid renderingRender particles in a vertex array

Three basic particle types: solid, liquid, and gas Each is rendered to a different offscreen buffer A vertex array is required for each particle type

Upper particle limit is approx 30,000 three different vertex arrays for three particle types

with 30,000 particles each is a waste One vertex array can be used for all three types

Fluid rendering Vertex array built on the SPUs

1~5 SPUs used depending on the num particles Lists built in LS and DMA’d to main memory

The vertex array is 64 sectors Each sector contains one particle type Max 512 particles per sector Atomic DMA to coordinate shared list updates

Fluid rendering

Grouped particles rendered as a smooth flowing fluid

Existing example: marching square/cubeRelated particles depicted as a polygon meshThe grid has to be fine, or liquid movement

isn’t smoothCurrently patented

Not by us

!""#$"#$"! %&'()*+,-./0112(3!"#$%%456/75789:;&'( !<

!"#$%&'()%(*$)+

, -*.#/(%&/0*1$2"(3&*()%(*(%&03&0&34..1567".8$)+&7"#$%

, 9)&(:$31$)+&(:04/"(;&15(&40*25$)+&3<#0*(=2#>(

? @)2(&15(&/0*1$2"(&*#>$2.)&503&>(()&%(1(21(%&03&/033$)+&$)1.&0&+*$%A&

15(&*("01(%&/0*1$2"(3&0*(&%(/$21(%&03&0&/."B+.)&4(35&7"#$%

? C5(&+*$%&503&1.&>(&D(*B&7$)(A&.*&15(&"$<#$%&4.D(4()1&%(/$21(%&$3&).1&

34..15E&C5$3&503&>(()&/01()1(%&F(:/$*(%GH

Fluid rendering

Render particles to a low-res offscreen buffer with a luminance texture

Blur the offscreen bufferScale up with bi-linear filterUse the resulting brightness to color the

liquid

!""#$"#$"! %&'()*+,-./0112(3!"#$%%456/75789:;&'( !<

!"#$%&'()*%++,-$./#+%0&(%-0%(,-$

1 2%-0%(,-$&'()*%03(%+4 56%&7)8.(%+)739,)-&)::.+*(%%-&/3::%(&(%-0%(+&'#(9,*7%

,"#$%+&8,96&96%&*%-9%(&9%;93(%+&7,9&/(,$69

4 <73(&,+&#00%0&#9&96%&)::.+*(%%-&/3::%(

4 =*(%%-&(%+)739,)-&,+&,-*(%#+%0&8,96&96%&3+%&):&#&/,.7,-%#(&:,79%(

4 >-7?&'#(9,*7%+&8,96&#&/(,$69-%++&@#73%&#(%&*)7)(%0&#+&7,A3,0

41=>3(?.1@@.?A3((, 5@2(3.B)+3.CDD(D E&>)&,(C3.@&)2(3.C,D.?2(F

!""#$"#$"! %&'()*+,-./0112(3!"#$%%456/75789:;&'( !<

!"#$%&'()*%++,-$./#+%0&(%-0%(,-$

1 2%-0%(,-$&'()*%03(%+4 56%&7)8.(%+)739,)-&)::.+*(%%-&/3::%(&(%-0%(+&'#(9,*7%

,"#$%+&8,96&96%&*%-9%(&9%;93(%+&7,9&/(,$69

4 <73(&,+&#00%0&#9&96%&)::.+*(%%-&/3::%(

4 =*(%%-&(%+)739,)-&,+&,-*(%#+%0&8,96&96%&3+%&):&#&/,.7,-%#(&:,79%(

4 >-7?&'#(9,*7%+&8,96&#&/(,$69-%++&@#73%&#(%&*)7)(%0&#+&7,A3,0

41=>3(?.1@@.?A3((, 5@2(3.B)+3.CDD(D E&>)&,(C3.@&)2(3.C,D.?2(F

Cohesiveness Free falling liquid causes particle

distances to increaseLiquid mass loses cohesiveness Opposite problem as compression

Solution: don’t fully clear the bufferImage lag effect maintains cohesiveness,

even in motion

!""#$"#$"! %&'()*+,-./0112(3!"#$%%456/75789:;&'( !<

!"#$%&$'()*&"()&*++*,-.

/ 01*2&-1*&"$3#$%&+("".&+4**"5

6 71*&%$.-(2,*&8*-9**2&-1*&:(4-$,"*.&$2,4*(.*.&(2%&-1*&"$3#$%&

'(..&";.*.&,;1*.$<*2*..

/ 01*2&-1*&"$3#$%&$.&4*2%*4*%=&-1*&;++>.,4**2&8#++*4&$.&2;-&

,;':"*-*"5&,"*(4*%=&$2.-*(%&$-&4*%#,*.&)4(%#(""5

6 71*&$'()*&"()&*++*,-&'*(2.&-1(-&*<*2&$2&';<*'*2-&

,;1*.$<*2*..&$.&4*-($2*%

Water surface AA

When rendering liquid to offscreen buffer, use a smooth step function

Two thresholds used for water surface and for tinting

!""#$"#$"! %&'()*+,-./0112(3!"#$%%456/75789:;&'( !#

!"#$%&'()#*+,%-+./#&0+1-'0-"&'(

! "#$#%$&$'#&()$#*&+,*-)%#.&)/$01)20)+0/3

4 5'#/&$'#&206,07&0+&*#/7#*#7&8/&$'#&8--1+%*##/&9,--#*.&)&

+:88$'&+$#;&-,/%$08/&0+&,+#7&1&)/$01)20)+0/3

4 <(8&70--#*#/$&$'*#+'827+&)*#&,+#7&$8&7#$#%$&$'#&()$#*&

+,*-)%#&)/7&-8*&$0/$0/3

! "#$#%$0/3&7*):)$0%&

:8=#:#/$

4 "#$#%$&)/>&+,77#/&%')/3#+

0/&$'#&206,07&&+;##7&)/7

70*#%$08/&?@AB&,;7)$#&C89D

4 E8$0->&$'#&AAB&8-&$'0+&#=#/$

4 <*033#*+&-8):&#--#%$+.&#$%F

SPU update job detects sudden changes in liquid speed and direction, and notifies the PPU to add foam effects

Depicting movement

Create a flow pattern to show movementEach particle gets a fixed random UV value

[0..1]UV value converts to RG valueUse a different color where RG is 0.5f, 0.5f

!""#$"#$"! %&'()*+,-./0112(3!"#$%%456/75789:;&'( ;"

!"#$%&&'()*+,-./01*2'&34-'546'.(*.7*,-3'8*9.6'.(

: ,-./*.7*$%)3-4$*-';3'8

< =7*(.6>'()*7-./&*4-.()*/'6>*6>%*-';3'8?*6>%(*>./*8.*/%*8%#'@6*

A.B%A%(6C

: D$%46%*4*7-./*#466%$(*6.*&>./*A.B%A%(6

< E&&')(*%4@>*#4$6'@-%*/'6>*4*7'"%8*$4(8.A*F2*B4-3%

< G>'&*F2*B4-3%*@.(B%$6&*6.*4*HI*B4-3%*.77*&@$%%(

< ,.$*6>%*4$%4&*/>%$%*HIJKLMN?*LMNO?*4*8'77%$%(6*@.-.$*'&*3&%8

"<".21.=<".&,.>?2+>).!@.A>)+(B

Refraction

From water and from magma heatPing-pong between offscreen buffers ( tex

feedback processing )Degree and direction depends on particles

fixed UV

Distance field

How does it work?Binary input image

Walls are white Space is black

Output image Wall core is bright Wall boundary is 0.5f Gets darker as you move away from wall 2 distance transforms: static and dynamic

Sample usesWall collision detectionMaking enlarged fonts look better

Distance transform

!""#$"#$"! %&'()*+,-./0112(3!"#$%%456/75789:;&'( ;!

!"#$%&'()*"(+,

- ./%$0#)%),"#$%&'()*"(+,1

2 3&45$)36%7()89"&%:;)"6%7(<

- .%++#=)>/"$(

- ?4%'(=)9+%'@

2 A5$45$)36%7()8,"#$%&'()*"(+,<

- .%++)'B:(=)9:"7/$

- .%++)9B5&,%:;=)C%+*DE%+5()8FGH<

- !"#$%&$)*:B6)>%++=),%:@

- IJ%64+(#)B*)$/(),"#$%&'()*"(+,)"&)

5#(

2 364:BE"&7)$/()%44(%:%&'()B*)

*B&$#)>/(&)(&+%:7(,

2 KB++"#"B&),($('$"B&)4:B'(##"&7)

*B:)$B4B7:%4/;L)($'G

Using distance transform for wall collision

Look up character’s pos in the distance field> 0.5f ⇒ collision

≤0.5f ⇒ no collision

Moving away from a collisionGet 4 distance field values near collisionLook at gradient to move away from the wall

Using distance transform for wall collision

!""#$"#$"! %&'()*+,-./0112(3!"#$%%456/75789:;&'( ;;

!"#$%&'()*"(+,)%&,)$-.-/0%.1"'%+)'-++"#"-&),($('$"-&

2 3-.-/0%.1"'%+)45%++#6)-7#$%'+(#8)

'-++"#"-&),($('$"-&

9 :7$%"&)$1(),"#$%&'()*"(+,)";%/()

<%+=()!)5"$1)0(#.('$)$-)$1()

'1%0%'$(0>#).-#"$"-&

!!!"<."=>.?)@%++)'-++"#"-&

!!!" ."=>.! ?)A-)'-++"#"-&

2 A-0;%+)+"&()'%+'=+%$"-&)*-0)$1()

'-++"#"-&)+-'%$"-&

9 :7$%"&),"#$%&'()*"(+,)<%+=(#)*0-;)

B)+-'%$"-&#)&(%0)$1()'-++"#"-&

9 !"0('$"-&)$-)"&'0(%#()$1()."C(+)

<%+=()4/0%,"(&$8)D)%..0-%'1"&/)

$1()5%++

0&2

"=;

"=?

:13@A).)&,(

Using distance transform for wall collision

!""#$"#$"! %&'()*+,-./0112(3!"#$%%456/75789:;&'( <;

!"#"$%&#'()&*+)"**(,("-+#%").,,(-$+&-/+0'.+#&%0()*.+1*"2+,3,0.4

5 6"**(,("-+/.0.)0("-+7,(-$+0'.+/(,0&-).+1(.*/

8 9(,0&-).+1(.*/+4.&,7%.,+:;<=:;<+)">.%(-$+<;?;@<#A

8 B#A+C+B+D30.+>&*7.+"1+<EFG+2'()'+)&-+D.+,0"%./+(-+0'.+HIJ

5 K'.-+/.0.)0(-$+&+)"**(,("-+2(0'+0'.+$%"7-/

8 !'.+1"%).+"1+%.#7*,("-+(,+&##*(./+(-+*(-.+2(0'+0'.+)"**(,("-+

,7%1&).?+#%"#"%0("-&*+0"+0'.+)"**(,("-+1"%).

5 G!KLLL

8 9(,0&-).+1(.*/+)&*)7*&0("-,+(-+I(A.*M7-N+O/.-+2.%.+"-*3+%7-+

"11*(-.

When detecting collision with the groundThe force of repulsion is applied in line

with the collision surfaceProportional to the collision force

Distance transform in-game

Distance transform algorithms

O(n2) Chamfer distance Used with Manhattan distance1ms for 256x256 on one SPUAlso had a 512x512 version

Dead reckoningA little more accurate

Jump floodingImplementable on GPU6ms *GASP*

Parallel versions exist, but...

Chamfer distance algorithm

Two passes ( forward and back )Propagate distance to closest wall

Forward pass looks at upper and left neighbors

Backwards pass looks at lower and right neighbors

The larger the window, the more accurateWe went with a 3x3 window

Chamfer distance algorithm ( unsigned )

!""#$"#$"! %&'()*+,-./0112(3!"#$%%456/75789:;&'( ;<

!"#$%&'()*(#+'(,+-.*'/(0%1#-&2'(3$4)/%#+.(5,036

7 3$4)/%#+.(*$)8

9 :&%#%-$(;%1#-&2'(<-$"'1(*)/(-$$(=%>'$1(?(@

9 :&="##%&4(A(<-$"'(%.-4'1(-#(#+'(';4'1(1'#1(;%1#-&2'(<-$"'(#)(B(51'';6

9 0%1#-&2'(=/)=-4-#%)&

9 C-$"'(%1(#+'(/'<'/1'()*(#+'()"#'/(1"/*-2'()*(-&()DE'2#(5%&="#(D$-2F(

/'4%)&6(

9 G%4&';(;%1#-&2'(*%'$;(H((;%1#-&2'(<-$"'(2);'(2-&(-11%1#(%&#'/&-$I'>#'/&-$(

;'#'2#%)&

= = = = =

= = = = =

= = = = =

= = " = =

= = " = =

= = = " =

! > " > !

! > " > !

; ! > " >

" > !

" > !

" >

?! ?>

?>

?>

)*!+,-

?!

?!?;

./0123@A((BC

4567/&D,(B.B&A2E,F(.G&()B

!""#$"#$"! %&'()*+,-./0112(3!"#$%%456/75789:;&'( ;<

!"#$%&'()*(#+'(,+-.*'/(0%1#-&2'(3$4)/%#+.(5,036

7 3$4)/%#+.(*$)8

9 :&%#%-$(;%1#-&2'(<-$"'1(*)/(-$$(=%>'$1(?(@

9 :&="##%&4(A(<-$"'(%.-4'1(-#(#+'(';4'1(1'#1(;%1#-&2'(<-$"'(#)(B(51'';6

9 0%1#-&2'(=/)=-4-#%)&

9 C-$"'(%1(#+'(/'<'/1'()*(#+'()"#'/(1"/*-2'()*(-&()DE'2#(5%&="#(D$-2F(

/'4%)&6(

9 G%4&';(;%1#-&2'(*%'$;(H((;%1#-&2'(<-$"'(2);'(2-&(-11%1#(%&#'/&-$I'>#'/&-$(

;'#'2#%)&

= = = = =

= = = = =

= = = = =

= = " = =

= = " = =

= = = " =

! > " > !

! > " > !

; ! > " >

" > !

" > !

" >

?! ?>

?>

?>

)*!+,-

?!

?!?;

./0123@A((BC

4567/&D,(B.B&A2E,F(.G&()B

!""#$"#$"! %&'()*+,-./0112(3!"#$%%456/75789:;&'( ;<

!"#$%&"'()*+*,%#-,)&+./0

1 2!34%567.%$+7.#*'"%+7%8&)8#,#."$

9 :&&)&7%#''606-#."%;)&%"#'/%8&)8#,#.+)*%7."8

1 <&)8#,#.+)*%8)7+.+)*%="&)%>/"&"%$+7.#*'"%?%@%+7%&"')&$"$%;)&%"#'/%'"--

9 <&)8#,#.+)*%>+*$)>%67"7%ABA%:6'-+$"#*%$+7.#*'"%

9 C/"*%$+7.#*'"%+7%68$#."$D%$+7.#*'"%+7%&"E'#-'6-#."$%;&)0%8&)8#,#.+)*%

8)7+.+)*%="&)

" " = !

= =

! !

>?&@2A,B(.3(CBA)B+)A2(D EF!

= ! ;

! G GH=

H=HF! HF!

EF!)*+,-./0123

Initial state Desired result

Jump flooding

Unlike DRA and CDA*, parallel processing is possible

Works on GPULog2(n) passes O(n2 log2(n)) calculationRough idea

Compute an approximation to the Voronoi diagram of a given set of seeds in a 2D grid

Jump flooding in action

In every pass, the distance is cut in half. These images show all 8 passes on the GPU

Platform comparison

PS3CDA: 1ms for 256x256 on one SPU

PCJump flooding: 8 passes required5~6ms was too much time, so we split it up

and did 4 passes per frameSPU vs GPU

SPU: more complex processing possibleGPU: awkward to program, and is already so

busy with rendering

Editor overview

FunctionsWall editing

Based on templatesHad procedural generation, but didn’t use it

Placing items, characters, etcTurning things on and off

Wall, rock, fluid, enemies, gimmicks, items, survivors, verlet update, particles

Fluid editorFlow simulationExecution/cancellationVarious debugging visualizations

Editor overview

!""#$"#$"! %&'()*+,-./0112(3!"#$%%456/75789:;&'( <<

!"#$%&'(#$)*+&,-

. /012&+,13

4 5#(06'-$7012&+,13$302"$'3$&,8,(-'8"+2'6$#*+&+1(9$6,2'&+,1$

,7$2"'-'2&#-39$+&#:39$#&2;

4 /60+*$76,<$#*+&+1(9$76,<$3+:06'&+,1$#=#20&+,1>2'12#66'&+,1

4 !,8,(-'8"+2'6$*#3+(1$7012&+,13$?'3#*$,1$&#:86'&#3

Topographical design

Different patterns for different thingsDifferent sized rocks, walls, ice, snow

Each stage had unified design concepts Designers still have to hand-draw their

levelsOne of the reasons it would be hard to

release a level editor on PS3

Pattern templates

Designers create patterns for wall decorations

The level creator uses the templates to design the walls

Templates broken into several partsUsing randomized loops and reverses, joints

are automatically made seamlessVector format for nice scaling

Conclusion

Fluid simulation system 32,768+ fluid particles @ 5SPU, 60FPS

Heat transmission, constant distance maintenance, etc

Universal collision detection system Real-time distance field CDA, 256×256, Manhattan@1SPU, 1ms

Used for collision detectionAlso abused for ??? in Shooter 2

Note to self: if time left over, have that “only on PS3” discussion I promised everyone on Twitter