• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            還沒(méi)想好
            還沒(méi)想好
            posts - 4,comments - 6,trackbacks - 0
            http://www.gamedev.net/community/forums/topic.asp?topic_id=412504

            No... In true, PVWp is wrong because P,V and W (as Direct3D defines) were created to satisfy the [row vector]*[matrix] multiplying order. In other words, the content of a transformation matrix could be different depending on the multiplying rule.

            For example, consider a translation matrix:

            For a [row vector]*[matrix] multiplying order, it is described as:
            1 0 0 0
            0 1 0 0
            0 0 1 0
            x y z 1
            

            For a [matrix]*[column vector] multiplying order, it is described as:
            1 0 0 x
            0 1 0 y
            0 0 1 z
            0 0 0 1
            

             


            I don't know the math details you're attempting to work out... I'm really bad at formal math theory. I do however know the D3D details of what's going on. Perhaps if I explain what D3D is doing, it'll help you.

            Matrix in memory normally.
            11 12 13 14
            21 22 23 24
            31 32 33 34
            41 42 43 44

            Normally a vector * matrix such a D3DXMatrixTransform will do:
            outx = vec dot (11,21,31,41)
            outy = vec dot (12,22,32,42)
            outz = vec dot (13,23,33,43)
            outw = vec dot (14,24,34,44)

            When you give a matrix to a shader, it is transposed, which offers a small optimization for most matrices, which I'll explain in a bit. After it's transposed, it's stored in 4 constant registers (or 3... I'll get to that).

            c0 = 11,21,31,41
            c1 = 12,22,32,42
            c2 = 13,23,33,43
            c3 = 14,24,34,44

            Next, in the shader performing a "mul(vec,mat)" will do this:
            v0 = input register containing position
            r0 = temp register
            dp4 r0.x, v0, c0 // (r0.x = v0 dot c0)
            dp4 r0.y, v0, c1
            dp4 r0.z, v0, c2
            dp4 r0.w, v0, c3

            As you can see, this is the same as D3DXMatrixTransform. Why does D3D perform a hidden transpose? To save precious constant space. You can declare your matrix as float4x3 and the transformation becomes:
            dp4 r0.x, v0, c0
            dp4 r0.y, v0, c1
            dp4 r0.z, v0, c2
            mov r0.w, (some constant holding 1)

            Any time the matrix isn't a projection, ie: for world, worldview, view, and bones especially, you can drop a constant without affecting the results, as it's always a (0,0,0,1) vector. Back in shader 1.1 with only 96 constants, it was a big deal. If you had 20 bone matrices, that would be either 80 or 60 constants. Personally, I'd take the 60, leaving more room for lights, fog, texture transforms, etc. It also takes time to upload all those useless (0,0,0,1) vectors to the video card, which is another small savings.

            posted on 2010-07-20 11:25 MDnullWHO 閱讀(516) 評(píng)論(0)  編輯 收藏 引用

            只有注冊(cè)用戶登錄后才能發(fā)表評(píng)論。
            網(wǎng)站導(dǎo)航: 博客園   IT新聞   BlogJava   博問(wèn)   Chat2DB   管理


            香蕉久久av一区二区三区| 欧美亚洲国产精品久久| 国产精品久久久久久搜索| 久久久精品国产sm调教网站| 国产精品18久久久久久vr| 久久本道综合久久伊人| 77777亚洲午夜久久多喷| 久久综合九色综合精品| 欧美亚洲国产精品久久| 久久AⅤ人妻少妇嫩草影院| 一本一本久久a久久综合精品蜜桃| 国内精品久久国产大陆| 色播久久人人爽人人爽人人片AV| 国产精品久久99| 久久久久久久久久久| 色成年激情久久综合| 久久久久se色偷偷亚洲精品av| 91精品免费久久久久久久久| 无码人妻久久一区二区三区免费| 久久久久黑人强伦姧人妻| 国产精品一区二区久久不卡| 欧美精品国产综合久久| 色婷婷狠狠久久综合五月| 久久99中文字幕久久| 人妻精品久久无码专区精东影业 | 伊人久久无码中文字幕| 精品多毛少妇人妻AV免费久久| 精品国产乱码久久久久久郑州公司 | 久久精品国产2020| 国产精品99久久久精品无码 | 久久久久夜夜夜精品国产| 国产精品禁18久久久夂久| 人妻少妇久久中文字幕| 久久精品人成免费| 久久久久久国产精品免费无码 | 区久久AAA片69亚洲| 香蕉久久夜色精品国产尤物| 亚洲美日韩Av中文字幕无码久久久妻妇 | 一本大道久久a久久精品综合| 久久精品国产2020| 国产亚洲美女精品久久久|