View Full Version : ps3 and rendering with quads
12-03-2007, 02:47 PM
I learned from some game company interview that the ps3 is much more efficient at rendering quads than it is tris. I wanted to ask anyone actually working on ps3 titles what they're experience has been with this (if it's indeed true) and how it has affected your workflow.
12-03-2007, 03:15 PM
Don't blame me for being so bold and jumping in on this without being a guru. But from what I'm told, the graphics processing pipeline deals with tris and vertices. So your quads would end up as tris anyway. However some tri-stripping mechanism might work more efficiently with quads, not really sure about that though.
12-03-2007, 03:28 PM
No worries, but I have a vague idea of how rendering goes. What I gathered from them was that they actually don't split the quads--that's what I'm confused about.
John Carmack talked about how using quads just wasn't very good compared to tris, but that was back in the Quake1 days. Things have changed since then, so maybe quads have become a good idea (considering the unique processing properties of the ps3, this isn't too far out there I don't think)...
12-03-2007, 03:33 PM
don't most engines convert meshes down to tris automatically?
12-03-2007, 03:37 PM
The main idea is that preferably the less deformed polygons the better it will perform overall.
12-03-2007, 03:38 PM
NDS also renders quads faster than tris if the quad is planar that the shape is a plane. At least in a title i worked for DS was like that. Might be wrong /images/graemlins/smile.gif
ill try ask around about ps3 .
12-03-2007, 03:54 PM
yes this is very true, we dont use triangles or even count poly budgets in them. straight up quads and we get our monies worth.. average about 6000-8000 quads per chacracter, not sure of the environment specs.
12-03-2007, 03:55 PM
I've not yet worked with anything that uses Tris instead of quads.
I work with PS3 and 360, but I've not been made aware of any "quad beats tri" code (we doe have rock beats scissors code).
As I'm sure you are aware, a triangle is the smallest polygon you can have. When you have one triangle drawn, drawing a second means calculating 1 extra vert in addition to two others to make an extra polygon. For that reason, in my own head, at this point in time, I don't see an advantage to rendering quads in game.
I expect a tech post in the next 2 hours will prove me wrong.
How can paper beat rock? Eh?
12-18-2007, 10:32 AM
I have no first hand experience with this matter but apparently there is some precedent to quadrilateral renderers: Wikipedia - Sega Saturn (http://en.wikipedia.org/wiki/Sega_Saturn). Changing the rasterizer itself makes quad-rendering more efficient. With the polygon limits jumping as high as they are these days the drawbacks might not be as numerous as in the days of the Sega Saturn. (If you can make sense of it) this seems to prove quad rendering is more efficient, or at least has benefits: Quadrilateral Rendering PDF (http://vcg.isti.cnr.it/publications/papers/quadrendering.pdf). It seems strange that ps3 would implement quadrilateral based rendering if 360 hadn't made the jump. Cross platform games aren't going to work as well now, if this is true. I still would like for more professional input on this matter, perhaps from a graphics programmer on a next-gen system, if there are any of you out there?
12-19-2007, 08:32 AM
I don't know about ps3 since my studio doesn't develop for it, but the DS can render a quad efficently if it stays planar like stated earlier, If its non-planar might as well be 2 triangles.
01-06-2008, 08:34 AM
I think they're talking about vertices not quads then. a bent "quad" can have 6 vertices, a flat one can have 4. If there's a uv seam across it it can also have 6.
I think there would have been a larger industry notice if quad rendering became more efficient as a standard. There's really no such thing as a quad as far as the rendering engines are concerned, quads are just for human convenience.
Just doesn't seem "right"
vBulletin® v3.8.4, Copyright ©2000-2013, Jelsoft Enterprises Ltd.