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

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


            久久精品成人免费网站| 亚洲精品无码专区久久久 | 久久永久免费人妻精品下载| 久久久精品国产免大香伊| 久久婷婷五月综合97色一本一本 | 久久精品无码一区二区WWW| 久久久久无码精品国产不卡| 99久久免费只有精品国产| 亚洲日本久久久午夜精品| 国产精品久久久天天影视| 精品视频久久久久| 国产麻豆精品久久一二三| 色婷婷久久久SWAG精品| 国产精品对白刺激久久久| 久久久久国色AV免费观看| 久久国产精品99国产精| 日韩欧美亚洲综合久久影院Ds | 模特私拍国产精品久久| 国产精品久久久久天天影视| 国产精品久久久久久久久软件| 色综合色天天久久婷婷基地| 精品国产乱码久久久久软件| 国产女人aaa级久久久级| 99久久国语露脸精品国产| 久久精品日日躁夜夜躁欧美| 亚洲欧美久久久久9999| 久久久国产精品| 国产精品99久久不卡| 久久最近最新中文字幕大全| 日日噜噜夜夜狠狠久久丁香五月 | 久久久久亚洲AV综合波多野结衣 | 亚洲精品WWW久久久久久| 亚洲嫩草影院久久精品| 9久久9久久精品| 久久精品国产99国产精偷| 国产精品久久免费| 亚洲国产精品婷婷久久| 四虎国产精品免费久久5151| 精品久久综合1区2区3区激情 | 中文精品99久久国产 | 国产精品久久久久天天影视|