
Advertisement

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 ExcellentAbout Dirk Gregorius

Rank
Contributor
Personal Information

Role
Programmer

Interests
Business
Programming
Recent Profile Visitors

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.guerrillagames.com/read/creatingatoolspipelineforhorizonzerodawn 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

Resolving contact and frictional forces using constraints
Dirk Gregorius replied to mjjq's topic in Math and Physics
Yes, and you also need a fallback if the relative velocity in the tangent plane becomes zero. Otherwise t will be the zero vector. 
Resolving contact and frictional forces using constraints
Dirk Gregorius replied to mjjq's topic in Math and Physics
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 warmstarting. 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 
Resolving contact and frictional forces using constraints
Dirk Gregorius replied to mjjq's topic in Math and Physics
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. 
The problem with friction is the coupling of the friction forces to the normal (nonpenetration) 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

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

Decent online resources for maths refreshers
Dirk Gregorius replied to Greedy Goblin's topic in Math and Physics
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 
Is it worth it for me to try to use a physics engine?
Dirk Gregorius replied to Gnollrunner's topic in Engines and Middleware
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 runtime 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. 
Is it worth it for me to try to use a physics engine?
Dirk Gregorius replied to Gnollrunner's topic in Engines and Middleware
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 (untransformed) 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 nonuniform 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. 
Is it worth it for me to try to use a physics engine?
Dirk Gregorius replied to Gnollrunner's topic in Engines and Middleware
Even in that case it is not as trivial as just nonuniformly 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 nonuniform scaling does not preserver angles so you need to be careful when transforming to sphere space. 
Is it worth it for me to try to use a physics engine?
Dirk Gregorius replied to Gnollrunner's topic in Engines and Middleware
This is clearly wrong! Angles are not preserved under nonuniform scaling. The closest point to a circle is not necessarily the closest point to an ellipse after rescaling back!. See example below. 
Continuous GJK for Linear Translations
Dirk Gregorius replied to DrDeath3191's topic in Math and Physics
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. 
FBX SDK skinned animation
Dirk Gregorius replied to mrMatrix's topic in General and Gameplay Programming
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 ); // Renormalize weights such that they add up to 1 Normalize( Influences ); } HTH, Dirk 
Sorry, no idea. I just copied it here when I came across it. Maybe I was scrubbing or went backwards in the browser history.

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

Advertisement