• <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>
            還沒想好
            還沒想好
            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 閱讀(518) 評論(0)  編輯 收藏 引用
            久久婷婷是五月综合色狠狠| 久久香蕉国产线看观看精品yw| 99久久国产热无码精品免费| 久久99精品国产99久久6男男| 国产69精品久久久久777| 久久精品国产亚洲沈樵| 精品久久久久久久久久中文字幕| 久久毛片免费看一区二区三区| 2021最新久久久视精品爱| 国产午夜福利精品久久2021 | 久久精品国产99国产精品澳门| 久久99国产精品久久99果冻传媒 | 久久久一本精品99久久精品88| 日产精品久久久久久久性色| 国产综合精品久久亚洲| 无遮挡粉嫩小泬久久久久久久| 久久AAAA片一区二区| 精品少妇人妻av无码久久| 亚洲国产婷婷香蕉久久久久久| 久久国产精品国产自线拍免费| 久久人人添人人爽添人人片牛牛| 久久99精品久久久久久秒播| 精品乱码久久久久久久| 日本WV一本一道久久香蕉| 精品人妻伦一二三区久久| 69SEX久久精品国产麻豆| 性欧美大战久久久久久久久| 色综合久久88色综合天天 | 国产99久久久久久免费看| 国产91色综合久久免费| 久久久久久午夜成人影院 | 四虎国产精品成人免费久久| 爱做久久久久久| 66精品综合久久久久久久| 99久久精品国产麻豆| 久久国产精品无码HDAV| 无码人妻精品一区二区三区久久| 久久精品国产男包| 精品熟女少妇AV免费久久| 亚洲级αV无码毛片久久精品| 伊人久久无码中文字幕|