• <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 閱讀(516) 評論(0)  編輯 收藏 引用
            亚洲欧美久久久久9999| 久久久久波多野结衣高潮| 久久亚洲国产成人精品无码区| 99久久国产主播综合精品| 91精品国产综合久久四虎久久无码一级 | 国产欧美久久久精品| 久久久久亚洲AV无码专区网站| 久久这里有精品视频| 久久精品国产免费观看| 精品综合久久久久久888蜜芽| 久久精品国产亚洲av瑜伽| 无码伊人66久久大杳蕉网站谷歌 | 久久午夜福利无码1000合集 | 精品久久久久久国产免费了| 国产亚洲欧美精品久久久| 精品久久久久久国产三级| 色婷婷综合久久久久中文一区二区| 久久久久久一区国产精品| 久久久久久久人妻无码中文字幕爆| 亚洲成av人片不卡无码久久| 日韩一区二区久久久久久| 久久婷婷五月综合色奶水99啪| 亚洲国产二区三区久久| 亚洲欧美伊人久久综合一区二区 | 亚洲国产精品无码久久青草| 青青草原1769久久免费播放| 久久久久亚洲AV无码观看| 看全色黄大色大片免费久久久| 99热热久久这里只有精品68| 久久精品国产69国产精品亚洲| 综合网日日天干夜夜久久| 亚洲午夜久久久久久噜噜噜| 久久久久亚洲av毛片大| 久久久久久国产精品美女| 99久久综合狠狠综合久久| 久久精品国内一区二区三区| 成人国内精品久久久久影院| 久久精品国产免费一区| 国产精品久久久久aaaa| 久久久久综合网久久| 9191精品国产免费久久|