Jump to content

  • Log In with Google      Sign In   
  • Create Account

sjaakiejj

Member Since 11 Apr 2007
Offline Last Active Apr 14 2012 07:54 PM

Posts I've Made

In Topic: [ODE] Access Violation at dCollide when using TriMeshes

03 April 2012 - 08:56 AM


dGeomTriMeshDataBuildSingle(dataID, vertices, sizeof(float)*3, vCount, indices, 6, sizeof(dTriIndex)*3);

From the doc over here:

Applies to all the dGeomTriMeshDataBuild single and double versions. (From http://ode.org/ode-l...html#sec_10_7_6) Used for filling a dTriMeshData object with data. No data is copied here, so the pointers passed into this function must remain valid.

So, you fill your data with temporary data which will be gone once you leave the createTriMeshBB method. Here's a fast hack, please do this not at home:
static float vertices[vCount * 3] = {
			0,0,0,
			20*30,0,0,
			20*30,0,20*30,
			0,0,20*30
	};
static	dTriIndex indices[6] = {
			0,1,2,
			0,2,3
	};

When this work, try to use some proper memory management to handle your mesh data.


How could I have missed that line? Besides, it's pretty logical... Thanks a lot, I'll go try it immediately Posted Image

Edit: It works, I had an additional issue afterwards which was that my object was just falling through the plane, but turned out the plane was upside down.

In Topic: A* considering edges?

01 April 2012 - 03:23 PM

You'd have to define the relationship between your grid nodes differently. A grid, to A*, is just a graph, and any node that is connected to another node is automatically possible to navigate. You'd either have to remove those connections (for instance, at the point on which you get the adjacency nodes, check if there's a wall obstructing the path from the current node to the one we're looking at), or change your approach from a grid to something like waypoints or a navigation mesh.

I think the Sims uses NavMeshes, but I'm not a 100% sure.

In Topic: Object Movement

07 March 2012 - 07:41 PM


Have you tried swapping the order of Rotated and Translated? I think that should do the trick

so instead of

  glTranslated(mx,my,mz);
glRotatef(direction,0,1,0);

you do
glRotatef(direction,0,1,0);
  glTranslated(mx,my,mz);


That does not appear to do anything different as far as I can tell.


You should definitely see something different, though its possible I pointed to the wrong pair, as I'm not quite sure which part represents your ship. Swapping the order means rotate first, then translate. Rotation should always be done at the origin, otherwise you get the exact effect you described, where the object rotates around the origin instead of its own axis.

In Topic: Object Movement

07 March 2012 - 07:13 PM

Have you tried swapping the order of Rotated and Translated? I think that should do the trick

so instead of
  glTranslated(mx,my,mz);
 glRotatef(direction,0,1,0);

you do
 glRotatef(direction,0,1,0);
  glTranslated(mx,my,mz);

In Topic: Bounding Box Calculations

07 March 2012 - 03:18 PM

I had considered this, but if I were to generate the bbox, and then apply the transformation/rotation/scale to it manually, a rotated model, would result in a rotated bbox. I was under the impression that this was bad practice. Unless I am mistaken.

Alternatively, I could use the apply the matrix to the points in the model, and then calculate a bounding box, but since applying rotation requires trig, and it would be run on every single vertex on every model, each frame, I imagined it would absorb ridiculous resources. Again though, I could be mistaken here as well.

Depends on how you build it. Either use AABBs like haegarr mentioned, or if you want rotated bounding boxes (probably mostly used in hitboxes) I would simply have a class that contains the model and its orientation, location and scale, and use that to set the state of both the GL objects and the Bounding box. That way you have logically seperated the two very different types of functionality, and you ensure that you're always running your calculations in the correct space.

A bounding sphere may be an option for you here. It will certainly be easier to calculate - just position it's center at the object's position and calculate the radius from the object size and largest scale factor, done - no need to bother with rotations. They're also faster to test against the frustum, but the tradeoff is that a sphere may not be an optimal shape for all objects.

A sensible approach, and it'll help simplify collision detection as checking for intersection with a sphere is trivial.

PARTNERS