Anyone know of a good way of encoding uniform data per face?
Looks like all of the attributes are set per vertex. Or a uniform can be set per object. But that means separating a large mesh into many objects, which destroys efficiency.
Thanks,
No, you cannot encode data per-face, unless you are sending uniforms yourself. Why would you want normals per-face for? The lighting calculations will not be correct and will look “out of place”, especially on certain edges where the difference in face orientation gets large.
Originally posted by Zulfiqar Malik:
Why would you want normals per-face for? The lighting calculations will not be correct and will look “out of place”, especially on certain edges where the difference in face orientation gets large.
Not everybody is writing a terrain engine. If we go back to our BSP discussion(or for that matter, portal rendering or whatever), the normals are DEFINED per face and that’s the way they should be rendered - you can’t render a cube f.e. with averaged vertex normals - it wouldn’t look correct.
However, this applies to the low-level geometry only, where edges are “desired”. If you render curved surfaces or .3ds models, f.e., you are absolutely right, the normals should be per-vertex then; there’s only one exception - namely if you wanted to compute shadow volumes on the CPU (mostly the case) - then you’d need the per-face normals as well (not for rendering tough)…
EDIT: Rereading the post, there’s probably one more thing: If low-poly geometry with per-face normals is rendered, the normals are still sent per-vertex to the graphics card; that’s the only way to render huge batches at once - specifying normal uniforms per-face would kill performance. That’s also where the vertex attribute duplication comes from…
Actually, I don’t think I specified the information was normals only. This information wouldn’t be.
Per Face encoding of information is used pretty frequently to store data. It could be indexes into data structures that are loaded as texture maps. Scalar information that shouldn’t be interpolated by the fragment processors. Many, many uses.
Programs like pman, etc. allow for this kind of information. But OpenGL seems to allow the encoding only through per vertex attributes, which can be memory expensive. It also means at least four times the memory and four times the bus transfer between GL_QUAD and GL_QUAD_STRIP alone (i think).
That’s because you normally wouldn’t render single faces (intermediate mode); mostly rendering is done using indexed vertex arrays - so there’s no way to specify a batch of vertices (= face) to which some attributes may apply.
Originally posted by fluid:
Scalar information that shouldn’t be interpolated by the fragment processors.
The per-vertex attributes are interpolated before they are even sent to the fragment programs, and that’s for free… so why worry about per-face attributes?
that’s the unfortunate part. this algorithm requires a uniform value per face over a dense mesh. the value is an index into a data structure. the index allows the algorithm to optimize a search for nearest neighbors.
seems like the solution is embedding the information as per vertex, just the same information so the interpolation won’t affect it.
glShadeModel( GL_FLAT ) easy!
Well it depends there ase some tricky bits…
- I don’t know if it works with shaders (may need to check the specs)
- Not really “per face” it just takes the first vert of the triangle so if that vert is used by several faces they may end up with the same data. But depending on what you want to do with it it may work.
- It “may not be HW accelerated”, meaning the driver has to reorganise the data to have unique vertices for every triangle. This will probably be slower than duplicating the data yourself.
thinking about that, the only downside is that this shader requires both interpolated and non interpolated behaviour (that can’t currently be multipassed in diff drawing modes). the normals, etc need to be interpolated. this specific information needs to be uniform at the same time.
thanks,