Search Home Members Contacts
About Us
Products
Downloads
Community
Support
Pages: [1]
  Print  
Author Topic: Having problems with tracking down some matrix problems  (Read 232 times)
StakFallT
Community Member
*
Posts: 191


« on: January 05, 2009, 03:16:44 PM »

Any chance I could get someone with Matrix math experience to look at this code:
http://utilitybase.com/paste/10750

Basically the code is a ShadowMapping project based on an example from Microsoft. I've been able to translate all of it to Delphi pretty close to 1:1. Some things had to have a couple more lines added, mostly just typecasting stuff. Stuff that required an extra line or two because a more direct typecasting wasn't possible. Like going from a TV_3DMatrix to a D3DMatrix required me to put it into a variable first then typecast that.

anyhow, I've been a couple of days trying to get this to work. It compiles, and depending on how I shuffle the order of things like TV.Clear I get various effects. Sometimes solid grey meshes, sometimes meshes with alphanumeric characters wrapped around the meshes, sometimes artifacting.

My thought is it HAS to be the matrix calculations because the shader (That is being used on the DX level) has various params that are taking in matrix values, one of these is a material param and another is a texture param (This would explain the "various orders of code" that produce artifacting). So my thought is, it seems to definitely be stemmed from that, but I can't track where the problem is. I can try to upload a project file but it uses various pieces from other projects and isn't all inside one project folder so I'd have to first condense it down which I don't mind doing if someone is willing to look at the code? Oh, I almost forgot, for you C++ guys out there, treat Delphi's
<object>.<method> as
<object>-><method> Tongue 

Thanks in advance!
« Last Edit: January 05, 2009, 03:18:50 PM by StakFallT » Logged
jviper
Community Member
*
Posts: 2058

Discipline in training


« Reply #1 on: January 05, 2009, 05:05:46 PM »

The fact that you get some weird alpha-numeric characters wrapped around the objects could mean that your using bad textures. Try verifying your textures are correct, and not -1 or 0.
Logged

JAbstract.....Don't just imagine, make it happen!
StakFallT
Community Member
*
Posts: 191


« Reply #2 on: January 05, 2009, 05:12:56 PM »

Well that only occurs if I shift the code around (Rem stuff "here" to unrem stuff "there"). I think the Internal D3D Texture that TV is using, is being accurately exposed. Here's the code that I'm using to grab that texture:
Code:
                TextureIndex := Form1.Mesh[obj].GetTexture(i);
                if TextureIndex > 0 then
                    begin
                    D3DTexture := iDirect3DTexture9(Form1.TVInternals.GetTexture(TextureIndex));
                    g_pEffect.SetTexture('g_txScene', D3DTexture);
                end
                else
                    g_pEffect.SetTexture('g_txScene', g_pTexDef);
The alphanumber problem I don't think is the main issue, as it occurs if I jumble the code around a bit (And for all I know jumbling the code around to that extent could be the incorrect order things need to be done in. So I think the alphanumeric thing can be disregarded for the time being). I think the bigger issue is the matrix values being passed to the shader params


EDIT: Well I solved a VERY large part of it, I was using custom made procedures to convert from a TV_3DMatrix to a D3DMatrix and the problem was instead of using the parameter (containing the passed Matrix values) on the procedure's prototype, I was using a locally declared variable that really didn't equal anything, and so I was getting matrix values raised to the -38 and -39 power! Now my textures are showing up properly, just one last thing, it's more of a glitch than anything. My camera is now rolling'ing when it should be Pitching'ing. See http://www.nasm.si.edu/exhibitions/gal109/NEWHTF/HTF541B.HTM for the definitions I used. I'm guessing something in the matrix calculations but again not sure. I think it would be significantly easier though as now I think it's more of a logic issue and less of a matter of finding some awry abstract rudimentary value.



EDIT 2:
Well it appears my code decieved me slightly. The parameter thing was in fact a big problem, and without fixing that nothing would've likely worked. But after fixing that I put all the code into yet another sandbox project to clean it up (Sort of like a final cleanup phase) that's when I noticed something disappointing. It appears everything started working (Excluding the parameter thing) because I had a mesh.render in the shader loop. So before I go any further, lemme pose this question.
Is this snippet of code ok to be doing?:
Code:
for obj := 1 to MaxMeshes do
        begin
        If MainRenderWindow.MeshObjIndexesUsed[obj] = 1 Then
            begin
            MeshAddr := MainRenderWindow.TVInternals.GetD3DMesh(MainRenderWindow.Mesh[obj].GetIndex);
            D3DMesh := ID3DXMesh(MeshAddr);

            //mWorldView := TVMatrixToD3DMatrix(MainRenderWindow.Mesh[obj].GetMatrix);
            TmpTVMatrix := MainRenderWindow.Mesh[Obj].GetMatrix();
            mWorldView := PD3DXMatrixA16(@TmpTVMatrix)^;

            //This MatrixMultiply line causes artifacts for some reason
            D3DXMatrixMultiply(mWorldView, mWorldView, pmViewTemp);

            g_pEffect.SetMatrix('g_mWorldView', mWorldView);

            g_pEffect._Begin(@cPass, 0);
            for p := 0 to cPass - 1 do
                begin
                g_pEffect.BeginPass(p);
                for i := 0 to MainRenderWindow.Mesh[obj].GetGroupCount() - 1 do
                    begin
                    //Basically we're just getting the material for
                    //each group of the mesh and the diffuse colors
                    //for that material then sending that info to
                    //the effect object.
                    MaterialIndex := MainRenderWindow.Mesh[obj].GetMaterial(i);
                    //vDif stands for vector Diffuse
                    vDifTmp.x := MainRenderWindow.TVMaterial.GetDiffuse(MaterialIndex).r;
                    vDifTmp.y := MainRenderWindow.TVMaterial.GetDiffuse(MaterialIndex).g;
                    vDifTmp.z := MainRenderWindow.TVMaterial.GetDiffuse(MaterialIndex).b;
                    vDifTmp.w := MainRenderWindow.TVMaterial.GetDiffuse(MaterialIndex).a;
                    g_pEffect.SetVector('g_vMaterial', vDifTmp);

                    Application.ProcessMessages();

                    //Now we do the same for the textures
                    TextureIndex := MainRenderWindow.Mesh[obj].GetTexture(i);
                    if TextureIndex > 0 then
                        begin
                        D3DTexture := iDirect3DTexture9(MainRenderWindow.TVInternals.GetTexture(TextureIndex));
                        g_pEffect.SetTexture('g_txScene', D3DTexture);
                    end
                    else
                        g_pEffect.SetTexture('g_txScene', g_pTexDef);

                    g_pEffect.CommitChanges();
                    Form1.TVInternals.UpdateD3DMesh(MeshIndex);
                    D3DMesh.DrawSubset(i);
                end;
                g_pEffect.EndPass;
            end; //for p := 0 to cPass - 1 do
            g_pEffect._End;
        end;
    end;

More specifically, the line (Almost all the way at the bottom) that states:
Form1.TVInternals.UpdateD3DMesh(MeshIndex);

Here's why I'm asking, the ID3DXMesh does not provide a render method. I'm not even sure BaseMesh does either (Probably not if BaseMesh is the parent of Mesh and Mesh doesn't have one). The reason I'm using ID3DXMesh is because I need to get access to Passes and Subsets (Which I'm guessing is a mesh'es group by TV Terminology and Popular Rendering Util Terminology). I'm kind of forced into using ID3DXMesh because inside of the group loop (Which is inside the pass loop) the textures and materials are applied to mesh's subsets; Normally not a big deal except the shader uses values passed to it inside of these loops which also means the g_pEffect object is heavily dependant on this design as well, and before I go reinventing the wheel I need to get a handle on this first.

So what I'm looking to do, is grab a pointer to the internal DX mesh loaded and created by TV, set some stuff on it, update it via UpdateD3DMesh, and then render it via Mesh.Render. I mean is that perfectly legit? Right now it seems to just make my mesh totally black.


EDIT 3: It turns out they weren't totally black just very very dark and without differentiating brightness meaning either no shadows or completely shadowed. A problem to figure out after I figure out why anything beyond my first mesh loaded results in those meshes not having it's gimbal locked when the camera is rotated.
« Last Edit: January 05, 2009, 11:21:01 PM by StakFallT » Logged
Pages: [1]
  Print  
 
Jump to:  

Powered by SMF 1.1.3 | SMF © 2006-2007, Simple Machines LLC
Seo4Smf v0.2 © Webmaster's Talks