• Advertisement
Sign in to follow this  
  • entries
    61
  • comments
    108
  • views
    55035

Ugh more headaches

Sign in to follow this  

250 views

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...
Sign in to follow this  


6 Comments


Recommended Comments

Quote:
Original post by MARS_999
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...


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()

Share this comment


Link to comment
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)

Share this comment


Link to comment
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

Share this comment


Link to comment
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?

Share this comment


Link to comment
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?

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Advertisement