• <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)  編輯 收藏 引用
            一本久久a久久精品综合夜夜| 99国产精品久久| 久久婷婷五月综合色奶水99啪| 无夜精品久久久久久| 久久久精品人妻一区二区三区蜜桃| 久久91精品国产91久久小草| 国产福利电影一区二区三区久久久久成人精品综合 | 一本色道久久88加勒比—综合| 91超碰碰碰碰久久久久久综合| 亚洲国产成人久久综合区| 久久天天躁狠狠躁夜夜avapp | 情人伊人久久综合亚洲| 久久久久亚洲精品天堂久久久久久| 久久大香萑太香蕉av| 狠狠色婷婷综合天天久久丁香| 久久涩综合| 精品久久久久久中文字幕| 欧洲性大片xxxxx久久久| 亚洲精品无码久久一线| 99久久精品国产一区二区三区| 久久免费看黄a级毛片| 精品熟女少妇aⅴ免费久久| 麻豆成人久久精品二区三区免费| 国产激情久久久久影院老熟女| 人妻无码αv中文字幕久久琪琪布 人妻无码久久一区二区三区免费 人妻无码中文久久久久专区 | 久久久久久精品免费免费自慰| 四虎国产永久免费久久| 久久亚洲私人国产精品| 久久天天躁夜夜躁狠狠| 亚洲午夜无码久久久久小说| 婷婷综合久久中文字幕| 久久精品国产亚洲精品2020| 狠狠色综合网站久久久久久久高清| 久久久免费观成人影院| 亚洲狠狠久久综合一区77777| 国产精品无码久久综合| 久久久久久亚洲精品成人| 久久亚洲精精品中文字幕| 亚洲综合精品香蕉久久网| 国内精品综合久久久40p| 亚洲av成人无码久久精品|