• Advertisement


  • Content count

  • Joined

  • Last visited

Everything posted by DJTN

  1. Previously I posted about a rotation issue with my camera. I thought I had solved the problem by adding frame time to the camera’s movement calculation but unfortunately this only masked the real problem, which I think is a precision issue with floats. I noticed this when I rotate not only the camera but other objects as well. I striped my render code down to the basics in an effort to identify the issue: [source lang="cpp"]Camera Calculations CameraTarget.X = CameraPosition.X + Sin(vRadians) CameraTarget.Y = CameraPosition.Y + (Cos(vRadians) * Cos(hRadians)) CameraTarget.Z = CameraPosition.Z + (Cos(vRadians) * Sin(hRadians)) CameraUp.X = 0; CameraUp.Y = 1; CameraUp.Z = 0; Update View Matrix: D3DXMatrixLookAtLH(View_Matrix, CameraPosition, CameraTarget, CameraUp); [/source] To make things as simple as possible I’ll add 0.002 to the hRadians float each frame. This makes the camera rotate to the left but when I slow the frame rate down I can clearly see the camera is not turning the same amount each frame. This also happens when I calculate rotations for the world matrix before rendering 3D objects too. When rendering at 60 FPS and adding an easing calculation to movements it’s not as noticeable for moving forward, backwards, left and right but when rotating, it is very noticeable. Even with the easing code added you can tell the rotations are accelerating and decelerating, sometimes jerky. I’ve tried to truncate the calculations for the CameraTarget and CameraPosition to regain some precision but to no avail, the issue still persists. Is this a precision issue? And if so, how can I get more precision for rotations? If it’s a not a precision problem then what is it?
  2. Float Precision Issue?

    [quote name='Madhed' timestamp='1353361755' post='5002455'] Honestly, to me it sounds like you are overanalyzing the "problem". I never encountered anything along those lines that was really noticeable and without seeing this myself I can't imagine what the problem actually looks like. Are you sure the wrong motion isn't caused by something else? [/quote] I've stripped my code down to nothing more than a camera and one object being rendered. I'm not overanalyzing the "problem". If the camera's rotations are not smooth, they are not smooth. Some might be ok with a randomly jerking camera, I'm not one of those people. Thanks? I'll revisit this at a later time.
  3. Float Precision Issue?

    Wow, I'm running out of ideas here. Since my View Matrix is accumalitive (I never reset my axis) - could this be the problem? I update every frame using the D3DXMatrixLookAtLH to build the View Matrix. My camera's Up never changes, only the position and the target.
  4. Float Precision Issue?

    [quote name='Hodgman' timestamp='1353205339' post='5001917'] Shouldn't it be 6.283....? [/quote] Yes Hodge, you're correct. I was truncating the float in my code to gain precision. [quote name='C0lumbo' timestamp='1353227105' post='5001982'] Another thing that occurs to me is that if your CameraPosition vector was a long way from the origin, then there'd be a lot of error when you create your CameraTarget vector by adding the unit vector, which could explain some oddness. Could you check that's not the case? [/quote] My camera position is (0,8,0). My target is (1,8,0) at the start. When I break on the code after the first value of 0.003 for hRadians has been calculated the target becomes (0.9999955, 8, 0.002999996) with the position vector staying the same. The target for the next 90+ frames: Frame: 0 Target: (1 , 8 , 0) Frame: 1 Target: (0.9999955 , 8 , 0.002999996) Frame: 2 Target: (0.999982 , 8 , 0.005999964) Frame: 3 Target: (0.9999595 , 8 , 0.008999879) Frame: 4 Target: (0.999928 , 8 , 0.01199971) Frame: 5 Target: (0.9998875 , 8 , 0.01499944) Frame: 6 Target: (0.999838 , 8 , 0.01799903) Frame: 7 Target: (0.9997795 , 8 , 0.02099846) Frame: 8 Target: (0.999712 , 8 , 0.0239977) Frame: 9 Target: (0.9996355 , 8 , 0.02699672) Frame: 10 Target: (0.99955 , 8 , 0.0299955) Frame: 11 Target: (0.9994556 , 8 , 0.03299401) Frame: 12 Target: (0.9993521 , 8 , 0.03599223) Frame: 13 Target: (0.9992396 , 8 , 0.03899011) Frame: 14 Target: (0.9991181 , 8 , 0.04198765) Frame: 15 Target: (0.9989877 , 8 , 0.04498481) Frame: 16 Target: (0.9988482 , 8 , 0.04798157) Frame: 17 Target: (0.9986998 , 8 , 0.05097789) Frame: 18 Target: (0.9985424 , 8 , 0.05397375) Frame: 19 Target: (0.998376 , 8 , 0.05696913) Frame: 20 Target: (0.9982005 , 8 , 0.059964) Frame: 21 Target: (0.9980162 , 8 , 0.06295833) Frame: 22 Target: (0.9978228 , 8 , 0.06595208) Frame: 23 Target: (0.9976205 , 8 , 0.06894525) Frame: 24 Target: (0.9974091 , 8 , 0.0719378) Frame: 25 Target: (0.9971888 , 8 , 0.07492969) Frame: 26 Target: (0.9969596 , 8 , 0.07792092) Frame: 27 Target: (0.9967213 , 8 , 0.08091144) Frame: 28 Target: (0.9964741 , 8 , 0.08390123) Frame: 29 Target: (0.9962179 , 8 , 0.08689027) Frame: 30 Target: (0.9959527 , 8 , 0.08987853) Frame: 31 Target: (0.9956786 , 8 , 0.09286598) Frame: 32 Target: (0.9953955 , 8 , 0.09585259) Frame: 33 Target: (0.9951035 , 8 , 0.09883834) Frame: 34 Target: (0.9948025 , 8 , 0.1018232) Frame: 35 Target: (0.9944926 , 8 , 0.1048071) Frame: 36 Target: (0.9941736 , 8 , 0.1077901) Frame: 37 Target: (0.9938458 , 8 , 0.1107722) Frame: 38 Target: (0.9935091 , 8 , 0.1137532) Frame: 39 Target: (0.9931633 , 8 , 0.1167332) Frame: 40 Target: (0.9928086 , 8 , 0.1197122) Frame: 41 Target: (0.9924451 , 8 , 0.1226901) Frame: 42 Target: (0.9920725 , 8 , 0.1256668) Frame: 43 Target: (0.9916911 , 8 , 0.1286425) Frame: 44 Target: (0.9913006 , 8 , 0.131617) Frame: 45 Target: (0.9909014 , 8 , 0.1345903) Frame: 46 Target: (0.9904931 , 8 , 0.1375624) Frame: 47 Target: (0.9900759 , 8 , 0.1405333) Frame: 48 Target: (0.9896499 , 8 , 0.1435029) Frame: 49 Target: (0.989215 , 8 , 0.1464712) Frame: 50 Target: (0.9887711 , 8 , 0.1494382) Frame: 51 Target: (0.9883183 , 8 , 0.1524038) Frame: 52 Target: (0.9878566 , 8 , 0.1553681) Frame: 53 Target: (0.9873861 , 8 , 0.1583309) Frame: 54 Target: (0.9869066 , 8 , 0.1612924) Frame: 55 Target: (0.9864184 , 8 , 0.1642524) Frame: 56 Target: (0.9859211 , 8 , 0.1672109) Frame: 57 Target: (0.9854151 , 8 , 0.1701679) Frame: 58 Target: (0.9849001 , 8 , 0.1731234) Frame: 59 Target: (0.9843763 , 8 , 0.1760773) Frame: 60 Target: (0.9838437 , 8 , 0.1790297) Frame: 61 Target: (0.9833022 , 8 , 0.1819804) Frame: 62 Target: (0.9827518 , 8 , 0.1849295) Frame: 63 Target: (0.9821926 , 8 , 0.1878769) Frame: 64 Target: (0.9816245 , 8 , 0.1908226) Frame: 65 Target: (0.9810476 , 8 , 0.1937666) Frame: 66 Target: (0.980462 , 8 , 0.1967089) Frame: 67 Target: (0.9798674 , 8 , 0.1996494) Frame: 68 Target: (0.979264 , 8 , 0.2025881) Frame: 69 Target: (0.9786519 , 8 , 0.205525) Frame: 70 Target: (0.9780309 , 8 , 0.20846) Frame: 71 Target: (0.9774011 , 8 , 0.2113932) Frame: 72 Target: (0.9767625 , 8 , 0.2143244) Frame: 73 Target: (0.9761152 , 8 , 0.2172538) Frame: 74 Target: (0.975459 , 8 , 0.2201811) Frame: 75 Target: (0.9747941 , 8 , 0.2231065) Frame: 76 Target: (0.9741204 , 8 , 0.2260299) Frame: 77 Target: (0.9734379 , 8 , 0.2289513) Frame: 78 Target: (0.9727467 , 8 , 0.2318705) Frame: 79 Target: (0.9720467 , 8 , 0.2347877) Frame: 80 Target: (0.9713379 , 8 , 0.2377028) Frame: 81 Target: (0.9706205 , 8 , 0.2406158) Frame: 82 Target: (0.9698942 , 8 , 0.2435265) Frame: 83 Target: (0.9691593 , 8 , 0.2464351) Frame: 84 Target: (0.9684156 , 8 , 0.2493415) Frame: 85 Target: (0.9676632 , 8 , 0.2522456) Frame: 86 Target: (0.9669021 , 8 , 0.2551475) Frame: 87 Target: (0.9661323 , 8 , 0.258047) Frame: 88 Target: (0.9653539 , 8 , 0.2609442) Frame: 89 Target: (0.9645667 , 8 , 0.2638391) Frame: 90 Target: (0.9637709 , 8 , 0.2667316) Frame: 91 Target: (0.9629663 , 8 , 0.2696217) Frame: 92 Target: (0.9621531 , 8 , 0.2725094) Frame: 93 Target: (0.9613312 , 8 , 0.2753946) Frame: 94 Target: (0.9605008 , 8 , 0.2782773) Frame: 95 Target: (0.9596616 , 8 , 0.2811576) Frame: 96 Target: (0.9588138 , 8 , 0.2840353) Frame: 97 Target: (0.9579574 , 8 , 0.2869104) Frame: 98 Target: (0.9570924 , 8 , 0.289783)
  5. Float Precision Issue?

    [quote name='Tispe' timestamp='1353192742' post='5001869'] How about D3DXToRadian() and use 0-360 values? [/quote] A lot of overhead making that change. I'll need to figure out a way I cant test it before going all the way.
  6. Float Precision Issue?

    [quote name='C0lumbo' timestamp='1353183191' post='5001830'] What is the absolute value of hRadians? [/quote] hRadians is set to zero and 0.002 is added each frame. 6.0 in hRadians is a complete circle. It doesn't appear to be related with the inaccuracies coming from the distance from zero.
  7. Float Precision Issue?

    [quote name='Madhed' timestamp='1353184067' post='5001832'] How exactly do you increase hRadians? If you add a constant amount every frame, the rotation will of course accelerate/decelerate depending on the frame rate. [/quote] I've removed the easing (dampening) code as well as the addition of the timestamp each frame so that I can get to the bottom of the issue. Basically my render loop is just adding 0.002 to hRadians and creating the view matrix. This slowly turns the camera. When I slow the frame rate down in the debugger I can clearly see the ratation is different each frame. Some frames the rotation amount is more obvious than others.
  8. Float Precision Issue?

    [quote name='C0lumbo' timestamp='1353183191' post='5001830'] What are those trig functions you're using - do they map to sinf/cosf? What is the absolute value of hRadians? Do you reset it back to the zero to 2Pi range or to the -PI to PI range after it leaves it? (if you let a float get too far from zero the precision drops significantly). [/quote] Yes they are sinf and cosf, the code is pseudo code from memory, I'm not at my computer. hRadians starts out at 0 and I'm adding 0.002 to it every frame in an attempt to find the problem. It accumulative I do not set it back to zero. When I get home I'll check to see how I can implement locking it down to as close to zero as I can get and see if that helps.
  9. I’ve got an issue where my camera jitters when I rotate left or right. It’s random so pinpointing the problem has been difficult. Using PIX I can see that there is a drop in frame rate when the jittering occurs. It’s not a constant jitter it’s like a frame or 2 are randomly taking longer to render. Right afterwards there is a jump in frame rate according to PIX but since I lock my FPS to 60 in my render loop I do not notice the upswing. What is even more peculiar is that I don’t have to render anything to reproduce the issue. Just the camera in the world, no mesh, no sky, etc and when I rotate left or right, randomly the frame rate dips. If I don’t VSync and I don’t lock my FPS down the jittering (lag) is more noticeable. I don’t see an issue moving forward or backwards, only rotating. I have a damping mechanism in place for my camera movement. I thought it might be the culprit so I removed everything in my camera class except the rotation’s calculations. I’m not at my desk so this is pseudo code: [CODE] CameraTarget.X = CameraPosition.X + (radius * Sin(vRadians)) CameraTarget.Y = CameraPosition.Y + (radius * Cos(vRadians) * Cos(hRadians)) CameraTarget.Z = CameraPosition.Z + (radius * Cos(vRadians) * Sin(hRadians)) CameraUp.X = CameraPosition.X – CameraTarget.X CameraUp.Y = ABS(CameraPosition.Y + (radius * Sin(vRadians + PI / 2))) CameraUp.Z = CameraPosition.Z – CameraTarget.Z [/CODE] After removing the damping code the issue still remains. It’s also worth noting that in PIX I do not have any memory or thread changes. Any input would be greatly appreciated. Dj
  10. Thanks for the replies, I’ve since fixed my issue. My render loop checked for window’s messages and bailed the loop until the message queue was empty and then picked back up again. This normally resulted in one frame being dropped every so often- depending on the end user’s key input. The random jittering (stuttering) resulted from measuring the length of the render inside the loop and not taking the dropped frames for processing the windows messages into consideration when moving objects. Since I’ve added the timestamp to include the time it takes to clear the message queue, I’m able to smooth out the animation so it’s not noticeable. In most cases the ultimate solution would be to use DirectInput to process peripheral communications. In my situation, DirectInput is not an optimal choice. Thanks again for everyone’s input. Cheers, Dj
  11. [quote name='eppo' timestamp='1351678074' post='4995772'] you're not using a valid enumerated swapchain discription [/quote] @eppo - I'm rendering in window mode in DX9 using Discard as the swapeffect and only the implicit swapchain. [quote name='Hodgman' timestamp='1351678375' post='4995774'] How do you get your user-input values in order to rotate the camera? Is it possible that the user-input code is causing your frame-rate issues? [/quote] @Hodgman - I think you're on to something here. The movement of my camera is additive, meaning the end user can constantly pass data in. My render loop bails for the window's message queue when there are items that need to be processed. This would explain the delay / lag / FR drop. Any advice Hodg?
  12. I have an object that I would usually move by adding to its position vector. If I wanted to move it forward, I’d add to its position vector’s Z value. If I want to move it backward, I’d “subtract” from its Z value and so on. I'm in a situation now were I need to move the object forward based on the camera’s looking direction. If the camera is looking left then I need to subtract from the objects position vector’s X value, etc... To calculate the position, I thought I’d simply put the position of the object into a new vector3, add to it’s z value like before, and then transform that vector by the view matrix and then set the object's position vector to the new vector3- however, this is not working as expected. How can I transform my move (position) vector based off the camera’s looking direction?
  13. [quote name='davis31' timestamp='1345126854' post='4970183'] That would work. But is it possible to use different techniques, for the different RT when using MRT?? If it is possible, could you give an example or a resource explaining how to do that? I've not been able to find any :S [/quote] [quote name='pcmaster' timestamp='1345190278' post='4970460'] You cannot have different effects (nor techniques (nor passes)) for the individual parts of the MRT, of course. Not even in DX11. Am I right? [/quote] I should have been more specific, when I said RT's... I meant "RT" not "MRT". This would require multiple passes for each RT (surface). I assumed you knew that you cannot render MRT's with multiple effects, multiple techniques, different bit depth, different width, different height, etc... in dx9 with MRT's. MRT (Multiple Render Targets) = one pass. Multiple RT's (several separate Render Targets) = multiple passes. I apologize if I confused anyone...
  14. Reverse Reprojection

    I've never used it nor do I know of any games that use it. You'd think it would be more popular because if you cach correctly, you don't have to render new data every frame and everything can be calculated per vertex not at the pixel level. All this adds up to a faster framerate for shadows, motion blurs and DOF. There has to be a caveat somewhere.
  15. If you're using a pixel shader, you can create another technique that doesn't use the clip funtion and use it for those RTs. Rememeber that clip doesn't return anything for that pixel, nor does it write any information to the back buffer or depth buffer. On newer graphic cards it stops the execution entirely.
  16. You limit the frame rate by measuring the time it takes between renders. If the threshold hasn't been met you don't render that frame. As for color manipulation, this can be done in a pixle shader. Create a quad, add the data to a vertexbuffer with the proper UV texture coords, set a texture and render. You can google "directx render texture quad" for examples. There is probably one with the other slimDX examples.
  17. Directx manages CPU and GPU memory on it's own. It could move blocks to the GPU, reallocate on CPU, etc... these decisions are mostly determined by how you create your vertex buffers ( it's description - i.e. dynamic, write only etc...) but I'm sure there are other factors too. The best way to determine a bottleneck is to use PIX and profile your engine/code This will give you a better idea of what directx is doing with the CPU/GPU memory.
  18. To get a decent looking reder you're going to have to use textures at some point. That's the whole reason behind [u]"pixel"[/u] shaders. Why cant you create your own texture? Or download some? You can even purchase texture packs. Just google 3D texture packs or visit [url="http://www.cgtextures.com/"]http://www.cgtextures.com/[/url] for free ones. Just make sure your read the "terms of use" and "license".
  19. D3DXCreateSphere and Texture

    what is the problem? What is the error?
  20. In order to get a screen shot with MSAA you'll need to have a surface and depth stencil surface that match your backbuffer format and orgianl depth stencil surface. They'll also need to have the same multi-sample type (i.e 2x, 4x, 8x, etc...). You then use stretch-rec to copy from one surface to another - saving the destination texture from the destination surface in the stretch-rec method.
  21. Rendering with dynamic U/V

    You can create a vertex format any way you like, holding any data you want on the CPU then pass it each frame to the vertex / pixel shader. In the vertex shader set up a struc to hold the incoming data and manipulate it anyway you want. It's pretty simple. Depending on what version of DX you're using you could also take advantage of geometry shaders. I have a shader where I pass in one field for position and the uv's. Based off the uv I calculate the position for each vertex so the object faces the camera. Flexability is the reason for custom vertex fomating. I'd also recomend pushing everything to the GPU you can. It's much faster than the CPU.
  22. I have a collection of bullet particles. Each frame I update their position using a velocity vector. The bullets move from the camera (gun) outwards regardless of the movement of the camera which is correct, but when the camera moves -the bullets in the distance move with it, which is incorrect. They should continue on their trajectory (driven by their velocity) regardless of the camera’s movement. I think the problem is the world transform matrix. It attaches a mesh and the particle emitter to the camera, however it also causes the bullets that have already been shot to move with the camera. The bullets should maintain their same trajectory after they’ve left. Storing the world matrix for each particle is impractical but this gives you an idea of what I’m trying to accomplish. If each time a particle was added to the collection I stored the current world matrix then I could transform the particles position to maintain its trajectory. The question is - how I can I get the particles to maintain their trajectory without storing the world matrix for each particle?
  23. Trajectory / Matrices

    I've solved my issue. For anyone else that finds this thread, the issue was in the matrix I was using to transform the velocity vector. To correct the matrix I created an inverted view matrix and manually changed element 41,42,43,14,24,34 to equal 0 and element 44 to equal 1. This gave me the correct matrix to transform my velocity vector for anything attached to the camera (gun, flame thrower, etc...). Hope this helps someone else.
  24. [quote name='JWBaker' timestamp='1343321064' post='4963361'] I am working with a fixed timestep(not in the simple example obviously , but im my actual code). Also, you may not use vsync, but if i force it in my driver and i see this issues then im going to complain about how broken it is with vsync on [/quote] I don't think it's an issue with vSync or the driver but moreso, how you're handeling the input on a thread that is blocked until the monitor refresh occures and while the OS tries to vSync 2 desktops. [quote name='JWBaker' timestamp='1343321064' post='4963361'] The fact that this does not show up in other DX games is making me lean toward somethign in the managed code [/quote] Maybe these other games are processing input on another thread when vSync is enabled. Just sayin...
  • Advertisement