The Game Technology discussion thread *Read first post before posting*

[Shifty Geezer]

And can you render all your particles into one 'particle graphic' and blend with the actual framebuffer only when it's all done? I don't think so, although this might be the case.
I mean, you need to do reads and compares with the Z-buffer of the scene geometry already rendered into the framebuffer while rendering the particle system, you can't just do it in complete isolation...

My theoretical particle engine -

Read a tile from the framebuffer, say 32x32, including depth. Also store the particle graphic, some smokey blob. Per pixel, per particle, blend if z-test clears. Spit out rendered tile and proceed to the next one. This design would only work for some particle types, but should be entirely processing dependent, with negligable impact on bandwidth - in essence a post-effect.

 

[Laa-Yosh]

Sounds good but involves a lot of vertex work to bin and split up your particle system's quads. And with limited local storage you also limit your possibilities, for example look at how they're using two relatively large bitmaps for animated smoke in Halo. There's no way you could store all that on top of the buffers and the vertices in 256k. It's no good if you can only use this particle engine for some percentage of your effects.

Now with 512k...


Anyway, I got the impression that marcus wasn't talking about this. It seemed more like he was thinking about how SPUs help out the RSX with vertex work, and didn't get the real cause of the problem (lots of reads/writes). I haven't really considered using the SPUs for the actual rendering of the particles... so that's why I said that RSX's problem isn't calculations but bandwith, and involving the SPUs won't help there.

 

[Shifty Geezer]

Sounds good but involves a lot of vertex work to bin and split up your particle system's quads.

I wouldn't even use quads. I'd use bitmaps. You only need a centre coordinate and camera settings for the transform to render al the particles.

Of course it'd only work with 2D particles and the like, so it would have limits. But I think visually it'd work well. I don't know what consumption of the SPE cycles would be like versus what's already needed for the game though. As Joker says, if you haven't spare cycles it's not worth it.

Anyway, I got the impression that marcus wasn't talking about this. It seemed more like he was thinking about how SPUs help out the RSX with vertex work, and didn't get the real cause of the problem (lots of reads/writes). I haven't really considered using the SPUs for the actual rendering of the particles... so that's why I said that RSX's problem isn't calculations but bandwith, and involving the SPUs won't help there.

Yeah, I dunno how well SPEs could help there. GPU rendering of particles is a bandwidth and draw hog, no two ways about it. I dare say you'd be better off not using particles, instead calculating an occlusion value per pixel. Kinda like, you could render fog with a 1000 layers of barely opaque quads stretching into the distance, but if the end result is just a fading to grey with z, you can calculate a simple LERP to get the same result! And of course if the hardware really can't handle the particle system (or whatever else) you are designing, you'd be better off going for a different design.

 

[zed]

Particle effects mean hundreds of transparent quads on top of each other which creates huge amounts of overdraw, dozens of layers, and that's what causes problems for the PS3 at full res.

Ive already given a possible solution for this, which results in higher quality particle systems to boot. Im a bit disappointed that developers are still taking the easy way out (theres a market for a middleware solution with the next consoles, this will be possible on the GPUs or today on the SPUs)

WRT bayonetta I watched a video (btw nice its got a lensflare, glad to see ppl arent afraid to use them, shadows arent unified as well)

http://www.1up.com/do/newsStory?cId=3170273
it seems the enemy fade out when they get too close to the camera(due to the fill issues no doubt I take it this is the ps3 version)

Are there any games with full res particles on either console so far?

to many to list

 

[assen]

Ive already given a possible solution for this, which results in higher quality particle systems to boot.

"I've already given" should only be accompanied by "I used in game X shipped/shipping in quarter Y"

Im a bit disappointed that developers are still taking the easy way out

That's the nature of engineering; every game has an infinite set of problems to solve, and a finite budget of programmer time; you get to choose how to use your available programmer time to make the best possible game. "Quality of transparent effects higher than what you get with 1/4 resolution rendering" would be pretty down the list in any real game; any real game can probably be improved more if the time spent on a more complex transparencies, is spent somewhere else.

 

[Dr. Nick]

http://www.1up.com/do/newsStory?cId=3170273
it seems the enemy fade out when they get too close to the camera(due to the fill issues no doubt I take it this is the ps3 version)


to many to list

Actually no, that video is from TGS 2008 the PS3 version wasn't shown until right before TGS 2009. Unless I clicked on the worng link some where. Oh and that screen from my earlier post it shows and enemy taking up almost half of the screen.

 

[liolio]

16 bit greyscale is the suggested quality, that should be the same as a normal map with only two channels stored, and most likely it can be compressed too.
Depending on the tesselation quality you may even downsize it once without any loss of detail... Assuming you keep the normal map as well, for smaller details, but that's a no-brainer IMHO.

Thanks for the answer

 

[zed]

Actually no, that video is from TGS 2008 the PS3 version wasn't shown until right before TGS 2009. Unless I clicked on the worng link some where. Oh and that screen from my earlier post it shows and enemy taking up almost half of the screen.

the screenshot showed little, sorry about the video I just googled the name + thats what I came up with.
Ive never heard about the game before, so if u can supply a link to a better video Ild be obliged

That's the nature of engineering; every game has an infinite set of problems to solve, and a finite budget of programmer time;

oh so true, but I was saying higher quality + higher framerate. Something like speedtree does for foliage u can have this for partcile like effects
btw here my speedtree (called qualitree ) example
http://www.youtube.com/watch?v=VHKc8aGho4A
sorry bout the upload quality + the programmer art etc but
A/ its higher quality than the foliage in crysis (technically perhaps not artistically)
B/ I wrote this+recorded this demo 5 years ago, it scales well btw

now particle effects are quite common, wouldnt it be nice to have a library to handle X effects? (like speedtree does)

 

[SG79]

to many to list

Any PS3 examples that come to mind? Most people here are suggesting that the low res solution is what every single PS3 developers goes with even if it's not a port (such as the case with a number of older PS3 exclusives).

 

[obonicus]

the screenshot showed little, sorry about the video I just googled the name + thats what I came up with.
Ive never heard about the game before, so if u can supply a link to a better video Ild be obliged

Check youtube. http://www.youtube.com/watch?v=0IOjyLAHnvA is a demo run on the PS3. http://www.youtube.com/watch?v=oluO...83FB9C33E&playnext=1&playnext_from=PL&index=6 for one on 360. Both have HD versions.

 

[Acert93]

oh so true, but I was saying higher quality + higher framerate. Something like speedtree does for foliage u can have this for partcile like effects
btw here my speedtree (called qualitree ) example
http://www.youtube.com/watch?v=VHKc8aGho4A
sorry bout the upload quality + the programmer art etc but
A/ its higher quality than the foliage in crysis (technically perhaps not artistically)
B/ I wrote this+recorded this demo 5 years ago, it scales well btw

now particle effects are quite common, wouldnt it be nice to have a library to handle X effects? (like speedtree does)

Thanks for the video.

It would be neat to see a middleware house that, instead of full suites, did components with a common framework. e.g. particles, materials, clouds, folioage, etc. Developers could ala carte elements relevant to them.

 

[Acert93]

Forza 3

An interesting thing some of us B3D geeks were discussing over a recent Live Party (our B3D home away from home!) was the surprising decision by Turn10 to minimize overdraw related techniques. This is surprising considering the eDRAM. While the cars have transparent windows and such, you would think as an exclusive they would have made a design decision to include a fair deal of particles and such. It would give the game a grittier look and add some interactive life to the sceen.

I understand and agree with the rock solid 60fps mantra, but for an exclusive I find this surprising. The 360 doesn't have a lot of exclusives, but the ones it has on non-multiplatform engines do appear to use a fair deal of particles and whatnot (e.g. Halo 3 seems to have full buffer transparent particles). T10 really seemed to have gone for the clean/hyper look and toned down lighting changes, dirt, etc.

 

[milan616]

Isn't the base engine from PGR4 though, as was the case with PGR3 and Forza 2? Any architectural decisions they made for PGR could have hampered their ability to add effects as they desired. Or it could have been a lack of budget. Microsoft's first party support really makes me sad these days.

 

[Laa-Yosh]

Huh?? Bizarre, the developer of PGR, is a brittish studio and they've been purchased by Activision over a year ago. I seriously doubt that there's any tech sharing between PGR and Forza.

 

[assen]

Huh?? Bizarre, the developer of PGR, is a brittish studio and they've been purchased by Activision over a year ago. I seriously doubt that there's any tech sharing between PGR and Forza.

This doesn't necessarily exclude the possibility of tech reuse, the contract under which Bizarre created PGR3/4 might have left not only the IP, but also the tech with Microsoft - similar to how Ruffian allegedly have Crackdown 1 as a basis for Crackdown 2.

 

[Laa-Yosh]

But to think that two games like those would share the engine completely? That's quite a lot different... not to mention that the two games aren't really similar anyway...

 

[ihamoitc2005]

Tech sharing

Huh?? Bizarre, the developer of PGR, is a brittish studio and they've been purchased by Activision over a year ago. I seriously doubt that there's any tech sharing between PGR and Forza.

A long time ago I read an interview for Forza 2 on the Xbox site where they said that they share tech with Bizarre.

 

[Laa-Yosh]

Sharing tech and using the same engine is quite different...

 

[Billy Idol]

Depending on the scheme they could theoretically use any of these, although for performance reasons it's probably better to only use the actual 3 vertex normals and no neighboring vertices.

The important thing is that tesselation on its own does not add any detail, it can only smooth out the existing curvature.

Just an info: I found this rather interesting introduction to subdivision and spline re-construction (and comparison of different methods):

http://www.mrl.nyu.edu/publications/subdiv-course2000/coursenotes00.pdf

 

[Laa-Yosh]

Yeah, nice overview, although a bit old by now

The Catmull-Clark scheme is the industry standard for movie VFX and animation, although different renderers implement different kinds of UV smoothing, which can cause some confusion.

DX11 tesselation is a completely different approach, because it's not using discrete levels of subdivision, it adds new vertices continuously.