# Randy Gaul

Member

427

2806 Excellent

• Rank
Member

• Website
• Role
Programmer
• Interests
Art
Audio
Design
Education
Programming

## Recent Profile Visitors

9409 profile views

1. ## 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. ## OBB-triangle and sphere-triangle contact data/manifold with SAT

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. ## 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. ## 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. ## 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.

7. ## 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. ## 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. ## 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. ## 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. ## 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.

13. ## 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. ## 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. ## 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.