• Advertisement
Sign in to follow this  

Another beginner, asking...

This topic is 3317 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

Okay!! I signed up just some minutes ago. I made last year some 3D experiments with DirectX (Visual C++). After loooong thinking, some questions seemed to appear, especially about efficiency issues. I'll be short, so here are the questions that I got in mind at the moment. --max framerate = 60 fps -- this is because of my monitor refresh rate, so nothing to worry about.. right? --meshes seemed to have very strange design. I thought of some ways to animate things on screen, using only primitives. DrawPrimitive + some Matrix for positioning. I'm afraid that this will result in a slow application... Anyway, the animated object can be saved in a smaller file than that .x format... --own vertex processing !! I spent some time writing a code that will transform 3D coordinates in screen coordinates. I didn't test it, but it looks mathematically correct. I will let DirectX render the primitives, directly on screen :D. I think that I will have trouble when I'll try to add lights... Tell me what you think of this idea. Should I keep my little vertex processor for some simple apps? --animate objects directly in the vertex buffer... this means I will update the vertex buffer frequently (for example when animating a bat's wings). I'll keep drawing the same primitives (from the same location in the buffer), and if an individual objects remains solid, it will be animated with series of matrix. And a bit of code that I want to use for this: sphere_vb->Lock(0, 0, (void**)&pVoid, 0); .........update the vertex buffer.......... sphere_vb->Unlock(); -------------------- I surely have some grammatical mistakes, since I don't know english at a very advanced level. I am a beginner in DirectX, but not a beginner in programming. I master the C++. I am not willing to use a 3D engine unless I learn at least the 15% of DirectX.

Share this post


Link to post
Share on other sites
Advertisement
--max framerate = 60 fps -- this is because of my monitor refresh rate, so nothing to worry about.. right?

**60 fps is a great target to shoot for, particularily if you have a camera that the user can control to look around.

--meshes seemed to have very strange design. I thought of some ways to animate things on screen, using only primitives. DrawPrimitive + some Matrix for positioning. I'm afraid that this will result in a slow application... Anyway, the animated object can be saved in a smaller file than that .x format...

**ok, that should be fine

--own vertex processing !! I spent some time writing a code that will transform 3D coordinates in screen coordinates. I didn't test it, but it looks mathematically correct. I will let DirectX render the primitives, directly on screen :D. I think that I will have trouble when I'll try to add lights... Tell me what you think of this idea. Should I keep my little vertex processor for some simple apps?

**this will be slower than having the video card to the transforms for you, but if your triangle count is not high it should be ok. If you plan on doing directional lighting then you will also need to do that math as well which is not typically done in screen coordinates

--animate objects directly in the vertex buffer... this means I will update the vertex buffer frequently (for example when animating a bat's wings). I'll keep drawing the same primitives (from the same location in the buffer), and if an individual objects remains solid, it will be animated with series of matrix.

And a bit of code that I want to use for this:

sphere_vb->Lock(0, 0, (void**)&pVoid, 0);
.........update the vertex buffer..........
sphere_vb->Unlock();

**this is ok for smaller, simpler objects. I have a few like that in my game. I don't update the buffer, I just store all frames in a larger vertex buffer and DrawPrimitive() from an offset into the VB.

Hope that helps...

Share this post


Link to post
Share on other sites
Quote:
Original post by chri5ty
Should I keep my little vertex processor for some simple apps?


It's not bad code to have, but I don't think it'd be useful for anything. Assuming you're using D3D9, it has its own software vertex processing, and this should be enough in simple cases. For more demanding apps, you'll use the hardware's vertex processing. Adding your own vertex processing will just complicate things, and is unecessary.

In general, I'd suggest doing things using Direct3D instead of your own code, when you can. And try not to change buffers too much if you don't have to.

Share this post


Link to post
Share on other sites
When I [re]invented the vertex processor, I was thinking of the following problem: Picking objects by screen coordinates...

The example in DirectX SDK seemed pretty simple: pick a triangle with the mouse (apparently there was an API), but when I looked over the source code, I was stunned to see how it really works... It was a combination of math an programming.

When I asked my math teacher about how to determine the intersection point between a line and a triangle. He filled me 2 blackboards within 10 minutes, showing me a final formula to determine the intersection point between the line and the triangle... But I needed to add some extra formulas to check whether that point was inside or outside the triangle.

---
Before I start again with DirectX, I would like to have the missing piece, for creating the very first 3D modeling application: 2D interface and mouse interaction with objects on screen (using only the basic API, without utilities). I'm pretty sure this is a bigger deal than the D3D9 basics, but I'll reserve some time reading any document you suggest me (as I'm the N-th person asking this...). I must understand first how things work, and then "upgrade" to a 3D engine, if necessary...

Share this post


Link to post
Share on other sites
Quote:
Original post by chri5ty
When I [re]invented the vertex processor, I was thinking of the following problem: Picking objects by screen coordinates...

The example in DirectX SDK seemed pretty simple: pick a triangle with the mouse (apparently there was an API), but when I looked over the source code, I was stunned to see how it really works... It was a combination of math an programming.

When I asked my math teacher about how to determine the intersection point between a line and a triangle. He filled me 2 blackboards within 10 minutes, showing me a final formula to determine the intersection point between the line and the triangle... But I needed to add some extra formulas to check whether that point was inside or outside the triangle.

---
Before I start again with DirectX, I would like to have the missing piece, for creating the very first 3D modeling application: 2D interface and mouse interaction with objects on screen (using only the basic API, without utilities). I'm pretty sure this is a bigger deal than the D3D9 basics, but I'll reserve some time reading any document you suggest me (as I'm the N-th person asking this...). I must understand first how things work, and then "upgrade" to a 3D engine, if necessary...
It might take 2 blackboards worths to do it with just maths, but in code you just need to multiply your world, view and projection matrices and take the inverse to give you a matrix that converts from screen space to world space (There's a step I'm missing, I can't remember what it is offhand, but it's 2 or 3 lines of code). Then you can take your mouse position and get a 3D ray in world space (Since there's no single 3D point that matches the 2D mouse point).
Once you have your ray, it's relatively easy to intersect against objects, you very rarely need to pick individual triangles.

And if you're only testing against a single triangle, it might be easier to run the 3 vertices through the WorldViewProj matrix, then test the mouse position in 2D.

Share this post


Link to post
Share on other sites
Okay. Thanks for suggestion.

For 2D Interface, I'll have to get the camera parameters, amd place the items at certain points in front of it.


Now what about DirectDraw? I've seen some pretty games using it. I had a little project where I used several bitmaps to create basic animations and paint them on the screen with a nice frame rate. Now I would like to get some hints on DirectDraw. I think it should be something very simple, since I provide the bitmap, or a serie of 2D images, DirectDraw has probably some similarities with D3D...

Share this post


Link to post
Share on other sites
Quote:
Original post by chri5ty
Now what about DirectDraw?

DirectDraw is dead. Has been since DirectX 8, if I remember correctly. The same thing can be done with Direct3D.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement