由于我们家的RD说给他的美术素材全部都要是2的次方尺寸
想请问这样是正常的吗？
就是128x128 256x256 512x512 1024x1024这种的以此类推
觉得很奇怪，所以上来请益一下
就算不管什么东西，举凡角色立绘、头像、背景等东西
背景就是720*1280这种尺寸了，也要生给他2的次方尺寸
美术素材本来就会有尺寸大小不可能全是2次方的尺寸的情况
可是程式说不这样做的话他编译出来美术素材会变得超级大
什么NGUI的也不打算去买，说什么怕NGUI一更新就挂掉所以不打算靠外挂
全部靠着UNITY内建硬上，用texurepacker打包给他也不要
一个说什么放进去还要自己旋转对位很麻烦
一个说还要额外装东西的方法不是好方法
TP都打包给你们了应该顶多给对位图就好了吧= = ............
所以只好想请问有作游戏的同行一下，你们放背景还是角色立绘那种的
都是怎么做的呢？
真的也会这样子做吗？
谢谢
角色没有很大只，可是却都应要把角色的尺寸宽高边界都拉到2次方....

感觉没错啊，除非是属于Sprite packer，不然pot方便压缩

为了效能，npot无法最佳化

应该是为了方便压缩吧，内建pot长宽比会爆炸

我当初都跟美术讲说小一点 然后先放进手机看XD

uGUI不需要power of 2

立绘头像背景 建议是用绘图软件批次处理成power of 2有些东西不适合打包成atlas 又需要PVRTC压缩 又不想被和unity sprite奋战长宽比的时侯...你提的解法 NGUI->建议不要用 TexturePacker->不适合用在立绘和背景上用Unity importer直接rescale成pot -> sprite长宽比要手动重调在流程上最简单的方法→用绘图软件批次处理成pot

不买nGUI是没什么问题，没特殊需求的话uGUI很够用了但我记得Unity会自动把Sprite包成Atlas除非你的图本来就是做成图集的形式，否则不用特地遵守2power的格式 前提是你家工程师是在用uGUI如果是用onGUI的神人的话我就不知道了 XD

TexturePacker 完全可以切好直接变成单张单张的 Unity Sprite，是不想学吧XD而且拼图才有意义，你一张图喂进内存的确是分配2的次方的空间，例如128휱29的图，就是会占用128휲56推文被吃掉了，晚点再补，不过先说你们工程师的观念有问题，完全误解了内存配置的运作

会比较方便 但引擎都有内建功能才对 directx也没这问题蛮莫名奇妙的 有需要大量转的话写程式自己转

POT = Power Of Two

昨天忘了补了，总之举例 128*129 的图，在内存里就要配置 128*256 的空间，但明明就只多了 1px，却要多出将近一倍的无用空间

新开案子用UGUI比较好，NGUI会慢慢被淘汰

这对于内存配置来说是极大的浪费，但你硬要把图留空到 128*256，意义在哪？拼图的好处就是够跟内存要最小的空间，可以塞进最多的图所以像刚刚上面的例子，浪费的空间就可以靠着填补其他小图把他补起来举例，如果你今天有两张图，一张是 128*129，一张是65*65，如果不拼图，在内存里面就会耗掉128*256 +128*128但如果拼图，因为 65*65 可以塞到 128*129 被配置到的128*256内存空间剩下的空白处，所以把两张图拼成128*256的图给游戏使用，这样就只会占128*256的空间。2的倍数是这样运作，你留空却不作为完全没意义

我建议你们多磨合、抱着谦虚的心一起探讨问题点。最好两个人就坐隔壁，很快会了解unity是友情杀手简单事情变动能配合就配合，图改个大小对你来说很快但如果他不太熟悉，你不配合他改，可能花他更多时间修正反正资源过大软件跑不动，问题是他扛，他迟早要学更多。类似的事情还很多很多，例如法线方向，模型中心各种搞反之，如果某个变动你要花很多时间，换你要求他尽量配合

就算是DirectX也有这问题吧 记得天珑书店里面有一本原文书也是这样写 主要是放大缩小处理后细节可不可以完美呈现的问题吧...

power-of-two 主要是可压缩，放大缩小是看 mipmap

早期支援 NPOT 的硬件刚出来的时候，速度会比 POT 慢一些不知道这块是不是真的由硬件做还是 driver 自己处理掉