• <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 閱讀(513) 評(píng)論(0)  編輯 收藏 引用

            只有注冊(cè)用戶登錄后才能發(fā)表評(píng)論。
            網(wǎng)站導(dǎo)航: 博客園   IT新聞   BlogJava   博問   Chat2DB   管理


            亚洲欧美一级久久精品| 精品国产福利久久久| 香港aa三级久久三级老师2021国产三级精品三级在 | 国产精品久久亚洲不卡动漫| 久久夜色精品国产噜噜麻豆| 热re99久久精品国产99热| 久久精品无码一区二区日韩AV| 精品久久久久成人码免费动漫| 无码日韩人妻精品久久蜜桃 | 四虎亚洲国产成人久久精品| 久久国产色av免费看| 精品无码久久久久久尤物| 久久99精品久久久久久不卡| 久久久久久久久波多野高潮| 国产AV影片久久久久久| 久久久久亚洲AV成人片| 中文字幕久久精品| 久久久久久极精品久久久 | 亚洲va中文字幕无码久久不卡| 久久精品人人做人人爽电影蜜月| 久久久久亚洲?V成人无码| 久久综合亚洲色HEZYO社区 | 精品无码久久久久久国产| 久久久国产乱子伦精品作者| 久久夜色精品国产噜噜亚洲a| 国产精品成人精品久久久| 精品综合久久久久久888蜜芽| 久久亚洲国产最新网站| 亚洲国产精品成人AV无码久久综合影院 | 久久综合久久综合九色| 久久久久亚洲精品无码蜜桃 | 久久精品国产99久久久古代| 青青热久久国产久精品| 久久久WWW成人免费精品| 久久久精品无码专区不卡| 久久精品一区二区影院| 久久久91人妻无码精品蜜桃HD| 久久高清一级毛片| 久久国产成人午夜aⅴ影院 | 热久久这里只有精品| 九九久久精品无码专区|