|
4 registered members (M_D, AndrewAMD, Quad, Ayumi),
806
guests, and 5
spiders. |
|
Key:
Admin,
Global Mod,
Mod
|
|
|
Re: Newton 2 wrapper
[Re: jweb]
#272141
06/16/09 18:16
06/16/09 18:16
|
Joined: Jul 2007
Posts: 959
nl
flits
User
|
User
Joined: Jul 2007
Posts: 959
nl
|
i try to make a conveyer now if they come in contact with the conveyer the get some force added now my question is how to get both entity's pointers because the first one does work but not the second entity pointer this is my try
ENTITY* test_unit;
void UserContactRestitution22 (const NewtonJoint* contactJoint, dFloat timestep, int threadIndex)
{
dFloat Ixx;
dFloat Iyy;
dFloat Izz;
dFloat mass;
const NewtonBody* body;
const NewtonBody* body0;
const NewtonBody* body1;
GenericContactProcess (contactJoint, timestep, threadIndex);
body0 = NewtonJointGetBody0(contactJoint);
body1 = NewtonJointGetBody1(contactJoint);
body = body0;
NewtonBodyGetMassMatrix (body, &mass, &Ixx, &Iyy, &Izz);
if (mass == (float)0.0) {
body = body1;
}
void* contact;
for (contact = NewtonContactJointGetFirstContact (contactJoint); contact; contact = NewtonContactJointGetNextContact (contactJoint, contact)) {
NewtonMaterial* nmaterial;
nmaterial = NewtonContactGetMaterial (contact);
you = (ENTITY*)NewtonBodyGetUserData(body);
test_unit = (ENTITY*)NewtonBodyGetUserData(NewtonJointGetBody1(contactJoint));
//NewtonMaterialSetContactElasticity (nmaterial, (float)you.skill98);
if(test_unit != NULL)
{
if(you.skill10 == 1 && test_unit.skill10 == 2)// i have set both you en test_unit to the correct value
{
float pos[3], n[3];
NewtonMaterialGetContactPositionAndNormal(nmaterial, pos, n);
you.skill8 = 8; // add force on a other func else force get duplicated
VECTOR pos_vec;
VECTOR n_vec;
vec_set(pos_vec,_vec(pos[0],pos[1],pos[2]));
vec_scale(pos_vec,METERTOQUANT);
draw_point3d(pos_vec,vector(0,0,255),100,5);
}
}
}
}
thx flits
"empty"
|
|
|
Re: Newton 2 wrapper
[Re: VeT]
#272684
06/19/09 09:43
06/19/09 09:43
|
Joined: Apr 2009
Posts: 14
Poland, Germany
EnjoMitch
Newbie
|
Newbie
Joined: Apr 2009
Posts: 14
Poland, Germany
|
Congratulations on defending your diploma, and welcome to the club  I'm very grateful for your wrapper and I admire your dedication. I need only very small parts of the Newton's features and although your wrapper uses many advanced features, it unfortunately lacks the ability to add WED blocks collision tree (from my experience). I read your comment above newton_treecollisionaddentity(): (note: if you would like to add WED blocks as static collision geometry then you have to pass NULL to ent_getmesh and loop through all blocks! the transformation to world space isn't necessary then.) so I've done the following: WARNING! THE FOLLOWING CODE IS INCORRECT!1) I've changed the void newton_treecollisionaddentity(NewtonCollision* treecollision, ENTITY* entity) to void newton_treecollisionaddentity(NewtonCollision* treecollision, ENTITY* entity, var argnum) 2) Inside the newton_addstaticcollisiongeometry(), after building collision tree for models, I've addded this loop:
var num = 0;
while ( (ent_getmesh(NULL, num, 0) != NULL) )
{
newton_treecollisionaddentity(treecollision, NULL, num);
num ++;
}
3) I've modified newton_treecollisionaddentity() to the following:
void newton_treecollisionaddentity(NewtonCollision* treecollision, ENTITY* entity, var argnum)
{
var num = 0;
if(!entity)
{
num = argnum;
}
LPD3DXMESH pmesh = (LPD3DXMESH)ent_getmesh(entity, num, 0);
/* ... */
if (entity)
{
//transform
}
else
{
// don't transform?
// add triangles to collision tree
for(i = 0; i < numfaces; i++)
{
float v[9];
v[0] = pvertices[pindices[(i*3)+2]].x * QUANTTOMETER;
v[1] = pvertices[pindices[(i*3)+2]].y * QUANTTOMETER;
v[2] = pvertices[pindices[(i*3)+2]].z * QUANTTOMETER;
v[3] = pvertices[pindices[(i*3)+1]].x * QUANTTOMETER;
v[4] = pvertices[pindices[(i*3)+1]].y * QUANTTOMETER;
v[5] = pvertices[pindices[(i*3)+1]].z * QUANTTOMETER;
v[6] = pvertices[pindices[(i*3)+0]].x * QUANTTOMETER;
v[7] = pvertices[pindices[(i*3)+0]].y * QUANTTOMETER;
v[8] = pvertices[pindices[(i*3)+0]].z * QUANTTOMETER;
NewtonTreeCollisionAddFace(treecollision, 3, v,12, pattributes[i]);
}
}
/* ... */
}
Unfortunately it doesn't work, and the blocks are passable, as if a transformation was needed after all. The problem is that I need a transformation matrix (ent_getmatrix), but of course it only accepts ENTITY*. I could create my own transformation matrix, by setting pan, tilt and roll to 0, but what about x,y,z ? Can I get it somehow for the static blocks? Could I ask you (or anybody else) for some help with this?
Last edited by EnjoMitch; 06/19/09 09:52.
|
|
|
Re: Newton 2 wrapper
[Re: VeT]
#272895
06/20/09 12:07
06/20/09 12:07
|
Joined: Apr 2009
Posts: 14
Poland, Germany
EnjoMitch
Newbie
|
Newbie
Joined: Apr 2009
Posts: 14
Poland, Germany
|
Unfortunately the new Newton version crashes some times with the wrapper. OK, anyway, I've prepared a test case for v. 2.00: Testcase linkThe archive includes all sources and a release version Z pushes the ball My expectations are that the ball rolls normally on those adjacent models, without bouncing on their edges, and doesn't tunnel through the final model - lifted a bit to act as a wall. The latter is achievable by enabling continuous collision mode, but still is not 100% secure (and probably will never be exactly 100% as far as I understand physics engines, but let's say I'd like it "even more secure"). From what I've read on Newton forum, to increase the engine's precision, you have to call its Update function as often as possible. Some students reported that their collision problems were solved after calling the NewtonUpdate() 10 times of their graphics engine framerate. Supposing that this would solve my bouncing-on-egdes problem (I have to ask on Newton forum to make sure), here's the show stopper - in GS you can't wait for shorter time than one frame (graphical frame as far as I understand). From help, subject - wait(): "The shortest wait time is one frame cycle, the longest wait time is (...)" This means that we can't call your newton_update() function inside for example while(1) { wait(-0.001); } loop, because the time may be less than the frame cycle and won't work this way. My idea is to write a C++ plugin which would be passed the newtonWorld pointer, then it would spawn a thread (f.e. Boost::Thread). Inside the thread we could have this loop: double prevTime = 0; while (!quit) { double time = timer.GetTime() - prevTime; NewtonUpdate(newtonWorld, time); Sleep(10); // sleep for as shortest time as possible prevTime = timer.GetTime(); } I already have a working plugin using Boost::Thread, but I'm not doing the most important thing there - I'm not calling the NewtonUpdate() function, heh. What could also help could be using the double newton.dll instead of float. If the Newton's author confirms this, I could spend some time on reworking the wrapper to make it support doubles instead of floats. I think it should be a matter of some replacements in the wrapper's code and typedefing dFloat as double. What do you think? Also check this reply from Julio: http://www.newtondynamics.com/forum/viewtopic.php?f=9&t=4631&p=33329&hilit=edges#p33329I think that we should update the wrapper to make it support version 2.02 of Newton. Any ideas where to begin?
|
|
|
Re: Newton 2 wrapper
[Re: VeT]
#272904
06/20/09 12:44
06/20/09 12:44
|
Joined: Apr 2009
Posts: 14
Poland, Germany
EnjoMitch
Newbie
|
Newbie
Joined: Apr 2009
Posts: 14
Poland, Germany
|
but i still dont understand, where this problem comes: at my comp and notebook the original version of calling NewtonUpdate() once per frame works fine, but in your example ball moves really laggy Now that's something REALLY weird. Could you elaborate "laggy"? As in low frames per second? What's the FPS rate? (F11). If it's high then you say that the ball's movement is updated a lot slower than it should be for that FPS? In this test case I'm really doing nothing in particular. I'm calling NewtonUpdate() every frame normally, just as you do - I haven't touched this part in this test case. Could you check if in sources there's fps_max = 10; in main() ? A stupid question maybe - as if I didn't know what I'm uploading but I suspect that there may have been a network cache problem. The idea of calling Update more often is increasing the physics engine's precision - avoiding unwanted reactions such as tunnelling through walls. Once per frame is enough for slow speeds and games not demanding high precision, but for a simulation this may not be enough.
Last edited by EnjoMitch; 06/20/09 12:46.
|
|
|
|
so, i'm back after some days of drinking beer