Re: [Algorithms] Character format.
Brought to you by:
vexxed72
|
From: Adam B. <aba...@tp...> - 2001-02-16 23:24:18
|
Since the PS2 has such small amounts of memory in it's vector units you might want to give up on using Indices, you'll be much better off writing a good stripping algorithm for your character. However yes you should re-transmit the vertex if any of it's properties changes (think of them as being different verticies at the same point in space). I've done exactly this task before on the PS2 (only more complicated because it used weighted vertices and morph targets for facial animation). If you'd like to discuss it in more detail then we should probably take it off the list so write to me directly. -- Adam Batters ----- Original Message ----- From: "Leigh McRae" <lei...@ro...> To: <gda...@li...> Sent: Saturday, February 17, 2001 7:24 AM Subject: [Algorithms] Character format. > Comments gents, > > I am designing a character animation system that is a single skinned mesh > that uses bones with weighted vertices. I intend to use index vertex > buffers. These buffers all use the same index for a vertex so this means > that each vertex has just one of each attribute (xyzw,rgba,uv,normal, etc). > The thing is that I just finished writing a exporter and I realized that a > vertex can quite often have more then one uv or normal associated with it. > So what do people do? Is the answer to generate a redundant vertex for each > of the uv's? Or use another index for the uv's? You are likely to also > have more then one normal per vertex to prevent smoothening sharp edges and > this means even more redundant vertices. I suspect that people make > redundant vertices since I have never see a render pipeline that has more > then one list of indices. > So does anyone have a guess-estimate as to which one will be bigger or are > the two about the same? Space is the main requirement since its a PSX2 > project. > > Leigh McRae > > > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > http://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > |