melax / sandbox Goto Github PK

Wow, very very good example code!

Learning a lot! A like the minimalistic approach and also that it just compiles right of the box!!
Really cool!

But I'm a little bit confused.
In physics.h in the function ConstrainAngularRangeW.

What is exactly the "position constraint" for the angular limits?
Should it not be "current_angle - max_angle" but in the code I see
"2 x (sin(current_angle/2) - sin(max_angle/2))"
Is it possible to explain or where the derivation comes from? :) It really frustrates me!
I mean, this differs from the limits derivation of the hinge joint in the document http://danielchappuis.ch/download/ConstraintsDerivationRigidBody3D.pdf

And

if(jmax.x==jmin.x)
{
Angulars_out.push_back(LimitAngular(rb0,rb1, qxdir(jf1), 2 * (-s.x+sin(jmin.x/2.0f)) /physics_deltaT));
}

differs from

if(jmax.y==jmin.y)
{
Angulars_out.push_back(LimitAngular(rb0,rb1,qydir(jf1),physics_biasfactorjoint * 2 * (-s.y+jmin.y) /physics_deltaT)); // btw '2' is because of quat angle is t/2
}

I believe I've found a bug in your physics or collision code. It's possible you're already aware of this, since after checking out older versions of the code, it seems to be present in all of them. The result of this bug is objects clipping through the geometry entirely.

An easily reproducible test case can be found by modifying your testphys/testphys.cpp code to only have a single cube that starts at {0.0f, 0.0f, 5.5f} (Here's a gist that has those changes available). When you run the program, it the cube will pass entirely through the world geometry as it falls.

I did a bit of sleuthing in a debugger to try and figure out the issue on my own. I did not have a ton of luck, but some. What I've found is that this seems to come from src.v in calcpoints ending up as a zero vector. Normalizing a zero vector ends poorly, and the rest of the code can't cope (and the simple solution of checking before normalizing and substituting a unit vector does not solve the problem). The zero comes from PlaneProjectOf returning zero on line 128 of gjk.h, but while I believe I understand that code, I don't understand it well enough to know how that should be handled (my guess is that that code is fine, and the caller should be checking for the zero vector).

A few things I've found do solve (well, avoid) the problem that might help track it down:

• Changing the starting position so that the x and y positions are not 0, 0. For example, going from {0.0f, 0.0f, 5.5f} to {0.0f, 0.1f, 5.5f} avoids it.
• Certain starting z positions don't trigger it. E.g. 1.9 won't, even though 1.85 and 1.95 will. Nothing below 0.7 seems to trigger it (until the cube begins to start inside the world geometry, at which point it always happens).
• Changing the orientation so that the collision does not occur as face * face avoids it.

Probably worth mentioning that I'm on a mac and using clang, and am using a modified version of glwin.h (you can see it here) that uses SDL to allow running from a mac. I don't believe this to be related in any way, since it happens at all optimization levels and otherwise works perfectly, but I obviously could be wrong.

P.S. This is a great project. Very straightforward code, not bloated or overengineered. Extremely pleasant to read through and learn from. Thanks for sharing it.

Hi, I am attempting to integrate the bunny LOD code into my program, but all it does is delete some triangles from the mesh. If I set the render number to the number of vertices (no reduction), the resulting mesh looks identical to the original.

I don't see anything wrong in my code, compared to the example. Do you see any obvious mistakes? Thanks.

int Map(const std::vector<int>& collapse_map, int a, int mx) {
	if (mx <= 0) return 0;
	while (a >= mx) {
		a = collapse_map[a];
	}
	return a;
}

//-----------------------------
// Get mesh data
//-----------------------------

std::vector<linalg::aliases::float3> vert;
std::vector<tridata> tri;
std::vector<int> map;
std::vector<int> permutation;
tridata t;

for (const auto& v : mesh->vertices)
{
	vert.push_back(linalg::aliases::float3(v.position.x, v.position.y, v.position.z));
}

for (int n = 0; n < mesh->CountPrimitives(); ++n)
{
	t.v[0] = mesh->GetPrimitiveVertex(n, 0);
	t.v[1] = mesh->GetPrimitiveVertex(n, 1);
	t.v[2] = mesh->GetPrimitiveVertex(n, 2);
	tri.push_back(t);
}

//-----------------------------
// Reduce the mesh
//-----------------------------

ProgressiveMesh(vert, tri, map, permutation);
				
//-----------------------------
// PermuteVertices
//-----------------------------
				
// rearrange the vertex Array 
std::vector<float3> temp_Array;
unsigned int i;
assert(permutation.size() == vert.size());
for (i = 0; i < vert.size(); i++) {
	temp_Array.push_back(vert[i]);
}
for (i = 0; i < vert.size(); i++) {
	vert[permutation[i]] = temp_Array[i];
}
// update the changes in the entries in the triangle Array
for (i = 0; i < tri.size(); i++) {
	for (int j = 0; j < 3; j++) {
		tri[i].v[j] = permutation[tri[i].v[j]];
	}
}

//-----------------------------
// Build new mesh
//-----------------------------

Assert(map.size());
model->Clear();
mesh = model->AddMesh();

// Add all vertices - this can be improved later
for (int i = 0; i < vert.size(); ++i)
{
	mesh->AddVertex(vert[i].x, vert[i].y, vert[i].z);
}

//Add triangles
int render_num = vert.size() * 0.5;
for (unsigned int i = 0; i < tri.size(); i++)
{
	int p0 = Map(map, tri[i].v[0], render_num);
	int p1 = Map(map, tri[i].v[1], render_num);
	int p2 = Map(map, tri[i].v[2], render_num);
	if (p0 == p1 or p1 == p2 or p2 == p0) continue;
	mesh->AddPrimitive(p0, p1, p2);
}