Sign in to follow this  

need help with direct3d

This topic is 3487 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hai, I'm trying to create a 3D game using "only" direct3d 9 and no other 3rd party library, and my own model format. but now I have serious problems with the design decisions. Actually I wanna do everything as optimized as possible and use the most up-to-date techniques but can't find a real document to help me about this. I don't wanna lose time with old d3d pipeline based articles. Tried to solve Irrlicht engine but in some point I found myself lost somewhere around namespaces and interfaces with mouth half open, spittle dripping... The main problem is that I can't decide "where to use what" Here is an example monolog in my mind: - I should use vertex buffers for all kind of vertex operations and shouldn't use system memory for this issue. using graphics card memory is way faster. *** Googling... someone's asking something about collision detection, aabboxes etc. and a question flashes in my mind.*** - In some point I need a structure like an octree, don't I? but wait, vertex buffers only keep the vertex information. so how am I able to create a mesh (to hold faces etc.) structure to use with an octree without using system memory? So maybe only vertex buffer isn't enough to do everything about vertices? *** Googling... nothing specific about this issue... *** - Maybe I should create another structure to hold vertices in system memory as well and carry them to vertex buffer after calculations.. but what if some of these calculations happen in every frame? It sounds crappy to load and unload vertex buffer in everyframe? Or maybe I should change the values direcly using vertex buffer?? *** another googling session in vain, seeing some microsoft article saying "try to create vertex buffer as big a possible and static as an optimization bla bla.." oh cmon stop punishing me! *** - Maybe we have something to do with vertex shaders about this. But wasn't vertex shaders for transformation and lighting?? well.. this goes to infinity. I'm not sure if this is a proper post for gamedev but my head is about to explode. and this vertex buffer thing was only an example. I have same deadlocks about use of shaders, use of memory, implementation of structures to use with meshes, and a significant number of other topics read loads of tutorials about all kinds of direct3d related topic but a tutorial shows how to do something with a simple hard coded box. nothing more about the use of them in a complex project. Also tried to find a simple and up-to-date engine using direct3d 9 to work out these stuff but failed. Ok after all this pathetic whining and meaninglessly long post, anyone to show an entry point? everything will be much appreciated..

Share this post


Link to post
Share on other sites
Quote:
I'm not sure if this is a proper post for gamedev..

Gamedev is a good place. But "game programming" may be a better forum as your questions are only partially about DirectX.

1. If you haven't done much programming before, start simple, get something to work and then add to it and optimize it.

2. If you have programmed complex projects in DirectX before, copy some of your previous work and optimize that.

"..I should use vertex buffers for all kind of vertex operations.."

Do you know what kind of operations you want to do? Designing without a concept of the final product is premature. It sounds like you should be doing conceptual work, not designing.

Share this post


Link to post
Share on other sites
Hate to say it but: slow down!!

Sure, everyone wants to go from ccalc to crysis in hours but sadly it just doesn't work that way.

Your post lists several fundamental and large areas of both general software development and game development. Each of these can be very complex in their own rights and your head exploding is a fair symptom of trying to learn them all at the same [grin]

I'd recommend you go back to the basics and pull up individual samples and tutorials on the technologies, features and algorithms you think are interesting/useful. Avoid the ready-made engines as they'll serve to confuse the issue in the long run.

hth
Jack

Share this post


Link to post
Share on other sites
Quote:
Original post by troxtril
- I should use vertex buffers for all kind of vertex operations and shouldn't use system memory for this issue. using graphics card memory is way faster.

*** Googling... someone's asking something about collision detection, aabboxes etc. and a question flashes in my mind.***
All your resources should be in the managed pool. That way, D3D keeps a system memory of the resource, and swaps it in and out of VRAM as required. The only exception to that is resources that can't be in the managed pool. That includes render targets (if you're doing render-to-texture), and dynamic resources (Which you'll probably be filling every frame anyway). It also means that when the device is lost (When the user alt+tabs from a fullscreen app for instance), you don't have to manually re-create all your resources; just the D3DPOOL_DEFAULT ones.

Quote:
Original post by troxtril
- In some point I need a structure like an octree, don't I? but wait, vertex buffers only keep the vertex information. so how am I able to create a mesh (to hold faces etc.) structure to use with an octree without using system memory? So maybe only vertex buffer isn't enough to do everything about vertices?

*** Googling... nothing specific about this issue... ***
The vertex buffer only holds vertices. It doesn't have any information about what vertices make up what faces. You need to keep that information yourself, in an array or something. Usually, you'll use an index buffer, which contains the order of vertices to use. But I wouldn't worry about octrees or any other spatial partitioning method till you've got the basics nailed.

Quote:
Original post by troxtril
- Maybe I should create another structure to hold vertices in system memory as well and carry them to vertex buffer after calculations.. but what if some of these calculations happen in every frame? It sounds crappy to load and unload vertex buffer in everyframe? Or maybe I should change the values direcly using vertex buffer??

*** another googling session in vain, seeing some microsoft article saying "try to create vertex buffer as big a possible and static as an optimization bla bla.." oh cmon stop punishing me! ***
The vertex buffer should only contain vertices used for rendering. You should never read from it. If you need to read vertex data, keep it in system memory (In an array allocated with new[], not in any D3D D3DPOOL_SYSTEMMEM structure). You definitely don't want to create and destroy the vertex buffer at runtime, however locking it and filling it every frame is fine (So long as you're not stuffing in loads of data).

Quote:
Original post by troxtril
- Maybe we have something to do with vertex shaders about this. But wasn't vertex shaders for transformation and lighting??
I can't really see how that would help.


Overall, you're really throwing yourself in at the deep end, as jollyjeffers said. Forget about octrees completely for now, focus on getting a mesh rendering. Then get 100 meshes, then start to look at how to optimise that. Then you can start looking into octrees and the like.

Share this post


Link to post
Share on other sites
thanks for the advice. I guess you all are right about this fast going situation.

couple of questions here:

as far as I can understand I need to preserve face and vertex data in a structure in system memory.

Quote:
Original post by Evil Steve
You definitely don't want to create and destroy the vertex buffer at runtime, however locking it and filling it every frame is fine (So long as you're not stuffing in loads of data).


for example, let's say I implemented a culling method and some of the meshes are out of frustum, and all these meshes have their own vertex buffers.

q1) is it ok to create a vertex buffer for each mesh or should I create a manager to fill a common vertex buffer for all meshes?

q2) should I clean the vertex buffers of meshes which are out of frustum and refill them when these meshes are in again?

and lastly for the "So long as you're not stuffing in loads of data" statement, how do you exactly quantify "loads of data"?

Share this post


Link to post
Share on other sites
Quote:
as far as I can understand I need to preserve face and vertex data in a structure in system memory.

If, as Evil Steve suggested, you put all you can into managed memory, you don't have to worry about it. And, as Evil Steve explained, you shouldn't store data in system memory unless you must!

An alternative to support your culling is to create meshes in managed memory. Do your culling by mesh location and extent and draw just the meshes that are visible. If your viewpoint doesn't change very fast, the meshes that need to be drawn will likely be in VRAM anyway.

By the way, in general the term "mesh" implies a vertex buffer (at a minimum). So, if you're talking about copying mesh data from it's own vertex buffer into a common vertex buffer, which may then in turn be copied by D3D into VRAM if it's not already there, it's double-work.

Share this post


Link to post
Share on other sites
Quote:
Original post by troxtril
for example, let's say I implemented a culling method and some of the meshes are out of frustum, and all these meshes have their own vertex buffers.

q1) is it ok to create a vertex buffer for each mesh or should I create a manager to fill a common vertex buffer for all meshes?

q2) should I clean the vertex buffers of meshes which are out of frustum and refill them when these meshes are in again?

and lastly for the "So long as you're not stuffing in loads of data" statement, how do you exactly quantify "loads of data"?

You profile (that applies to all 3 questions).

Get a basic thing up and running, try not clearing the meshes, and using a buffer per mesh. If you see you're running out of memory, try clearing meshes when they go out of frustum. If you see that isn't fast enough (loading too many times), look for a different solution (a large dynamic buffer that gets filled according to need).

Specifically, your questions about meshes and vertex buffers can be easily solved by using the Managed Pool. This would make the DX runtime manage memory for you, by keeping a system memory copy and copying only the resources it needs to the GPU. This is the perfect solution for nearly all "basic" scenarios, I'd recommend you try it first.

Nevertheless, I've shown you ways to work around your problem even without using the Managed Pool simply to illustrate the way I think you should be working. Keep moving, and only solve problems you actually encounter. You don't need to solve all of the world's problems, just yours.

Hope this helps.

Share this post


Link to post
Share on other sites

This topic is 3487 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

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

Sign in to follow this