It's just come to my attention that the exporter for the 3rd party 3d engine we are using (net immerse) is duplicating the vertices on the corners of objects such as tables, chairs and walls, in the conversion from Max geometry to vertices for direct 3d. I'm realising now the reason why it is having to do this - the objects have been textured in Max using more than one set of u,v coordinates per vertex. This is both to make the texturing easier for the artists, and also it seems a necessary evil introduced by lightmapping, unless each surface in the geometry can be matched with a conjoined area within the lightmap. Before this I had just been working with simpler objects that were textured without lightmaps and with a constraint on the texture coordinates so that in most cases there was only one set of uv's was necessary at each vertex location. This previously had allowed me to easily triangle strip the objects and make good use of the vertex cache on t&l cards and get great performance. But it's striking me that if in my new project almost each polygon is having to have its own unique individual set of 3 vertices, then this is going to totally wreck any benefits from vertex caching and triangle stripping. Am I imagining it or could this represent a fundamental barrier to performance, particularly on architectural geometry? I have to say by the way that I've had no direct experience with dx8 so it may provide an obvious way around this problem (e.g. specifying the texture coordinate set separately from the vertex position).

Don't forget that you can still tri-strip a non-continuous surface by inserting degenerate triangles between the unconnected strips (by duplicating the vertices at the end of one strip and the start of the next). If you use DrawIndexedPrimitive() for you're rendering then you just need to duplicate the index rather than the whole vertex (saving transform time) and the extra triangles will get rejected early on during the triangle setup stage on the card. The extra cost here is very small (esp. compared to the cost of doing lots of drawprim calls). If you haven't already then you might want to take a look at nVidia's triangle-stripping program - it takes vertex caching into account when it generates tri-strips (and I think it'll insert degenerates for you, can't remember) - go to the developer's section at nvidia.com.

Oops, I don't think I made it too clear what I meant, my fault. Although the triangles on a surface look as though they should be sharing vertices at an edge, they don't actually share ANY vertices because each vertex needs to be totally different because although the x,y,z location is the same, the texture coordinates need to be different (because of the texturing technique and lightmapping). 'Don't forget that you can still tri-strip a non-continuous surface by inserting degenerate triangles between the unconnected strips (by duplicating the vertices at the end of one strip and the start of the next).' Yup, I can tri strip it if each triangle has a totally independent 3 vertices (i.e. unused in the other neighbouring triangles which use 'duplicate' vertices (with different texture coordinates) rather than the same vertices, but there would then be no benefit to stripping it over just sending each triangle by a batch of 3 indices. (i.e. to get each triangle in a strip in this scenario you would need to send all the 3 indices plus potentially extra for a swap to get the degenerate triangle). 'If you use DrawIndexedPrimitive() for you're rendering then you just need to duplicate the index rather than the whole vertex (saving transform time) and the extra triangles will get rejected early on during the triangle setup stage on the card.' Unfortunately I think the card would still have to perform the entire t&l etc on each 'duplicated' vertex on the triangle edges because they are actually separate vertices (i.e. the card doesn't 'know' ahead of time that the x,y,z coordinates are the same). 'If you haven't already then you might want to take a look at nVidia's triangle-stripping program - it takes vertex caching into account when it generates tri-strips (and I think it'll insert degenerates for you, can't remember) - go to the developer's section at nvidia.com. ' Yup, I'm familiar with it, but as with all stripping algorithms it relies on the fact the triangles are SHARING vertices, but in my case unfortunately no two triangles are sharing vertices. But I think on reading your reply pieman you must have misunderstood because I badly worded my question so please don't take my comments as nastiness :P .

Hi, I don't think there's anything much you can do about that other than tell the artists to try and create their meshes in a manner that will allow vertex sharing. If any of the vertices members are different; either colour, normal, uv coordinates or anything else you have in there, they have to be duplicated. Just try and get the artists to create the source models with shared UV coordinates, normals and vertex positions whereever possible. Tim.

yup, I thought so unfortunately our artists have already created most of our levels, so they're not going to be too keen on retexturing, hehe! But I'm beginning to think that this whole problem is unavoidable to a large extent when using lightmaps anyway. It's a tricky one to get around really, and it really breaks a lot of the speed optimizations.. maybe some day nvidia and microsoft or the opengl org will get round to making a workaround for this in the api that doesn't break the pipeline. I'm surprised I don't here more people whining about this.. by the way tim are you in wales now or is your location thingy old.. back from japan? you'll have to meet up with us lot some time for beers, .. gareth (clarke) my right hand man here informs me he's mates with you from uni.

Hi, Yeah, I'm back from Japan; doing the university thing again and working towards an mphil at the moment. That's nice as it's not as stressful as working for a living but it does remind me what it's like to have no cash... Cash permitting, I'd love to come out for a beer sometime. It'd be great to see Gareth again too, he told me that you two were mates a while ago. A few months ago, I went out for a beer with Lourens, Eddy and almost Mark(!) as well but Mark(!) had to shoot. That was a good laugh and it'd be good to see some of the people here out on the piss again As for the lightmapping thing; there might be a way to share vertices and use lightmapping as well but it would require another preprocessing step to see which textures match up and can be stored in a manner that would allow vertex sharing. I'll have a think about that one. Tim.

1. ISTR someone from nVidia proposing a method for re-creating the texture surfaces themselves (preprocessing step) based on polygon location and sharing. It was for a different problem (mirrored textures with texture space normal maps for DOT3), but the basic idea of programatically re-ordering the thing which is causing the problem could be one to think about. 2. Technically I think the solution used by the nice GameC...onsole [] I'm working with at the mo should be possible on DX8 level cards (although not the API). The hardware can take multiple component streams (one for position, one for normals, one for texture coordinates etc - as supported in DX. The major, (and nice) difference is each stream can have it's own indexing (not supported in DX. This is also very similar to how 3DS Max stores it's data too (UV coord array is separate to vertex position array and there are two sets of faces UV and positional). 3. Another consoley thing it'd be nice to see is a reserved index code for strips to mark a new anchor position for a strip (so you can restart the same strip in a new position without the need for a new draw call). 4. Can't the lightmaps just be "shrink wrapped" ? (possibly with a separate set of coords or texgen). You can get some occasional stretching artifacts, but most of the time (depending on your game) it's not noticable.

I do the same sort of multiple index thing in my modelling program and then build a dx-happy vertex buffer and tri strip from the resulting mesh. I'd also like to see independent indices for normal, colour and uv arrays as that would make things much easier. Tim.

Erm, that wasn't Mark!, Mark!'s real name isn't even Mark. It was Mark "I have a ponytail and a sissy surname, does that count?" Rose who was supposed to come along, at least as far as I understand. (yes, that's a real-life quote from this board, although it's probably so old it's not even in the archives anymore). Anyway, there were some vague plans to do it again next summer...I'm probably going to be in the UK again this summer so let me know :-).