<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en-gb">
	<link rel="self" type="application/atom+xml" href="https://pybullet.org/Bullet/phpBB3/app.php/feed/topic/140" />

	<title>Real-Time Physics Simulation Forum</title>
	
	<link href="https://pybullet.org/Bullet/phpBB3/index.php" />
	<updated>2005-10-11T09:17:36+00:00</updated>

	<author><name><![CDATA[Real-Time Physics Simulation Forum]]></name></author>
	<id>https://pybullet.org/Bullet/phpBB3/app.php/feed/topic/140</id>

		<entry>
		<author><name><![CDATA[gino]]></name></author>
		<updated>2005-10-11T09:17:36+00:00</updated>

		<published>2005-10-11T09:17:36+00:00</published>
		<id>https://pybullet.org/Bullet/phpBB3/viewtopic.php?p=368#p368</id>
		<link href="https://pybullet.org/Bullet/phpBB3/viewtopic.php?p=368#p368"/>
		<title type="html"><![CDATA[Re: Barycentric coordiantes and voronoi solver]]></title>

		
		<content type="html" xml:base="https://pybullet.org/Bullet/phpBB3/viewtopic.php?p=368#p368"><![CDATA[
<blockquote class="uncited"><div><blockquote class="uncited"><div>Which GJK implementation requires more information from the simplex solver, and how does it use this exactly, JMC ?<br>Erwin</div></blockquote>The whole reason I brought this up was because SOLID uses the values even in the case that the simplex is full. Look at SOLIDs common_point and closest_points in DT_Convex.cpp.<br><br>Clarification: Both of those functions bail out of the gjk loop when there is a full simplex, but then they call gjk.compute_points which use the barycentric coordinates.</div></blockquote>In case of a full simplex the Johnson routine returns the barycentric coordinates of the origin (four parameters corresponding to the four vertices of a tetrahedron). You need these to compute a common point (In case of an intersection the closest points coinicde.) How to compute a common point or a pair of closest points from the barycentric coordinates is explained on page 141 of my book. In case you want to return a boolean only or want to compute the penetration depth, you do not need the barycentric coordinates of the origin for a full simplex. Hope this helps.        <br><br>Cheers,<p>Statistics: Posted by <a href="https://pybullet.org/Bullet/phpBB3/memberlist.php?mode=viewprofile&amp;u=4">gino</a> — Tue Oct 11, 2005 9:17 am</p><hr />
]]></content>
	</entry>
		<entry>
		<author><name><![CDATA[John McCutchan]]></name></author>
		<updated>2005-10-11T00:21:18+00:00</updated>

		<published>2005-10-11T00:21:18+00:00</published>
		<id>https://pybullet.org/Bullet/phpBB3/viewtopic.php?p=367#p367</id>
		<link href="https://pybullet.org/Bullet/phpBB3/viewtopic.php?p=367#p367"/>
		<title type="html"><![CDATA[Re: Barycentric coordiantes and voronoi solver]]></title>

		
		<content type="html" xml:base="https://pybullet.org/Bullet/phpBB3/viewtopic.php?p=367#p367"><![CDATA[
<blockquote class="uncited"><div>Which GJK implementation requires more information from the simplex solver, and how does it use this exactly, JMC ?<br>Erwin</div></blockquote>The whole reason I brought this up was because SOLID uses the values even in the case that the simplex is full. Look at SOLIDs common_point and closest_points in DT_Convex.cpp.<br><br>Clarification: Both of those functions bail out of the gjk loop when there is a full simplex, but then they call gjk.compute_points which use the barycentric coordinates.<p>Statistics: Posted by <a href="https://pybullet.org/Bullet/phpBB3/memberlist.php?mode=viewprofile&amp;u=148">John McCutchan</a> — Tue Oct 11, 2005 12:21 am</p><hr />
]]></content>
	</entry>
		<entry>
		<author><name><![CDATA[Erwin Coumans]]></name></author>
		<updated>2005-10-09T02:00:32+00:00</updated>

		<published>2005-10-09T02:00:32+00:00</published>
		<id>https://pybullet.org/Bullet/phpBB3/viewtopic.php?p=364#p364</id>
		<link href="https://pybullet.org/Bullet/phpBB3/viewtopic.php?p=364#p364"/>
		<title type="html"><![CDATA[Re: Barycentric coordiantes and voronoi solver]]></title>

		
		<content type="html" xml:base="https://pybullet.org/Bullet/phpBB3/viewtopic.php?p=364#p364"><![CDATA[
<blockquote class="uncited"><div> When P lies inside ABCD, P itself is the closest point Q; this case falls out directly based on how the testing is performed so I'm a bit surprised to hear you say the Bullet implementation does not handle it.</div></blockquote>Bullet detects the case where the origin lies within the tetrahedron in VoronoiSimplexSolver.cpp here:<div class="codebox"><p>Code: </p><pre><code>00468    if (!pointOutsideABC  &amp;&amp; !pointOutsideACD &amp;&amp; !pointOutsideADB &amp;&amp; !pointOutsideBDC)00469          {00470                  return false;00471          }</code></pre></div>So this case is handled by Bullet by detecting it, and based on this result the GJK loop terminates. Then penetration depth calculation is performed and a penetration information is reported. So in this case, the barycentric coordinates of the origin/P are not calculated, because GJK will terminate anyway.<br><br>Which GJK implementation requires more information from the simplex solver, and how does it use this exactly, JMC ?<br><br>Erwin<p>Statistics: Posted by <a href="https://pybullet.org/Bullet/phpBB3/memberlist.php?mode=viewprofile&amp;u=2">Erwin Coumans</a> — Sun Oct 09, 2005 2:00 am</p><hr />
]]></content>
	</entry>
		<entry>
		<author><name><![CDATA[Christer Ericson]]></name></author>
		<updated>2005-10-08T20:58:49+00:00</updated>

		<published>2005-10-08T20:58:49+00:00</published>
		<id>https://pybullet.org/Bullet/phpBB3/viewtopic.php?p=363#p363</id>
		<link href="https://pybullet.org/Bullet/phpBB3/viewtopic.php?p=363#p363"/>
		<title type="html"><![CDATA[Re: Barycentric coordiantes and voronoi solver]]></title>

		
		<content type="html" xml:base="https://pybullet.org/Bullet/phpBB3/viewtopic.php?p=363#p363"><![CDATA[
<blockquote class="uncited"><div>Could you tell me, do you provide an explanation on how to project the origin onto a tetrahedron? Some of the gjk algorithms still require it, even in the case where the origin is inside the tetrahedron. Currently bullet's implementation doesn't handle that case.</div></blockquote>What you're asking for is a special case of finding the point Q of a tetrahedron ABCD closest to a given query point P (where, in your question, P is the origin). Yes, I cover the general problem in Section 5.1.6 (and again in Section 9.5.2). When P lies inside ABCD, P itself is the closest point Q; this case falls out directly based on how the testing is performed so I'm a bit surprised to hear you say the Bullet implementation does not handle it.  If you can provide a test case of a query point and four tetrahedron vertices for which you consider the code broken, I'm sure Erwin can verify if the code has a problem, and if so, fix it.<p>Statistics: Posted by <a href="https://pybullet.org/Bullet/phpBB3/memberlist.php?mode=viewprofile&amp;u=8">Christer Ericson</a> — Sat Oct 08, 2005 8:58 pm</p><hr />
]]></content>
	</entry>
		<entry>
		<author><name><![CDATA[John McCutchan]]></name></author>
		<updated>2005-10-04T03:23:24+00:00</updated>

		<published>2005-10-04T03:23:24+00:00</published>
		<id>https://pybullet.org/Bullet/phpBB3/viewtopic.php?p=352#p352</id>
		<link href="https://pybullet.org/Bullet/phpBB3/viewtopic.php?p=352#p352"/>
		<title type="html"><![CDATA[Re: Barycentric coordiantes and voronoi solver]]></title>

		
		<content type="html" xml:base="https://pybullet.org/Bullet/phpBB3/viewtopic.php?p=352#p352"><![CDATA[
<blockquote class="uncited"><div>These calculations are from my book, where I describe in detail where the terms come from (in several steps, one more optimized than another).</div></blockquote>I currently can't afford your book, but I do plan on picking it up in the near future. Could you tell me, do you provide an explanation on how to project the origin onto a tetrahedron? Some of the gjk algorithms still require it, even in the case where the origin is inside the tetrahedron. Currently bullet's implementation doesn't handle that case.<p>Statistics: Posted by <a href="https://pybullet.org/Bullet/phpBB3/memberlist.php?mode=viewprofile&amp;u=148">John McCutchan</a> — Tue Oct 04, 2005 3:23 am</p><hr />
]]></content>
	</entry>
		<entry>
		<author><name><![CDATA[Christer Ericson]]></name></author>
		<updated>2005-10-01T06:15:23+00:00</updated>

		<published>2005-10-01T06:15:23+00:00</published>
		<id>https://pybullet.org/Bullet/phpBB3/viewtopic.php?p=349#p349</id>
		<link href="https://pybullet.org/Bullet/phpBB3/viewtopic.php?p=349#p349"/>
		<title type="html"><![CDATA[Re: Barycentric coordiantes and voronoi solver]]></title>

		
		<content type="html" xml:base="https://pybullet.org/Bullet/phpBB3/viewtopic.php?p=349#p349"><![CDATA[
<blockquote class="uncited"><div>Sorry, I didn't phrase my question properl. I'd like to understand the geometry behind your calculations. I understand the geometry behind d1 &amp; d2 but what is the geometry behind d3,d4,d5,d6, vc, vb, and va. A reference to where you developed this formula would be appreciated.</div></blockquote>These calculations are from my book, where I describe in detail where the terms come from (in several steps, one more optimized than another).<p>Statistics: Posted by <a href="https://pybullet.org/Bullet/phpBB3/memberlist.php?mode=viewprofile&amp;u=8">Christer Ericson</a> — Sat Oct 01, 2005 6:15 am</p><hr />
]]></content>
	</entry>
		<entry>
		<author><name><![CDATA[John McCutchan]]></name></author>
		<updated>2005-09-26T03:45:39+00:00</updated>

		<published>2005-09-26T03:45:39+00:00</published>
		<id>https://pybullet.org/Bullet/phpBB3/viewtopic.php?p=348#p348</id>
		<link href="https://pybullet.org/Bullet/phpBB3/viewtopic.php?p=348#p348"/>
		<title type="html"><![CDATA[Re: Barycentric coordiantes and voronoi solver]]></title>

		
		<content type="html" xml:base="https://pybullet.org/Bullet/phpBB3/viewtopic.php?p=348#p348"><![CDATA[
<blockquote class="uncited"><div>The projection of the origin into the triangle plane happens here:<br><a href="http://www.continuousphysics.com/Bullet/BulletFull/html/VoronoiSimplexSolver_8cpp-source.html" class="postlink">http://www.continuousphysics.com/Bullet ... ource.html</a><div class="codebox"><p>Code: </p><pre><code>00405     // P inside face region. Compute Q through its barycentric coordinates (u,v,w)00406     float denom = 1.0f / (va + vb + vc);00407     float v = vb * denom;00408     float w = vc * denom;00410         result.m_closestPointOnSimplex = a + ab * v + ac * w;00414         result.SetBarycentricCoordinates(1-v-w,v,w);</code></pre></div></div></blockquote>Sorry, I didn't phrase my question properl. I'd like to understand the geometry behind your calculations. I understand the geometry behind d1 &amp; d2 but what is the geometry behind d3,d4,d5,d6, vc, vb, and va. A reference to where you developed this formula would be appreciated.<br><blockquote class="uncited"><div><blockquote class="uncited"><div>Q2) When you have a full simplex, and you can't reduce it down to a smaller one, you just give up. Don't some uses of the gjk algorithm require you to calculate the lambda values even if you end up with a full simplex? An example that comes to mind is closest points on objects.</div></blockquote>There are two cases in which the simplex solver will terminate the Bullet GJK implementation:<br><br>1) No reduction is done, because the origin is inside the tetrahedron. This means means the two convex objects are penetrating. The GJK outerloop will break. <br></div></blockquote>This is the case I was asking about, some of the gjk algorithms still attempt to compute some values even when the simplex couldn't be reduced. Examples from solid, DT_Convex.cpp::common_point, DT_Convex.cpp::closest points. I don't how accurate these values will be even if the system of equations was solved, because like you say, the origin is inside the tetrahedron, and the objects are in penetration.<p>Statistics: Posted by <a href="https://pybullet.org/Bullet/phpBB3/memberlist.php?mode=viewprofile&amp;u=148">John McCutchan</a> — Mon Sep 26, 2005 3:45 am</p><hr />
]]></content>
	</entry>
		<entry>
		<author><name><![CDATA[Erwin Coumans]]></name></author>
		<updated>2005-09-25T14:43:43+00:00</updated>

		<published>2005-09-25T14:43:43+00:00</published>
		<id>https://pybullet.org/Bullet/phpBB3/viewtopic.php?p=347#p347</id>
		<link href="https://pybullet.org/Bullet/phpBB3/viewtopic.php?p=347#p347"/>
		<title type="html"><![CDATA[Re: Barycentric coordiantes and voronoi solver]]></title>

		
		<content type="html" xml:base="https://pybullet.org/Bullet/phpBB3/viewtopic.php?p=347#p347"><![CDATA[
<blockquote class="uncited"><div> Q1) I've been studying up on barycentric coordinates of a triangle, and from what I've read it's only defined if the point P lies in the plane of the triangle. I can't seem to find where in the code you project the origin onto the plane of the triangle. </div></blockquote>The projection of the origin into the triangle plane happens here:<br><a href="http://www.continuousphysics.com/Bullet/BulletFull/html/VoronoiSimplexSolver_8cpp-source.html" class="postlink">http://www.continuousphysics.com/Bullet ... ource.html</a><div class="codebox"><p>Code: </p><pre><code>00405     // P inside face region. Compute Q through its barycentric coordinates (u,v,w)00406     float denom = 1.0f / (va + vb + vc);00407     float v = vb * denom;00408     float w = vc * denom;00410         result.m_closestPointOnSimplex = a + ab * v + ac * w;00414         result.SetBarycentricCoordinates(1-v-w,v,w);</code></pre></div><blockquote class="uncited"><div>Q2) When you have a full simplex, and you can't reduce it down to a smaller one, you just give up. Don't some uses of the gjk algorithm require you to calculate the lambda values even if you end up with a full simplex? An example that comes to mind is closest points on objects.</div></blockquote>There are two cases in which the simplex solver will terminate the Bullet GJK implementation:<br><br>1) No reduction is done, because the origin is inside the tetrahedron. This means means the two convex objects are penetrating. The GJK outerloop will break. <br><br>2) Degenerate simplex, 3 or more points that are co-linear. This will also terminate the GJK loop. Degeneracy can also be caused by cancellation, as Gino stated before, this can be a problem in cases with large difference in feature sizes. If this is really a problem, some improvements can be made by re-ordering calculations to remove this cancellation effect.<br><br>In both cases either the current seperating distance is within the chosen collision-margins there will be a closest point result (penetration) reported, or a seperate user-provided penetration depth algorithm will be used.<br><br>Erwin<p>Statistics: Posted by <a href="https://pybullet.org/Bullet/phpBB3/memberlist.php?mode=viewprofile&amp;u=2">Erwin Coumans</a> — Sun Sep 25, 2005 2:43 pm</p><hr />
]]></content>
	</entry>
		<entry>
		<author><name><![CDATA[John McCutchan]]></name></author>
		<updated>2005-09-22T03:29:58+00:00</updated>

		<published>2005-09-22T03:29:58+00:00</published>
		<id>https://pybullet.org/Bullet/phpBB3/viewtopic.php?p=346#p346</id>
		<link href="https://pybullet.org/Bullet/phpBB3/viewtopic.php?p=346#p346"/>
		<title type="html"><![CDATA[Barycentric coordiantes and voronoi solver]]></title>

		
		<content type="html" xml:base="https://pybullet.org/Bullet/phpBB3/viewtopic.php?p=346#p346"><![CDATA[
Q1) I've been studying up on barycentric coordinates of a triangle, and from what I've read it's only defined if the point P lies in the plane of the triangle. I can't seem to find where in the code you project the origin onto the plane of the triangle. <br><br>Q2) When you have a full simplex, and you can't reduce it down to a smaller one, you just give up. Don't some uses of the gjk algorithm require you to calculate the lambda values even if you end up with a full simplex? An example that comes to mind is closest points on objects.<p>Statistics: Posted by <a href="https://pybullet.org/Bullet/phpBB3/memberlist.php?mode=viewprofile&amp;u=148">John McCutchan</a> — Thu Sep 22, 2005 3:29 am</p><hr />
]]></content>
	</entry>
	</feed>
