Jump to content
  • Advertisement

Randy Gaul

Member
  • Content Count

    427
  • Joined

  • Last visited

Community Reputation

2806 Excellent

2 Followers

About Randy Gaul

  • Rank
    Member

Recent Profile Visitors

9409 profile views
  1. Randy Gaul

    Continuous GJK for Linear Translations

    You're right, I was just referring to the triangle case. I suspect a common thing to do for TOI solvers is to apply a buffer radius around each shape for the GJK function to work with. This can give GJK some breathing room. In effect, this applies a tolerance buffer zone around shapes that counts as colliding as far as the TOI solver goes. I personally haven't tried getting into this kind of tuning very in-depth yet, so maybe Dirk can have some more specific advice for you.
  2. For sphere to triangle you can use GJK to compute closest points between the sphere's center and the triangle. Given these, computing a manifold becomes trivial. For other convexes to triangle, I have used SAT between convex meshes. It's also possible to store adjacency information between triangles in your heightmap, and collide convex meshes against these (this way you can avoiding "interior edge" collisions by properly representing the Voronoi regions of shared edges between triangles). Be sure to look up Dirk's resources from GDC 2013-2015 at box2d.org/downloads. I would recommend to stop reading Ian Millington's book. It's not state of the art and uses a lot of out-dated technology. It's an OK book for an introduction to collision detection, but as you are noticing in your post, it must quickly be retired in favor of other resources.
  3. Randy Gaul

    Continuous GJK for Linear Translations

    Oh my old 3D code doesn't do that snapping thing. I suggest looking at my 2D stuff I linked earlier -- it does the snapping thing there. My old code is nice to see as a general idea of what 3D can look like, but I haven't touched it for a long time. Actually not that long ago (like 5 months ago) someone pointed out a bug in my old 3D code! The bug was like 3 years old. So to reiterate, I would put trust in Erin's resources, and then expand from there (which sounds like what you're doing, so that's great). I still need to do more testing with my linear CA implementation, like checking for 0 velocity bound, make sure the end conditions are strong. My tolerance can also probably be reduced further. I might want to shrink or expand the collision shapes by a radius factor. I'm not sure yet.
  4. Randy Gaul

    Continuous GJK for Linear Translations

    In colliding cases my implementation snaps the vertices together and manually sets the distance to zero. GJK is perfectly good at detecting intersection. It does get a little difficult in the “almost intersecting with a tiny distance”, but this kind of problem can be successfully mitigated.
  5. Randy Gaul

    D3D9 Shader Constant Update Frequency

    Got the answer: https://twitter.com/grumpygiant/status/1059705960162197504 Gotta update them every time. The constants are just in a table, no special caching.
  6. In OpenGL a shader uniform can be in a program, and then never updated. If the program is unbound, another shader is used, and then rebound, the old uniform value will stay in-tact. This was the behavior I expected from D3D9. Unfortunately I'm mostly referencing Frank Luna's DX9 book, which covers FX and not the HLSL alternatives. So I'm at a lack of information a lot of the time. If anyone has a suggestion on better resources/references let me know! I had this terrible problem in another thread, and it came down to setting shader constants once for each shader, and then never updating them again thereafter. My shader constant updating code cached values on the CPU with a dirty flag, sort of like this: for (int i = 0; i < uniform_count; ++i) { uniform_t* u = uniforms + i; if (u->dirty) { update_shader_constant(u); u->dirty = 0; } } Is this kind of caching not valid when swapping between different shaders from one draw call to another? Is this because constants are mapped to registers, and those register values are not saved/associated with specific shaders? Any links on advice for optimized ways to update constants? I'm assuming SetVertexShaderConstantF is the best thing to do each frame?
  7. Randy Gaul

    D3D9 Render to Texture Problem

    Well. No idea what the problem is, but I made an entirely new repo and reimplemented everything, and it all works. Thanks everyone for popping in and trying to help! Consider this thread mostly finished, since I'll eventually find the exact difference between the isolated repo and my bigger project. Here's the working repo: https://github.com/RandyGaul/d3d9-Render-to-Texture Edit: Found the culprit. I was caching shader constants and not updating them every frame. I suppose caching them is not a valid thing to do when switching between different shaders, overriding register values. Made followup question:
  8. Randy Gaul

    D3D9 Render to Texture Problem

    I took apart one of Frank Luna's example source for rendering terrain as a minimap via render to texture. I replaced his render target code with mine, and it all worked. I'm pretty convinced the problem is just in my do_draw_calls_d3d9 function. So I'll post up the source for that here. Still tinkering with things, but if anyone spots something odd, please let me know.
  9. Randy Gaul

    D3D9 Render to Texture Problem

    I've already written texture out to file in a few ways. For now strategy I'm going to go with, is to get an old SDK sample building, and then change out their DrawPrimitiveUP to DrawPrimitive, and see if that works. There's got to be a subtle difference somewhere... Like I noticed the SDK samples are constantly freeing up references to surfaces all over. I think they are just trying to make their sample code "generic" by preserving whatever previous surface was bound as render target, but it's worth a try. Also Mitton just suggested on twitter to use Intel's frame analyzer, since he said it probably still works with D3D9: https://twitter.com/grumpygiant/status/1059530944531521536 This might be worthwhile. Any other ideas? I'm open to try anything at this point.
  10. Randy Gaul

    D3D9 Render to Texture Problem

    There is no depth buffer, it's just a color buffer. Setting to 1.0f doesn't change any behavior. Just tried unbinding all textures after each draw call -- no dice. Plus, if I couldn't bind the texture as render target I would get an error code return value, or I wouldn't have been able to render anything to screen. But OP shows I was able to render to screen, but only once.
  11. Randy Gaul

    D3D9 Render to Texture Problem

    Oh gotcha. That makes total sense. I'll try round-robin on this tomorrow and see how that works... Usage flag for the texture is D3DUSAGE_RENDERTARGET, and pool is D3DPOOL_DEFAULT. One thing I don't really understand, is that none of the DirectX SDK samples are cycling through double/triple buffered textures, and they seem to run fine. Also Mitton isn't doing any buffering in his tigr library: https://bitbucket.org/rmitton/tigr/src/be3832bee7fb2f274fe5823e38f8ec7fa94e0ce9/src/tigr_d3d9.c?at=default&amp;fileviewer=file-view-default#tigr_d3d9.c-169:248 So I'm not exactly sure why I would need to.
  12. I'm using D3D9 to render to a texture, and I want to then render that texture to a fullscreen quad. I'm able to render to the texture just fine, and have verified this in a few ways (more on that later). My problem is very odd: if I ever attempt to render this texture onto the screen as a full-screen quad, I am only able to render to the texture *once*. By once I mean all subsequent attempts to render to texture will return no error codes, however, the texture contents will never get updated. --- Here's how I'm creating my texture render target: IDirect3DTexture9* texture; HRESULT res = impl->dev->CreateTexture(w, h, 0, D3DUSAGE_RENDERTARGET, D3DFMT_A8R8G8B8, D3DPOOL_DEFAULT, &texture, NULL); IDirect3DSurface9* texture_surface; res = texture->GetSurfaceLevel(0, &texture_surface); Rendering to the texture: HR_CHECK(impl->dev->SetRenderTarget(0, texture_surface)); HR_CHECK(impl->dev->Clear(0, NULL, D3DCLEAR_TARGET, 0xFF0000FF, far_dist, 0)); HR_CHECK(impl->dev->BeginScene()); // gather up all the draw calls and submit them // not shown to keep things short... do_draw_calls_d3d9(gfx); HR_CHECK(impl->dev->EndScene()); And rendering texture to fullscreen quad: HR_CHECK(impl->dev->SetRenderTarget(0, screen_surface)); HR_CHECK(impl->dev->BeginScene()); HR_CHECK(impl->dev->Clear(0, NULL, D3DCLEAR_TARGET, 0xFFFF0000, far_dist, 0)); // create draw call for full-screen quad here // not shown to keep things short... do_draw_calls_d3d9(gfx); HR_CHECK(impl->dev->EndScene()); impl->dev->Present(NULL, NULL, NULL, NULL); So to test this stuff I made a checkerboard sprite, spawn it in the center of the screen, and start translating it to the right over time. This is rendered to the texture. Problems arise when I try to run the third code snippet, to render the texture on screen as a full-screen quad. I noticed the entire screen was simply the clear color blue (0xFF0000FF). First thing I did to figure out why the sprite didn't show up, but the clear color did, was to use D3DXSaveTextureToFile. Now the saved image is completely blue as well. Next thing I tried was to simply delete the clear line for the texture, and see what happens. Oddly enough, the checkerboard sprite shows up on screen! I am clearing the screen background itself to red (0xFFFF0000). So there should be no blue anywhere, since I deleted the clear to blue line for the render to texture snippet. Here's a screenshot: OK. Strange. The sprite is rendered correctly to the texture, and the texture is rendered correctly to the screen. But the sprite is *not* translating over time. I attempt to save the the texture to file again, and as shown on screen, the texture itself is not scrolling at all (this was saved after a few seconds, and the sprite should have been moving quite far to the right by now). Very weird. Next thing I tried was to comment out all the code in my third snippet, the code for drawing a full-screen quad. The only code running at this point is the render to texture code snippet. Here's the image after a few seconds of scrolling the checkerboard sprite to the right: There's a nice smearing effect since I'm not clearing the texture contents each render pass. This means that somehow the render target texture is only updated *one time* after it is drawn on the full-screen quad. That update can be a clear to blue, or it can be rendering the sprite itself. I made one final test. I replaced the third code snippet with this one: HR_CHECK(impl->dev->StretchRect(texture_surface, NULL, screen_surface, NULL, D3DTEXF_POINT)); impl->dev->Present(NULL, NULL, NULL, NULL); This final snippet works exactly as expected, and I have no idea why. Here's a gif of the StretchRect implementation just to prove so: Anyone have any ideas what is going on here? Please let me know if anyone needs more information to help out. I must be missing something small. Maybe I need to call AddDirtyRect or something. I have no clue. I've tried all kinds of things and am currently stumped. Also tried running on a few different machines -- always the same behavior. If anyone knows where I can find a working example of render to texture for d3d9 let me know. All the DirectX SDK samples use DrawPrimitiveUP -- so they aren't exactly the same. I've been peeking around into different open source engines with directx9 renderers, but haven't just yet been able to see an example I can download and mess with myself.
  13. Randy Gaul

    Continuous GJK for Linear Translations

    I can maybe take a closer look tomorrow, but I can throw down some recommendations at least for now. Start with the 2D case first. Use Erin's old GJK demo from GDC as your starting point. Then you can modify his code, and morph it into yours. This strategy is effective because you can use Erin's code as a baseline, and each change you make, you can be sure if you introduced bugs or not. You also get the benefit of using Erin's very good debug rendering. Try to port your version, once verified working, to 3D. This is actually a straight-forward process, and assuming you've found my old code, you can see roughly what the 3D tetrahedron case can look like. Make sure you are still debug rendering, just like Erin's 2D demo. Caching all the iterations and looking at them can give you an idea of where your bugs may lie. Erin's demo: PDF, and demo. This is how I got a decent 3D GJK implementation up and going.
  14. Randy Gaul

    Angular Friction

    The formulation is almost identical to the normal response constraint. Just change normal N to tangent T. The two tangent axis are based on the normal constraint axis. Use any function you can think of that will take a vector as input and generate an orthonormal basis. The two new axes can be treated as your friction tangents. Erin posted a function a while ago: https://box2d.org/2014/02/computing-a-basis/ That's pretty much it. It works OK. You get sliding artifacts as one axis will converge before the other... You also get 2 extra constraints (one for each tangent axis) per normal contact -- this gets expensive and also deteriorates the solver's convergence. Two extra constraint per normal constraint is a lot. This is why Dirk was mentioning other "unpublished" strategies that are probably nicer because they use less constraints, and avoid the artifact I mentioned. I have an example of the cheesy Coloumb stuff here: https://github.com/RandyGaul/qu3e/blob/master/src/dynamics/q3ContactSolver.cpp#L152-L175 You can still get problems though. Like a sphere spinning -- there's no way for this tangent basis approach to account for actual spinning. All the Coloumb stuff is doing, is driving a specific contact point's velocity to zero, within the contact plane, and the forces are fed with inputs from the previous tick's normal force. Nowhere in this model is the angular velocity of the *body* taken into account (except when it contributes to the *linear* velocity of a contact point).
  15. Randy Gaul

    Angular Friction

    Some of the friction ideas I've seen around are quite simple. At the end of the day you will want to reduce the number of constraints as possible, and go with something straightforward. It won't be a mountain if you are comfortable formulating and solving constraints. The hard part is, in my opinion, coming up with a simple model and/or figuring out how to reduce inputs to the constraint solver. I know this isn't very specific info... I haven't done a custom solution myself. I always just did the super cheesy Coloumb approach Dirk described.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!