• <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)  編輯 收藏 引用
            97久久国产综合精品女不卡| 日本高清无卡码一区二区久久| 亚洲国产精品无码久久一区二区 | 精品国产福利久久久| 国产2021久久精品| 久久婷婷人人澡人人爽人人爱| 大伊人青草狠狠久久| 国产精品99久久久久久猫咪 | 久久无码人妻一区二区三区午夜| 97久久精品国产精品青草| 色婷婷久久综合中文久久一本| 日产精品99久久久久久| 青春久久| 色综合久久中文色婷婷| 狠狠色丁香久久婷婷综合五月| 无码国内精品久久综合88| 国产精品99久久精品爆乳| 99久久精品国产免看国产一区| 久久人人爽人人人人爽AV| 岛国搬运www久久| 久久国产一区二区| 久久AV高清无码| 久久久久久午夜成人影院| 久久综合久久美利坚合众国| 久久99精品久久久久久9蜜桃| 久久这里只精品国产99热| 色婷婷综合久久久中文字幕| 狠狠色婷婷久久综合频道日韩| 综合久久一区二区三区| 久久久国产视频| 久久婷婷五月综合成人D啪| 亚洲国产成人精品女人久久久 | 国产亚洲美女精品久久久久狼| 久久精品国产亚洲77777| 国产精品九九久久免费视频 | 亚洲精品美女久久久久99| 久久亚洲AV成人无码国产| 欧美日韩精品久久久免费观看| 亚洲午夜久久久久久久久电影网| 久久亚洲精精品中文字幕| 成人亚洲欧美久久久久 |