There are good artist reasons for which most vertices will have common properties ("world" vertices and some "entity" vertices).
Simply put, this is choosen to maintain a consistent look and feel.

I would agree that you should begin by using a single format with high efficiency.

There are also some few cases (mostly fx) in which standard formats are not enough but I would say this accounts for less than 5% of the total vertices for an average scene. Skeletal animation is however an important exception. I have some doubts it should use the same "world" management system anyway so I believe there's no problem.
I would suggest leaving this 5% for the future. Don't worry about this now.

There are a couple of strategies that you can take with this.

Firstly you could define a single vertex format - a super-set of all properties. Roughly like the previous two replies have suggested. All internal rendering and effects are simplified as they all read from a common data source.

You'd also need to implement some sort of processing to convert from whatever incoming format to this single/common internal format. This could be done as a preprocessing step (dxops.exe from the command line can do much of this) or you could build it into your mesh loading class.

The second way, and in my opinion the most flexible is to create a linking/matching system.

Firstly you read in the data from the file with no changes and store it's vertex signiture. This immediately defines a class of effects and rendering that it can be used with. For example, if it only defines a POSITION+TEXCOORD then you can't use dynamic lighting as it doesn't contain a normal (etc..).

If you want to render the incoming data using a technique that requires additional information then you can examine the differences and see about auto-generating it. For example, the input is still POSITION+TEXCOORD but you want to do tangent-space per-pixel lighting, so you use D3DXComputeTangentFrameEx() to build NORMAL+TANGENT+BINORMAL elements into the vertex. Probably good to emit a warning to the logfile so that the artist(s) know that its done something...

If the technique requires a property (e.g. a 2nd/3rd set of texture coordinates) that your program cannot automagically generate then it's an error. The input geometry is not compatable with the requested technique. In this instance you can either downgrade to a lesser effect or cleanly fail and output a reason to the log-file.

You should be able to implement this abstractly such that your application code is clean and straight forward - effectively offloading the problem to the data files (which are relatively easy to change).


Dustin/Circlesoft usually has something clever to add to these sorts of threads, so hopefully he'll spot it [grin]

Cheers,
JAck

in my engine vertices of any type are possible. It was a pain to code it but now i have vertex class that deals with it all and it's quite easy to use too(and as fast as possible).
before you use the vertex you have to define the attributes it will have like that:
vertex.addAttribute(POSITION,usageIndex,FLOAT3)

and set the value with
vertex.setAttribute(NG_POSITION,(void*)&value)
(i could remove that ugly void pointer but i'm too lazy.)

so i think this isn't much more complexer than having some static vertex types but it's more flexible.

btw setting attributes doesn't need any if statements,searching through lists or sth similar(in case you wonder about performance)

regards,
m4gnus