
Advertisement
raigan
Member
Content Count
303 
Joined

Last visited
Community Reputation
1111 ExcellentAbout raigan

Rank
Member
Personal Information

Role
3D Animator

Interests
Programming
Recent Profile Visitors
The recent visitors block is disabled and is not being shown to other users.

It seems like what you're trying to do is polygon offsetting: https://stackoverflow.com/questions/1109536/analgorithmforinflatingdeflatingoffsettingbufferingpolygons This can be tricky in the general case, but there are several libs/algos available that should help you linked in that thread. (Maybe you're trying to do what you literally said  scale a triangle away from its centroid  in which case there are easier solutions. It just seemed like in general what you were after was offsetting) A simple way to offset a polygon that I've used in the past is to move each vertex along the average of the normals of the edges adjacent to that vertex. eg: //given vec2 a,b,c (counterclockwise ordered verts) and offset distance r: vec2 n0 = Perp(ba)/Len(ba);//n0,n1 are outwardfacing normals adjacent to b vec2 n1 = Perp(cb)/Len(cb);//Perp(v) is vec2(v.y,v.x), Len(v) is Sqrt(v.x*v.x + v.y*v.y) vec2 n = n0 + n1; vec2 b2 = b + n*(r / (n.x*n.x + n.y*n.y)); Note that you might need to use Perp(v)=(v.y, v.x) depending on whether +y is up or down in your coordinate system. Anyway this will still work it'll just offset stuff inward so you'll know you need to multiply something by 1 to fix it

Practical (robust) vertexface continuous collision detection?
raigan replied to sebjf's topic in Math and Physics
thanks for the link sebjf, I just assumed that site was the usual scammy paywall  cheers 
Practical (robust) vertexface continuous collision detection?
raigan replied to sebjf's topic in Math and Physics
Do you know of a public version of this paper anywhere? All I can find is various paywalls 
I meant the *original* Bridge Builder game https://en.wikipedia.org/wiki/Bridge_Builder It's quite possible Bridge Constructor is using FEM! Gish also uses penaltymethod + really tiny steps, since it's by the same author.

I know that the original Bridge Builder uses particles + springs with very small timesteps to keep things stable, similar to this paper: http://www.uniweimar.de/~caw/papers/p7kacicalesic.pdf Other games have used a similar approach, for example I would bet that Rigs of Rods works the same way since they've mentioned that their simulator runs at 1000hz. The game is open source so you can poke around and see how it works: https://github.com/RigsOfRods/rigsofrods

Problems in [Cloth Simulation] with Verlet Integration
raigan replied to YoungX's topic in Math and Physics
Thanks raigan, I tried something like below: FindCollisionParticles(); // if found one, then mark this particle isActive = false; which makes it also not movable by its physical update or constraints. for (num_iterations) { SolveDistanceConstraints(); } // at the end of the update RecoverDeactivatedParticles(); // Reactive particles that are marked deactive in FindCollisionParticles(); Somehow this doesn't work for me. Sorry, maybe I didn't explain very well: you need to handle collision *just like a constraint*, i.e you need to solve both collisions and other constraints together in the loop, otherwise the solver won't converge nicely. Something like: for (num_iterations) { SolveDistanceConstraints(); SolveCollisionConstraints(); } This way the constraint forces can "talk" to each other and find a mutually acceptable equilibrium state. Of course: what does SolveCollisionConstraints() look like? There are many ways of implementing this; the unoptimized version is to run a full broad+narrow phase collision in here, but that gets slow. Instead you can cache the pairs returned by the broadphase before solving, and rerun narrow phase (i.e calculate the vertface or edgeedge penetration depth and project out of collision if the two features are penetrating). JoeJ's approach also works, AFAICT it's Jacobi iterations instead of GaussSeidel  see the paper "Mass Splitting for JitterFree Parallel Rigid Body Simulation" for more info: IIRC you shouldn't be scaling by some arbitrary number but instead averaging all particle displacements based on relative mass. The paper has more details. The downside to Jacobi is that it converges more slowly. 
Problems in [Cloth Simulation] with Verlet Integration
raigan replied to YoungX's topic in Math and Physics
This isn't as complicated a problem as you think  you just need to remember that collision constraints are a type of constraint, and solve them *together* with the distance constraints in your solving loop. eg something like: for(num_solver_iterations) { SolveDistanceConstraints(); SolveCollisionConstraints(); } Of course, this moves collision detection to inside your solver loop, which is bad for performance. Typically people cache the broadphase and update the narrow phase, i.e your collision data knows the face+vertex that are colliding, and when solving the collision constraint you first check if collision is happening (which you have to do anyway to calculate the error term) and if not you skip solving it this iteration. I hope this makes sense! 
Orientation and angular velocity of particle cloud
raigan replied to h4tt3n's topic in Math and Physics
AFAICT this still requires some idea of a "rest pose"/starting configuration (the a_i unit vectors in the stackexchange reply). (Thanks so much btw, I hadn't realized there were approaches to this besides Muller's! Very interesting.) The OP wanted to know if there are any approaches that *don't* require some sort of initial state/rest pose. 
Orientation and angular velocity of particle cloud
raigan replied to h4tt3n's topic in Math and Physics
I'm not an expert but I don't think that your conclusion necessarily follows. It just doesn't make sense to me: particles only have a defined position, not an orientation. You can aggregate their positions to get a COM, which helps you define all the other properties you listed (eg angular momentum doesn't make sense for a particle in isolation, but does relative to the COM), but AFAICT the COM doesn't help define an orientation. I'm struggling to see how you could define orientation without some sort of frame of reference similar to that provided by a rest pose. 
Orientation and angular velocity of particle cloud
raigan replied to h4tt3n's topic in Math and Physics
I am using this method to analyze and control deformable soft bodies in a physics engine. When creating an object of a particular, well defined shape, like for instance a truss or girder with the orientation vector pointing along the length of the body, I can see on screen how the orientation (visualized by a point and a line) drifts away from the physical shape. This happens slowly by simply adding angular velocity and letting it rotate unconstrained by external forces. When influencing it through collision or by constraining it to other bodies, the orientation quickly drifts away from the correct value. This seems like the exact usecase for shape matching  i.e you start with a particular arrangement of particles. Why exactly do you want to avoid having to define a "rest pose"? 
Orientation and angular velocity of particle cloud
raigan replied to h4tt3n's topic in Math and Physics
This seems related to "shape matching"; this recent paper should have lots of useful references (and itself presents a method to extract rotation from a point cloud): http://matthiasmuellerfischer.ch/publications/stablePolarDecomp.pdf Note that AFAICT you'll need some sort of "rest pose" defined for the points or the concept of orientation doesn't make a lot of sense. 
Help understanding term in XPBD (position based dynamics) paper
raigan replied to coderchris's topic in Math and Physics
Awesome! I'm glad that works :) Thanks for letting me know about those details  I wonder if it's an error in the paper or what. Do normalized constraints offer any benefits? I've never come across them before. 
Help understanding term in XPBD (position based dynamics) paper
raigan replied to coderchris's topic in Math and Physics
I'm a bit rusty but IIRC in PBD gradC is a vector, which means gradC(xi  x^n) might be a dot product, projecting the approximate velocity (xi  x^n) onto the constraint gradient gradC. This is just a guess! Please let me know if you work it out, because I'd like to try implementing this too. :) 
hey  no worries, it's a hard problem! One thing that might have slipped under your radar is the physicsbased locomotion R&D that Cryptic Sea are doing (in conjunction with their games Sub Rosa and A New Zero): https://twitter.com/crypticsea/status/796871092438605824

awesome! One thing I thought of, have you read any of Michiel van de Panne's papers? He does a lot of research into control of physicsdriven characters: https://www.cs.ubc.ca/~van/papers/Simbicon.htm https://www.cs.ubc.ca/~van/papers/2010TOGgbwc/index.html https://www.cs.ubc.ca/~van/papers/2013TOGMuscleBasedBipeds/index.html http://www.cs.mcgill.ca/~kry/pubs/abc/index.html https://www.cs.ubc.ca/~van/papers/2015CGFmultiskilled/index.html

Advertisement