Jump to content
  • Advertisement

Dirk Gregorius

Member
  • Content Count

    1123
  • Joined

  • Last visited

  • Days Won

    2

Dirk Gregorius last won the day on August 16

Dirk Gregorius had the most liked content!

Community Reputation

2835 Excellent

4 Followers

About Dirk Gregorius

  • Rank
    Contributor

Personal Information

  • Role
    Programmer
  • Interests
    Business
    Programming

Recent Profile Visitors

14530 profile views
  1. Dirk Gregorius

    Starting point for game editor

    I think the best start is to look at ImGUI. There is a lot of activity there at the moment. And with Blizzard driving the development as the main sponsor you can expect some interesting development there in the future. https://github.com/ocornut/imgui In particular dock widgets are interesting in this context: https://github.com/ocornut/imgui/issues/2109 If you browse around the project you can find a bunch of smaller engine projects which use IMGui for their editors. Most notably Lumix here: https://github.com/nem0/LumixEngine Here is a good talk about tools in general I stumbled across recently : https://www.guerrilla-games.com/read/creating-a-tools-pipeline-for-horizon-zero-dawn Note that I am not arguing here that ImGUI is the new sexy. I am actually not convinced it is any better than more traditional GUI libraries like e.g. Qt. We use Qt at work and my experience with Qt has been excellent most of the time. Unfortunately there is less information publicly available how to write good game tools with Qt which I could point you to (or I am not aware of any). If you look at ATF I recommend to look at it as an example how not do it. In my opinion this is an example of *massive* over engineering. If you will use ATF for your tools you will end up with something that will be absurdly complicated for the problems you will be going to solve. In particular their comparison with Qt doesn't make sense and shows that the author doesn't know much about Qt in my opinion. HTH, -Dirk
  2. Yes, and you also need a fallback if the relative velocity in the tangent plane becomes zero. Otherwise t will be the zero vector.
  3. You only set the restitution bias once per prestep. There is a small gotcha though. Make sure you compute the relative approaching velocity for the restitution bias *before* you apply the warm-starting. Otherwise you will use wrong velocities. I would skip restitution initially though. There are very few objects that really need restitution. Designers sometimes thinks that you need restitution for stuff to tumble over, but this not the case. Restitution makes objects look lighter than they are most of the time which I personally try to avoid. There are a few exceptions though. E.g. ammunition shells. HTH, -Dirk
  4. That sounds about correct. Even with warmstarting the stack will sway a bit before it becomes stable. Also make sure you use a linear slop. This is important for contacts to persist between frames.
  5. Dirk Gregorius

    Angular Friction

    The problem with friction is the coupling of the friction forces to the normal (non-penetration) force. E.g. we have dC1/dt = (v2 + omega2 x r2 - v1 - omega1 x r1 ) * n and lambda1 >= 0 dC2/dt = (v2 + omega2 x r2 - v1 - omega1 x r1 ) * s and -mu * lambda1 <= lambda2 <= mu * lambda1 dC3/dt = (v2 + omega2 x r2 - v1 - omega1 x r1 ) * t and -mu * lambda1 <= lambda3 <= mu * lambda1 The problem we solve is not linear anymore. Practically it is not an LCP in the presence of friction. So all proofs about convergence don't hold anymore. There are a couple of ways to solve this thougj. The first is what Randy suggests and use the normal force from the last frame. This works pretty bad in practice. A better approach is to use the current accumulated normal force (which is changing every iteration). This is mathematically not well defined (at least I haven't seen any proofs here), but it works great in practice. The next issue with above formulation is that you are clamping against box and not a circle. There are two ways to solve this. The first is to align the first tangent direction with the relative velocity in the friction plane. This is very simple. v = vn + vt <=> v = (v * n) * n + vt => vt - = v - (v * n) * n Be careful when the relative velocity is zero. You need to fall back onto a geometric approach as described in Erin's blog post. A better way to solve the friction problem is to use circular clamping. You solve the the friction constraints as a 2x2 block system and then you clamp the length of vector. Finally what really makes the difference for friction for me is warmstarting. If your warmstarting doesn't work you will get poor friction and poor simulation quality. HTH, -Dirk
  6. Dirk Gregorius

    Angular Friction

    Usually, for every contact point, you solve one non-penetration and two friction constraints. The friction constraints depend on the non-penetration constraint (e.g. Coloumb friction). This is all you need. Other friction models exist, but I am not sure they have been published.
  7. Dirk Gregorius

    Decent online resources for maths refreshers

    I really like Essential Math for Game Developers. There is an associated math tutorial at GDC and you can get a lot of free resources on their website, but the book is really good as well: http://essentialmath.com/ Eric Lengyel (who is active here on the forum as well) has published some really good books on math (and more) as well: http://www.terathon.com/lengyel/ Finally my colleague Fletcher has written a really nice book on game specific math as well. It also comes with a bunch of free online resources. Look for the associated website. https://www.amazon.com/gp/product/1568817231/ref=dbs_a_def_rwt_bibl_vppi_i0
  8. Dirk Gregorius

    Is it worth it for me to try to use a physics engine?

    Yeah, e.g. Quake did this. The player was a sphere and the collision geometry was inflated (Minkowski sum) by the sphere radius so at run-time the player movement involved only point to plane tests. Note that this didn't mean they just scaled the render geometry, but they also needed to add new geometry (e.g. sweeping around corners - It is called bevel planes in the map files iirc.). Mathematically it is more of Minkowski addition than scaling.
  9. Dirk Gregorius

    Is it worth it for me to try to use a physics engine?

    I see, you are saying something like this: 1) Translate into origin, rotate to align with principal axes, scale to unit sphere 2) Apply same transform to ray 3) Compute t in unit sphere space 4) Compute intersection point in ellipse space - simply evaluate original (un-transformed) ray equation using the same t 5) Compute intersection normal in ellipse space - simply use ellipse gradient at intersection point I see that this might work, but my original point was *only* that you need to be careful with non-uniform scale and collision detection. As an example I used the closest point test. Before I would use this I would simply compute the intersection by plugging the parametric ray equation into the implicit ellipse equation and try to show that both are equivalent.
  10. Dirk Gregorius

    Is it worth it for me to try to use a physics engine?

    Even in that case it is not as trivial as just non-uniformly scaling back and forth between sphere and ellipse space. IIRC the trick for tracing a ray is to scale around the center of the ellipse since the center of scaling matters. The bottom line is that non-uniform scaling does not preserver angles so you need to be careful when transforming to sphere space.
  11. Dirk Gregorius

    Is it worth it for me to try to use a physics engine?

    This is clearly wrong! Angles are not preserved under non-uniform scaling. The closest point to a circle is not necessarily the closest point to an ellipse after re-scaling back!. See example below.
  12. Dirk Gregorius

    Continuous GJK for Linear Translations

    CA without rotations is very very easy. If you are looking for the simplest algorithm and only need linear movement this is the way to go. You can take Erin's code from above and just swap out the root finder which is trivial without rotations.
  13. Dirk Gregorius

    FBX SDK skinned animation

    You can do something like this: 1) Go over each cluster and collect vertex influences (bone index and weight) 2) Go over each array of influences (per vertex) and sort, resize, and normalize 3) Copy influences into your vertex structure struct VertexInfluence { int BoneIndex = 0; float BoneWeight = 0.0f; } // Sort influence by bone weight bool operator<( VertexInfluence Lhs, VertexInfluence Rhs ) { return Lhs.BoneWeight < Rhs.BoneWeight; } // Normalize bone weights such that they sum up to 1 void Normalize( std::vector< VertexInfluence >& Influences ) { float TotalWeight = 0.0f; for ( const VertexInfluence& Influence : Influences ) { TotalWeight += Influence.BoneWeight; } // This can happen if a vertex is not skinned if ( TotalWeight == 0.0f ) return; for ( const VertexInfluence& Influence : Influences ) { Influence.BoneWeight /= TotalWeight; } } // Collect vertex influences from clusters std::vector< std::vector< VertexInfluences > > VertexInfluences; VertexInfluences.resize( VertexCount ); for ( const Cluster* : mClusters ) { int BoneIndex = mBones.IndexOf( Cluster->Bone ); for ( int i = 0; i < Cluster->VertexCount; ++i ) { int VertexIndex = Cluster->VertexIndices[ i ]; float VertexWeight = Cluster->VertexWeights[ i ]; VertexInfluences[ VertexIndex ].push_back( { BoneIndex, VertexWeight } ); } } // Process influences for ( int i = 0; i < VertexCount; ++i ) { // For each vertex get the array of influences std::vector< VertexInfluence >& Influences = VertexInfluences[ i ]; // Sort influences by weight (largest weights first) std::sort( Influences.begin(), Influences.end() ); // Add zero weights if number of influence is smaller the needed or remove influences with smallest weights from back Influences.resize( MAX_BONE_COUNT ); // Re-normalize weights such that they add up to 1 Normalize( Influences ); } HTH, -Dirk
  14. Dirk Gregorius

    "Nice" tweakable S-function

    Sorry, no idea. I just copied it here when I came across it. Maybe I was scrubbing or went backwards in the browser history.
  15. Dirk Gregorius

    "Nice" tweakable S-function

    Then you will appreciate this one as well. Accidentally stumbled over it yesterday: https://www.youtube.com/watch?reload=9&v=mr5xkf6zSzk
  • Advertisement
×

Important Information

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

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!