Page 2 of 6 FirstFirst 1234 ... LastLast
Results 11 to 20 of 55

Thread: 3d Engine Collision

  1. #11

    Re: 3d Engine Collision

    Yes exporting your model requeres some more effort then. Also it allows you to make parts dynamic that way (e.g. think of elevators) Also it pays back when checking collisions especially on larger worlds.

    PS your cell.x is a real challenge for my glmodel .x loader.
    http://3das.noeska.com - create adventure games without programming

  2. #12

    Re: 3d Engine Collision

    i have been looking into the dx function 'D3DXLoadMeshHierarchyFromX' i'm wondering if it is possible to load a hierarchy of frames, atm i have a floor frame, and i could create all walls as frames etc, keeping everything in 1 x file as 1 model, and then creating a bounding box around the frames.


    btw what is your glmodel x loader? lol

    ;MM;

  3. #13

    Re: 3d Engine Collision

    Quote Originally Posted by Memphis
    btw what is your glmodel x loader? lol
    http://www.noeska.com/dogl/glModel.aspx

    http://3das.noeska.com - create adventure games without programming

  4. #14

    Re: 3d Engine Collision

    interesting project you have there

    ok so.. i have done some looking around and only thing i think will be best is polygon collision, i can optimise meshes at a later stage. so by each stModel struct having a linked list of polygon/vertices and then any moving object can have their vertices checked to see if they intersect the stModels vertices. i can do this for specific types of models loaded (in this case the room/building only), and then do bounding box collision checks for other objects added into the room.

    does anyone have an example of how to get a list of all the vertices per polygon from a mesh? sorry for trouble. thanks in advance for any more help.

    ;MM;

  5. #15

    Re: 3d Engine Collision

    Now that is not easily explained.

    Basicly a mesh consists of a list of vertices and a list of indices.

    If a polygon/face consists of 3 vertices for the first face you would need to look up the vertices for indice[0], indice[1] and indice[2]. So if indice[0] returns 10 you need to read out vertice[10]. etc.
    You should be able to read this info from ID3DXMesh .

    I cannot tell how to do this specific for ID3DXMesh as i do not use D3D.
    http://3das.noeska.com - create adventure games without programming

  6. #16

    Re: 3d Engine Collision

    I have used ID3DXMesh and it works like you described.

    Lock the vertexbuffer to retrieve a pointer to video-memory. This pointer points to an array of vertex structs/records. Lock the indexbuffer and read the indices in groups of three (each group is a triangle/face).. each of the indices refers to a vertex in the vertexbuffer. That's how it's done.
    Coders rule nr 1: Face ur bugz.. dont cage them with code, kill'em with ur cursor.

  7. #17

    Re: 3d Engine Collision

    hi yes i am trying, however i dont seem to be able to get it to work

    [code="delphi"]
    pVertices, pIndices: Pointer;

    SetLength(tModel.lstTri, pNewMesh.GetNumFaces);

    pNewMesh.LockVertexBuffer(D3DLOCK_READONLY, pVertices);
    pNewMesh.LockIndexBuffer(D3DLOCK_READONLY, pIndices);

    for i := 0 to pNewMesh.GetNumFaces do begin
    tModel.lstTri[i].X := // ... lost here..
    tModel.lstTri[i].Y :=
    tModel.lstTri[i].Z :=
    end;
    [/code]

    i am having trouble using these both. do you have any examples of this routine? thanks.

  8. #18

    Re: 3d Engine Collision

    [pascal]
    type
    PVec3 = ^TVec3;
    TVec3 = record x, y, z: Single; end;
    TFace = array[0..2] of DWord;
    TMeshPositions = array of TVec3;
    TMeshFaces = array of TFace;
    PIndex2 = ^TIndex2;
    TIndex2 = array[0..0] of Word;
    PIndex4 = ^TIndex4;
    TIndex4 = array[0..0] of DWord;
    ...
    var
    Positions: TMeshPositions;
    Faces: TMeshFaces;
    Mesh: ID3DXMesh;
    Vertices: Pointer;
    VertexStride: Word;
    Indices2: PIndex2;
    Indices4: PIndex4;
    MeshOptions: DWord;
    i: Integer;
    ...
    MeshOptions := Mesh.GetOptions;
    SetLength(Positions, Mesh.GetNumVertices);
    SetLength(Faces, Mesh.GetNumFaces);
    VertexStride := Mesh.GetNumBytesPerVertex;
    Mesh.LockVertexBuffer(D3DLOCK_READONLY, Vertices);
    for i := 0 to High(Positions) do
    Positions[i] := PVec3(
    Pointer(Cardinal(Vertices) + i * VertexStride)
    )^;
    //Unless you use a custom vertex declaration in your mesh
    //it is safe to assume that the first 12 bytes are vertex positions.
    Mesh.UnlockVertexBuffer;
    //Depending on the size of indices (16 or 32 bit) use an
    //appropriate typed pointer (Indices2 or Indices4).
    if MeshOptions and D3DXMESH_32BIT = D3DXMESH_32BIT then
    begin
    Mesh.LockIndexBuffer(D3DLOCK_READONLY, Pointer(Indices4));
    for i := 0 to High(Faces) do
    begin
    Faces[i][0] := Indices4^[i * 3];
    Faces[i][1] := Indices4^[i * 3 + 1];
    Faces[i][2] := Indices4^[i * 3 + 2];
    end;
    end
    else
    begin
    Mesh.LockIndexBuffer(D3DLOCK_READONLY, Pointer(Indices2));
    for i := 0 to High(Faces) do
    begin
    Faces[i][0] := Indices2^[i * 3];
    Faces[i][1] := Indices2^[i * 3 + 1];
    Faces[i][2] := Indices2^[i * 3 + 2];
    end;
    end;
    Mesh.UnlockIndexBuffer;
    [/pascal]
    After that you can easily find your triangles like this:
    Positions[Faces[0][0]]; Positions[Faces[0][1]]; Positions[Faces[0][2]]; //for the first triangle
    Positions[Faces[n][0]]; Positions[Faces[n][1]]; Positions[Faces[n][2]]; //for n'th triangle

    There may be some minor errors in the code since I just typed it in the forum and haven't checked it myself.

  9. #19

    Re: 3d Engine Collision

    great thanks Dan, i will check this out ASAP. and post back.

  10. #20

    Re: 3d Engine Collision

    Nice topic, there are lot stuf to talk about 3d collision.

    You currently have a .X file for draw your world, in this case the only info you have available to test collision is the same you have for render your word which is called "a triangle soup".

    Doing some kind collision with triangles soups can be done, not any kind collision but some, for FPS type games for example is good enough where the collision your are doing is testing if you can go forward or not, backward or not, upward or not, downward or not etc, but identifing some kind geometry in your world for doing for example climbing is hard.

    With triangle soup basically what you do is to use the normal (the vector that tell where the triangle is pointing to) for identify which triangles can be considered as wall, floor, ceiling or even slants, for example you can know that any triangle with normal (0,1,0) is a standable floor cos it is pointing stray UP, and any triangle with normal (0,-1,0) is a ceiling cos it is pointing stray down, for any triangle where the "Y" component is 0 you can say it is a stray wall.

    Along with the normal there is also some usefull data like the "plane EQ" witch is used with the normal and one vertex triangle coordinates to calc is any position is in fornt or behind that triangle; there is also the distance formula which calc the distance between the triangle and any desired position.

    Now, if your .x file has lets say 2,000 triangles then testing collision every frame is is very slower, so it is best that your soup triangle have to be pre-processed some how to allow to reject triangles as much as posible before doing test with the triangles that are really near to the player position.

    A popular pre-procces is the so called BSP trees, which sort the triangle soup in a very complicated binary tree using the normal and the plane EQ of every triangle, that will allow to check very fast for any position you want which triangles are closer in front, back, up and down.

    The problem i found with BSP trees is that this algorith is hard to understand and implement when one is a newbie.

    More easier algorithms are for example the quadtrees and octreess which sort the triangle soup in recursive sectors so using the distance formula and calculating in which sector the player currently is you can test only the traingle that belong to that sector.


    Where there are more techniques where is not involved a triangle soup, but most the time that will mean you have to do the word geometry for rendering (triangle soup) and the collison data separated but that is stuff for another post,





Page 2 of 6 FirstFirst 1234 ... LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •