• <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)  編輯 收藏 引用
            久久这里只有精品视频99| AAA级久久久精品无码区| 亚洲精品乱码久久久久久中文字幕 | 超级碰久久免费公开视频| 国产精品欧美久久久久无广告 | 久久这里只精品99re66| 亚洲国产另类久久久精品| 99久久www免费人成精品| 国产色综合久久无码有码| 国产精品九九久久精品女同亚洲欧美日韩综合区 | 亚洲人成无码网站久久99热国产 | 久久久久亚洲精品无码网址| 久久久亚洲欧洲日产国码是AV| 久久综合久久综合久久综合| 久久受www免费人成_看片中文| 91麻豆精品国产91久久久久久| 久久99久国产麻精品66| 伊人久久无码精品中文字幕| 狠狠人妻久久久久久综合| 国内精品久久久久| 久久精品中文闷骚内射| 99久久国产精品免费一区二区| 伊人情人综合成人久久网小说| 狠狠色丁香婷婷综合久久来来去| 粉嫩小泬无遮挡久久久久久| 久久精品卫校国产小美女| 一本色综合久久| 久久人人爽人人爽人人片AV不| 亚洲Av无码国产情品久久| 天堂无码久久综合东京热| 久久精品无码一区二区app| 精品国产综合区久久久久久| 久久不射电影网| 99热成人精品免费久久| 久久久久综合国产欧美一区二区| 老司机国内精品久久久久| 99久久国产综合精品五月天喷水| 94久久国产乱子伦精品免费| 久久九色综合九色99伊人| 综合久久给合久久狠狠狠97色| 香港aa三级久久三级老师2021国产三级精品三级在 |