Quads might be a useful primative.

One might argue that quads can always be turned into triangles, however, this throws away information that might be useful. For example, when generating vertex normals on a patch you get better results from a quad tesselation than a triangulated tesselation. Also, Kobbelt subdivision on a quad patch would be better than refinement on a tri mesh that gets biased by the choice of diagnol.

Collada already enables quads to be represented by using polygons. However, somethimes there are a lot of quads. Having an xml node for each quad makes the file heavy. If you pop it into Internet Explorer to eyeball the file, it will load really really slow.

Unlike tristrip, quad could be a justifiable primitive in collada.

Just my 2c

You don’t think tristrips are justifiable?

What if you want to write a tristripping tool, that fits in your asset pipeline, reading and writing Collada files?


This is achieved by writing an algorithm that reorders the index triples within a tri list.

Please refer to other topic about tri strips, and continue discussion there. ok my bad for mentioning that within this thread.

I left quads out because I wasn’t hearing any use cases for them from game developers. It would be a simple matter to add quad primitives to COLLADA 2.0.

i might be stepping into the deep side of the pool here, but… the ability to support non-triangulated polys is fairly important from an art asset management perspective. my guess is that it doesn’t matter how your maintaining them (quads or polys) but if an artist is expected to meaningfully edit an object that was created in one package, “exchanged” through collada and loaded back into a new application, (of back into the same program for that matter) collada needs to be able to maintain 4 sided polys (truthfully n sided would be best.

with most modern modeling tools quads are essential for selection types such as “edge rings” and “edge loops” and these are in turn very important for getting the most out of such fundamental tools as component extrude, delete, chamfer… in addition triangulation doesn’t lend itself well to any of the subdivision algorithms i’m aware of. for these reasons, at the very least a quad exported from Maya needs to load up as a quad if reimported into max or xsi and vise versa.

if melax’s concerns about overhead, and my assertion about inter-program editing are important to the goals of collada then a clean implementation might be warranted.