Vertex colour = Gouraud shading?

rumblesushi

What exactly are the differences between the two?

I know exactly what Gouraud shading is, and even though Vertex colour seems to be a more contemporary term, it seems to be more or less the same thing - per Vertex lighting information, rather than pixel level.

Cheers,
RumbleSushi

PixelGoat

Vertex Colours does not have to contain lighting information. It can also be used to for tinting and help break up tiled textures some.

r_fletch_r

Not really. thats like saying a self illumination map is the same as the phong per pixel lighting model.

Vertex colour = way of storing colour information on a per vertex level.

Goraud Shading = way of assigning lighting data to verts and interpolating between those values to give a smooth result

jocose

yeah like r_fletch_r said Goraud is a bit a math used to calculate lighting. This calculation constantly re-evaluates what lighting value each vertex should have. This is then interpolated across the surface of the triangle.

Vertex colors work in a similar way but without the real time math. Instead the values are saved in each vert permanitly.

This has a few advantages. First, its really efficient provided your using it in stead of real-time lighting, and second it gives you total control over the colors being used.

Some shader/physics systems can use vertex color values to control other things. Like how rigid or soft a mesh is at a particular location, or what texture gets used when a shader is applied to particular polygons.

Eric Chadwick

But yeah, they both interpolate across the polygons in a similar way... both give you these linear-looking gradients from vertex to vertex.

So if you bake lighting info into vertex colors, then show just the vertex colors, it ends up looking just like Gouraud. Kinda cool.

rumblesushi

What Eric said is pretty much what I thought, that at the very least, they are both vertex level gradients, so if you used vertex colours without texture mapping, it would look like gouraud shaded polys with solid colour.

The only difference then is that Vertex colour stores colour rather than just light information, obviously And that gouraud shading is going to generally be updated by a real time light source.

jocose - that's interesting actually, sounds like an efficient way of handling physics data, even though it isn't intended for that purpose.

Do you guys know exactly how a 3D engine interprets Vertex colour and uses it in the rendering pipeline?

If used on textured polygons (which of course it would be) - presumably it would be used as a second render pass with a blend mode?

r_fletch_r

They both interpolate vertex data to provide smooth shading so they both can look the same.. they are not however anything like each other.

I'm pretty sure there is no second pass, that sounds excessive. vertex colour tinting has been around since forever. more than likely the colour is just multiplied over the diffuse colour

so texturecolour * lighting * vertex colour

someone with shader writing experience should probably confirm that but it seems the most likely answer

rumblesushi

So it would be multiplied at a pixel level then right? And all in 1 render pass, simply altering the colour of the diffuse pixel?

Not having pixel level control in my engine is pretty annoying. I'm contemplating adding Vertex Colour, but it's going to be too expensive, like Gouraud Shading. Both involve rendering the polygon twice, one with diffuse, and the second with the lighting data/vertex colour with a blend mode. I'll have to stick to baked textures, annoying, but the rendering is more of a bottleneck than RAM in my environment.

r_fletch_r

Beyond me, It was my assumption that any modern graphics API could handle this stuff for you.

rumblesushi

Ah yes, the thing is, my engine is a browser based software renderer, no GPU or any api's at all, everything is done from scratch

r_fletch_r

Keep in mind that I have a retardedly simple view of graphics programming in practice... but here i go.

If you've written a textured polygon drawing function then why not integrate your vertex colour into that? your using a barycentic coord to sample your texture so why not use it to work out the vertex colour factor it in when you draw your pixel.

Eric Chadwick

Vertex color absolutely does not require lighting, it's just color data. Where in the shading pipeline you use it is entirely up to you. I only meant it's similar to Gouraud in the way they are interpolated.

Some OpenGL code I found after a quick search, might help you...
http://www.cs.hs-rm.de/~panitz/hopengl/skript.html#LineAttributes

rumblesushi

Eric - oh I know you weren't saying they are the same thing, but mechanically they are similar, at least. Thanks for the link too, even though I have an idea of how it's implemented, that's helpful.

fletch - usually you'd be right In a software based scanline renderer you could simply multiply the pixel value after sampling the texture with either lighting data or vertex colour in one pass. It would be pretty fast actually, with not much impact on performance.

The thing is, my engine is not a scanline renderer. It's built in Flash, and you don't have pixel level control. So I have 2 ways of rendering polygons.

After the vertices are transformed etc, and the polygons checked for visibility, you can either use flash's 2D drawing API to draw a triangle, with moveTo(), lineTo() etc with a texure fill and transformation matrix, or you can use the draw triangles function, which you feed a list of transformed Vertex coordinates and a texture, and it draws triangles in batches for you.

Either way, it's only polygon level control, rather than pixel level. So to apply lighting data or vertex colour, you'd need to render a seperate batch of polygons with just that data, plus a blendmode (which is expensive) on top of the textured polygons.

That results in about 25% of the normal performance, which is obviously not acceptable, especially when we're talking super low polycounts anyway.

That's why I'm pretty much going to just use baked textures