XeNTaX

What's the point of vertex colors? I know they have an NP-complete problem for vertex coloring, but other than that...
How are they used?
Are there any practical uses that one should be aware of?

PSX games use vertex colouring to improve the detail of models while keeping the load times and possibly disk space low. See the Crash Bandicoot series, for example.

its not uncommon to see current gen games use vc, it does inpack shading but I'm no expert.

They're cheaper than lightmaps or other forms of texture-based baked lighting. (fill-wise, and on some hardware lightmaps can only be done in multiple passes, or not at all due to insufficient hardware blending options) That's the primary benefit, and the reason tons of PSP games still use vertex colors for baked in lighting. Most current-gen games have switched to textures or pixel/fragment shader variables (shader variables are often ideal because custom colorization is often sufficient to have on a per-mesh/draw basis), although I do still come across people using vertex colors occasionally.

I think I explained all this in the guide, didn't I?

http://wiki.xentax.com/index.php/3D_Mod ... rtex_color

Vertex colors are color values assigned to vertices. It's not hard to imagine a colored dot in 3d space, but what happens when vertices connect and form lines or triangles? It would be practically useless to have colored dots on your mesh. Luckily, that's not how they are rendered by OpenGL or DirectX when connected. The colors of the neighboring vertices are interpolated over the surface, so you get a nice gradient. This makes vertex colors very useful for things like skydomes because they take up far less memory than gradient textures. Vertex colors are also used on map models to simulate shadows. Some old games use vertex colors on characters instead of textures (usually only the face of the character will use a texture image).

I didn't notice the vertex color section lol

MrAdults wrote:They're cheaper than lightmaps or other forms of texture-based baked lighting. (fill-wise, and on some hardware lightmaps can only be done in multiple passes, or not at all due to insufficient hardware blending options) That's the primary benefit, and the reason tons of PSP games still use vertex colors for baked in lighting. Most current-gen games have switched to textures or pixel/fragment shader variables (shader variables are often ideal because custom colorization is often sufficient to have on a per-mesh/draw basis), although I do still come across people using vertex colors occasionally.

L.A. Noire still uses vertex lighting for vehicle headlights and distant streetlamps. The III-era Grand Theft Auto games also made extensive use of this, especially since I haven't seen any lightmaps (ala-Source or LS3D/Mafia) being used for simulating shadows on outdoor areas in those games, just coloured verts and nothing else. Which probably explains why buildings don't seem to cast any noticeable shadows.

Vertex lights in OpenGL and DirectX color the vertices which they influence, but they are realtime lights, in other words they manipulate the vertex colors in real time, so they aren't stored in the 3d files. We shouldn't care about them.

It seems a bit silly to be writing new explanations of what common rendering components are, when you can instead pick and pull from pages with rather complete information on their use and behavior. Like official OpenGL/D3D implementation documentation from any given vendor. Microsoft docs are usually a good source. Some problems with the description I see quoted on vertex colors here:

1) OpenGL and Direct3D are not required to interpolate vertex colors. In fixed function OpenGL this is dictated by glShadeModel (this affects interpolation of vertex colors even when lighting is disabled), ShadeModel when writing in Cg, and the list goes on. Most graphics API's have some means of dictating interpolation on a per-component basis, although the means may and often will vary based both on the component and the API. Flat shading is often used (in older games particularly) where more than 1 color per face was not needed or desired, yet in many of these cases colors were still baked into vertex lists and occasionally interleaved as we often see in data sets meant for modern graphics pipelines. This was particularly common in custom software renderers.

2) Way too subjective. It actually wouldn't be practically useless to have colored dots on your mesh (and many people use sprites or even rasterized points in conjunction with vertex colors for this purpose), nor is flat shading useless for many reasons. You should explain what vertex colors are, then explain how they're actually treated by common graphics API's like OpenGL and Direct3D, keeping in mind their conditional uses and not just the common ones that you're used to seeing.

3) Explaining how vertex colors are used to solve common problems (like lighting) is a good idea, but belongs in another paragraph, if not another article, and should have more relevant information depending on which aspects of vertex colors you want to talk about. For example, the practice of simulating lighting and shadows with vertex colors is mentioned in your paragraph, but the process of tessellating and cutting is not, which is very relevant to that specific topic. It often makes lightmaps a performance win even on older systems and rendering architectures, and it's a required procedure for representing any reasonably-complex lighting model with vertex colors. I'm not sure I would mention this topic at all, but if you're going to mention it, be thorough. In the long-term information like this belongs in its own article (because doing lighting with vertex colors is actually a very involved topic), so you can just link to the relevant parts of that article from your vertex color info. Otherwise, if you feel it deserves to be mentioned but you don't want to or can't offer a detailed explanation, you should include it in an itemized "common real-world uses for vertex colors" list where it can be linked to a descriptive article on the topic by someone who cares in the future.

This advice applies pretty generically to anything you end up describing there. You should really be able to basically copy-paste most of your base explanations and descriptions right out of OpenGL/D3D documentation. Anything subjective should be mentioned without invalidating other not-common-but-still-valid uses.

The most practical use for them i've found is for adding color to a textured model prior to render baking.
If your not that artistic, it's possible to produce a more professional looking texture from a simple bland texture.
http://i1235.photobucket.com/albums/ff4 ... l/tms1.jpg
http://i1235.photobucket.com/albums/ff4 ... l/tms2.jpg

I've also misused them to add vertex weights to models, which was outside of the scope of the software used at the time.

gjinka2 wrote:Vertex lights in OpenGL and DirectX color the vertices which they influence, but they are realtime lights, in other words they manipulate the vertex colors in real time, so they aren't stored in the 3d files. We shouldn't care about them.

Either that, or it can be baked too. The ones in L.A. Noire that I mentioned earlier were realtime vertex lights.

MrAdults wrote:It seems a bit silly to be writing new explanations of what common rendering components are, when you can instead pick and pull from pages with rather complete information on their use and behavior. Like official OpenGL/D3D implementation documentation from any given vendor. Microsoft docs are usually a good source.

Firsly, it seems rude to say we are doing silly things.
Secondly, you are basically asking "what is the point of reading a general philosophy book if you can just read the works of all the famous philosopers?" maybe we don't have the time nor the knowledge?
Finally, why don't you just edit the wiki page yourself? You did take the time to post it here, the wiki doesn't require any registration.

1) OpenGL and Direct3D are not required to interpolate vertex colors. In fixed function OpenGL this is dictated by glShadeModel (this affects interpolation of vertex colors even when lighting is disabled), ShadeModel when writing in Cg, and the list goes on. Most graphics API's have some means of dictating interpolation on a per-component basis, although the means may and often will vary based both on the component and the API. Flat shading is often used (in older games particularly) where more than 1 color per face was not needed or desired, yet in many of these cases colors were still baked into vertex lists and occasionally interleaved as we often see in data sets meant for modern graphics pipelines. This was particularly common in custom software renderers.

I have never seen non-interpolated vertex colors for meshes consisting of faces. Again, feel free to edit the wiki.

2) Way too subjective. It actually wouldn't be practically useless to have colored dots on your mesh (and many people use sprites or even rasterized points in conjunction with vertex colors for this purpose)

(So do I.) I'm talking about colored dots on mesh consisting of only faces and rendered as such. Maybe my wording isn't good, again its a wiki, feel free to improve it.

3) Explaining how vertex colors are used to solve common problems (like lighting) is a good idea, but belongs in another paragraph, if not another article,

This is a brief guide to what data is stored in 3d files and how it's stored, not a defnitive guide on how OpenGL and DirectX work. I disagree.

For example, the practice of simulating lighting and shadows with vertex colors is mentioned in your paragraph, but the process of tessellating and cutting is not, which is very relevant to that specific topic.

Hm, maybe because Ive never heard of "tessellating and cutting"? Again, you can add it yourself if you want, or at least post it in the talk page.

But really, cut me some slack, will ya??

When I see someone doing something silly, I will tell them they are doing something silly, explain why I think this, and if possible advise them such that what they're doing can be made less silly or perhaps even not silly at all. I should think going and tearing your wiki entries up myself would've been far more "rude". Your options at this stage are:

1) Take the advice.
2) Ignore the advice.
3) Act like the way in which the advice was delivered has offended your delicate sensibilities.

3 can be combined with 1 or 2 as you see fit. I recall you were big on 3 in another thread with mariokart64, so I'm not surprised you've chosen this marvelous and appealing option in your dealings with me. Let me be the first to congratulate you on a path well-chosen.

I personally think that re-describing core rendering components is pretty redundant, like I already said, so I see no reason to edit what you've written short of removing it entirely and just linking directly to existing documentation and wiki articles that cover the same information. I should think you might be interested in improving it yourself instead of inviting me to come in and destroy it all. If you want to at least make the information consistent and accurate yourself, then I've just given you some fairly good guidelines for doing so. If you have no interest in any of that, I or someone else will probably fix it eventually, sure.

I think it was someone else... Like ganjii or something like that got into it with mc.

MrAdults wrote: linking directly to existing documentation and wiki articles that cover the same information.

Anything technical that requires specialized knowledge and some experience with it goes over my head.

Most of the articles I've read regarding 3D are very technical and specialized and assume you know something about 3D and have played around with 3D and made your own 3D.

Or talk about how they are implemented.
Or the physics and maths behind it.