• <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   管理


            久久久久久免费视频| 国产一区二区精品久久| 久久国产精品免费一区二区三区| 久久亚洲综合色一区二区三区| 日韩精品久久久久久| 国产99久久久国产精品小说| 久久精品无码午夜福利理论片 | 国产成人综合久久精品尤物| 久久久这里有精品中文字幕| 色综合久久中文字幕无码| 久久夜色精品国产亚洲| 久久精品国产亚洲AV香蕉| 久久香蕉国产线看观看99| 一本色道久久88—综合亚洲精品| 女人香蕉久久**毛片精品| 亚洲国产精品无码久久一区二区 | 久久久久亚洲精品天堂| 国内精品伊人久久久久网站| 久久精品人成免费| 伊人久久亚洲综合影院| 香港aa三级久久三级| 精品久久久久久成人AV| 久久精品国产日本波多野结衣| 久久国产香蕉视频| 久久精品成人影院| 国内精品久久久久久不卡影院| 72种姿势欧美久久久久大黄蕉| 波多野结衣久久精品| 久久人人爽人人爽AV片| 精品久久久久久久久久中文字幕| 99久久精品毛片免费播放| 久久99久久99精品免视看动漫| 大香伊人久久精品一区二区| 午夜精品久久久久9999高清| 久久久久久久综合日本| 久久精品国产精品亚洲人人| AAA级久久久精品无码区| 91亚洲国产成人久久精品网址| 国产精品久久久久久久久| 久久99精品国产一区二区三区 | 欧美精品福利视频一区二区三区久久久精品 |