Archived

This topic is now archived and is closed to further replies.

bilsa

Vertex structures?

Recommended Posts

Hello! Hello! I was thinking about the size the the "Vertex structurs" take. eg 1. //this is how the full structure would look like right?
  
struct s3DVERTEXALL {
	FLOAT x2D, y2D, z2D, rhw;
	FLOAT x3D, y3D, z3D;
	FLOAT nx, ny, nz;
	D3DCOLOR diffuse;
	FLOAT tu, tv;
};
  
eg 2. //this is how a cut of and memory friendly version looks like:
  
struct s3DVERTEX {
	FLOAT x3D, y3D, z3D;
	D3DCOLOR diffuse;
};
  
eg 3. //this is how a more dynamical structure would look:
  
struct sVERTEX {
	union {
		struct s2D {
			FLOAT x, y, z, rhw;
		} s2D;

		struct s3D {
			FLOAT x, y, z;
		} s3D;
	} CoordinateType;

	union {
		struct sColor {
			D3DCOLOR diffuse;
		} sColor;

		struct sTexture {
			FLOAT tu, tv;
		} sTexture;
	} TextureType;
};
  
So, how important IS the size of those structures? Those are going to be used very often right? So, according to "sizeof()" those were the results: eg 1. result: 54 //bytes? chars? or whatever... eg 2. result: 16 eg 3. result: 24 So between the the cut of and very "undynamical" structure, eg 2, and the more dynamical one, eg 3, there is "only" 8 bytes difference. So would this matter very much when creating a big project in 3D? The first one is probabilly not to even consider? But the other two? wich one to use?? If I want very little memory consuming then the second is bes right? But then on the other hand I will have to create a new structure for each other case of Vertex type I want to create... and thus making it not good for creating a "MeshObject" class where I just would want to pass a VertexArray with information about the polygons and nothing else: Something like this:
  
class MeshObject
{
public:
	int	Create(struct sVERTEX *sVertex);	//With a Vertex Array as argument, 

							//this class will set up "almost"

							//everything else by itself

	//... other stuff...

};
  
So, how important is this memory when working with 3D? Thx for reading this [edited by - bilsa on May 5, 2003 11:27:13 AM]

Share this post


Link to post
Share on other sites
Direct3D(X) uses the stride (sizeof VertexStructure) to find out howmany vertices there are in the buffer, so it can render those vertices. Thats why you need to pass the stride + FVF.

.lick

Share this post


Link to post
Share on other sites
1) It depends on the specific graphics chip.

2) On many chips:
a. for sequential access (i.e. you lock the buffer, fill in all vertices and then render from the whole buffer) prefer smaller vertex formats.

b. for random access (i.e. locking and filling in occasional vertices or rendering from random parts of the buffer), prefer vertex formats that are a multiple of 32 bytes in size.

3) Take a look on the developer.nvidia.com site, there's a presentation on there which compares the relative performance of different vertex sizes.

4) Since vertices are likely to be in AGP memory, everything has to go across that bus so is limited by the performance of that (or PCI on older chips), so logically transferring less data per vertex allows you to transfer more. Whether the bus is your bottleneck depends on how much you're drawing.

EDIT:

5) also check for D3DFVFCAPS_DONOTSTRIPELEMENTS

--
Simon O'Connor
Creative Asylum Ltd
www.creative-asylum.com

[edited by - s1ca on May 5, 2003 11:43:44 AM]

Share this post


Link to post
Share on other sites
That was a very interesting article!

According to them, the nvidia chip made best results with a FVF on 24 bytes

Anyway, since they even didn't test FVF's on 16 bytes, that shouldn't be anything to worry about

And besides, I don't think that the difference between the different sizes was big enough to worry about...


[edited by - bilsa on May 5, 2003 12:47:25 PM]

Share this post


Link to post
Share on other sites
That first vertex isn''t even a valid FVF vertex type. You can''t have D3DFVF_XYZ and D3DFVF_XYZRHW in the same vertex.

For the most part you can use a larger vertex type which does everything you want, even where parts of it may be redundant (for example an untextured mesh using a vertex type with texture coordinates).

Vertex size becomes an issue though if the meshes in your app use wildly different vertex sizes. For example you might use a very small vertex type for particle effect, but a huge one for skinned meshes. In that case you should use the vertex type most appropriate to each situation, because using the huge vertex type for everything will start to affect performance.

If you find that your bottleneck is your vertex throughput you can try compressing the vertices. You need to use vertex shaders for this though.

Share this post


Link to post
Share on other sites