Now for the other side of the coin. The pondering of moving back to OpenGL... If so when or will we get instancing from Nvidia or ATI? This whole back and forth thing is about to kill my drive to code... Guess it's the grass is greener on the other side of the fence issue...
Well I am not sure about the whole DX idea anymore. I just tried running a demo from a book that I bought that was going about rendering terrain the way I pondered a few months ago while I was thinking about moving to DX. The gist is take a large terrain mesh and break it down into patches or grids and render them with LPD3DXMESH per grid. Well the load time for the terrain alone will age you... Good grief its slow as hell. My OpenGL version loads a 1025x1025 HM and frutsum culls the grids and loads a lot faster. I am pointing the finger at the fact this DX method uses so many LPD3DXMESH's and has to setup this main mesh first and then break it down into a mesh for each grid(33x33). So if anyone ever reads my posts, I would be interested to know how you are going about your DX terrain rendered and if you know of any good tutorial sites...
Now for the other side of the coin. The pondering of moving back to OpenGL... If so when or will we get instancing from Nvidia or ATI? This whole back and forth thing is about to kill my drive to code... Guess it's the grass is greener on the other side of the fence issue...
Now for the other side of the coin. The pondering of moving back to OpenGL... If so when or will we get instancing from Nvidia or ATI? This whole back and forth thing is about to kill my drive to code... Guess it's the grass is greener on the other side of the fence issue...
Previous Entry
More Progress
Comments
August 09, 2006 03:34 AM
instancing is mostly likely to turn up in OGL3.0, although it might sneak out as an extension before then. 3.0's spec isn't due before next years SIGGRAPH and drivers will probably take a few months to follow on (as normal I expect NV to be there first, ATI to follow)
August 09, 2006 09:19 AM
Quote:Original post by zedzeek
what do u need instancing for?
What do I need more than 640k for? :) RTS games for one...
Hmmm, next year huh... Well I will have to keep this in mind.
On a off note, what is the scoop with GLEW? Can you use it in a commerical app and get paid without being sued? Or does one need to use GLEE. Thanks
August 10, 2006 01:06 AM
Quote:Original post by superpig
You mean you're loading the whole mesh and then breaking it down every time you load? No wonder it's slow. You're not stripifying it or something as well?
Personally, I never use D3DXMESH for anything except little sample apps. Given that each terrain patch has the same topology, you need one index buffer for all of them, and then one vertex buffer per patch - or you can have one vertex buffer with all the terrain's vertices in and then use the start offset with the indices. If you've built your data efficiently, loading the terrain is something like:
ID3DDevice9::CreateVertexBuffer()
ID3DVertexBuffer9::Lock()
ReadFile()
ID3DVertexBuffer9::Unlock()
No this is just a one time load from the "Intro to 3D Game Programming with DX9.c a Shader Approach" The author is using the D3DXMESH to load all the data into a huge chunk in system memory and then subgrids he calls it but I call it patches of 33x33 sizes and loads them into their own meshs and calls DrawSubset(0) on each mesh with a loop that has the meshes that pass the frutsum test. All I know is it takes awhile to load up and all its doing is rendering a 1025x1025 map, where my OpenGL rendering takes a lot less time and it has to do the hm also plus compress my textures at loadtime where his aren't...
So you are saying you are using the same IBO with the same rendering order for lets say 33x33 mesh 0-3072(32*32*3) indices and then make e.g. 513x513 terrain mesh with 33x33 patches = 16x16=256 VBO's... So 256 VBO with 1 IBO to render the terrain mesh for a 513x513 terrain?
August 10, 2006 01:16 AM
Quote:Original post by superpig
You mean you're loading the whole mesh and then breaking it down every time you load? No wonder it's slow. You're not stripifying it or something as well?
Personally, I never use D3DXMESH for anything except little sample apps. Given that each terrain patch has the same topology, you need one index buffer for all of them, and then one vertex buffer per patch - or you can have one vertex buffer with all the terrain's vertices in and then use the start offset with the indices. If you've built your data efficiently, loading the terrain is something like:
ID3DDevice9::CreateVertexBuffer()
ID3DVertexBuffer9::Lock()
ReadFile()
ID3DVertexBuffer9::Unlock()
No this is just a one time load from the "Intro to 3D Game Programming with DX9.c a Shader Approach" The author is using the D3DXMESH to load all the data into a huge chunk in system memory and then subgrids he calls it but I call it patches of 33x33 sizes and loads them into their own meshs and calls DrawSubset(0) on each mesh with a loop that has the meshes that pass the frutsum test. All I know is it takes awhile to load up and all its doing is rendering a 1025x1025 map, where my OpenGL rendering takes a lot less time and it has to do the hm also plus compress my textures at loadtime where his aren't...
So you are saying you are using the same IBO with the same rendering order for lets say 33x33 mesh 0-3072(32*32*3) indices and then make e.g. 513x513 terrain mesh with 33x33 patches = 16x16=256 VBO's... So 256 VBO with 1 IBO to render the terrain mesh for a 513x513 terrain?
August 10, 2006 01:18 AM
Advertisement
Latest Entries
Back in the saddle again... I hope...
1856 views
Not much to say.....
2100 views
Coding again, but seems useless
1369 views
Hell Yeah
1482 views
OpenGL 3.0
1369 views
Yawn
1550 views
About Dam Time
1286 views
No SUBJECT
1389 views
At last Physics is working!!
1323 views
Advertisement
You mean you're loading the whole mesh and then breaking it down every time you load? No wonder it's slow. You're not stripifying it or something as well?
Personally, I never use D3DXMESH for anything except little sample apps. Given that each terrain patch has the same topology, you need one index buffer for all of them, and then one vertex buffer per patch - or you can have one vertex buffer with all the terrain's vertices in and then use the start offset with the indices. If you've built your data efficiently, loading the terrain is something like:
ID3DDevice9::CreateVertexBuffer()
ID3DVertexBuffer9::Lock()
ReadFile()
ID3DVertexBuffer9::Unlock()