D

有没有办法加快Sprite Packing的速度

现在游戏里的UI贴图比较多,每次只要UI贴图有很少的改变/新增,打ab包的时候就需要很长的时间,并且cache server貌似对Atlas无效。 我做了个实验,复制出7张不大的图片创建一个新图集,然后打ab包,需要时间大约360秒,其中350秒是在Sprite Packing。打包过程中仔细观察Editor.log的变化,发现打那张新的Atlas并没有花太长时间,检查所有Atlas是否需要重新打貌似才是主要花费时间的地方。 请问这个速度有没有办法加快,或者有没有什么代替的方案?

3 个月前 1 225

关于Crunch压缩图片的ab包应该如何打包的问题

https://unity3d.com/cn/learn/tutorials/topics/best-practices/assetbundle-usage-patterns?gq=Bundles%20which%20consist%20primarily%20of%20DXT-compressed%20textures%20which%20use%20the%20Crunch%20compression%20algorithm%20should%20be%20built%20uncompressed. unity官网的AssetBundle用法介绍里有一条 4.6.1. Crunch Compression Bundles which consist primarily of DXT-compressed textures which use the Crunch compression algorithm should be built uncompressed. 就是说因为使用Crunch压缩之后的图片,打成ab包再压缩大小也基本不会有变化,还会导致打包慢+使用时候需要解压,所以建议不要压缩。 但是我们打ab包的时候,并没有针对每个ab包选择压缩不压缩的选项,要么所有都压缩,要么所有都不压缩。 所以按照“使用Crunch压缩的图片打包时建议不要压缩的思路”的话,我想到2种做法: 1、所有ab包都不压缩,不知道这会不会导致Texture以外的资源的ab包变大很多,如果有用过的人希望介绍下经验。 2、先用LZ4打所有包,然后备份AssetBundleManifest文件,再用不压缩方式打Crunch压缩的图片包,打完把之前备份的AssetBundleManifest覆盖回来,感觉这种做法有点怪,还会导致图片的ab包要打2次,延长打包时间。 想问一下有没有更好的做法?还是说只要不压缩就可以了?

3 个月前 1 337

各项资源内存、mono内存、lua内存等基本都没变化的情况下,总内存分配一直在增加

遇到一个奇怪的问题,只要反复进出副本,总内存就一直在增加(1次10m左右),而这时候的各项资源内存、mono堆总内存、lua内存都基本没变化 第一次 <图片> 第一次详细 <图片> 第二次 <图片> 第二次详细 <图片> 就是说有某种被unity统计到的内存,但是又不在详细里。请问这部分可能是什么

4 个月前 0 355

关于Profiler里的Objects占用内存的疑问

搜了下之前的回答 https://answer.uwa4d.com/question/58ee14ed691df3f25d576cdd 这里说Objects在实际运行时没有,我做个了测试,发现个比较奇怪的现象 1、首先连上profiler看内存 <图片> Objects有100多m,Profiler这项有50m 记录下这时候用Profiler.GetTotalReservedMemory获取到的内存大小,大约是400m 2、断开usb线,重新启动游戏,看Profiler.GetTotalReservedMemory获取到的内存大小,大约是350m,少掉的并不是Objects的100多m,而是和Profiler的50m相当。 请问这个是为什么

4 个月前 0 123

场景打成assetbundle包,比场景直接打到apk里大了200MB

我们项目之前场景管理方式是把所有用到的场景用默认打包的方式打到apk里,这时候打出来的apk是400多m 现在我试了下把场景也用ab包的方式管理,结果打出来的apk一下变成600多m 把2个apk解压出来看,大小基本一样,主要是压成apk之后压缩率差了很多,400多m的包压缩比有66%,600m的包压缩比只有91%。 请问有没有什么办法让场景打成ab包的apk包小一点

7 个月前 0 239

ASTC格式的图片在低端机上的内存

在低端机上试了下某些图片用ASTC格式,发现一个奇怪的现象。 一张256x256的 normal map,不压缩的话也就是256k,但是在低端机上,这张图片大小实际变成了11m。为什么会这样?不支持的格式不是应该解压成RGBA32么。 补了张图 <图片>

1 年前 0 227

Resources.UnloadUnusedAssets时某些情况下卸载不掉ab包里资源的奇怪问题

在uwa的报告里发现某些ab包里的资源会同时存在2、3份,于是去查了下,发现一些奇怪的现象 版本:5.4.5p4 有一个自己写的加载ab包系统,卸载的时候用的Unload(false) 有2个ab包,a是UI Prefab,里面挂了一张图片,b是这个图片所在的图集的ab包 情况一: 1、用自己的ab包系统加载a(中间自动根据引用加载了b),并且实例化 2、destroy这个gameobject,卸载a的包(自动根据引用卸载了b) 3、调用Resources.UnloadUnusedAssets() 4、用Profiler看内存里的Texture2D 现象:b的图集在内存里 情况二: 情况二就比情况一多了一步GC.Collect() 1、用自己的ab包系统加载a(自动根据引用加载了b),并且实例化 2、destroy这个gameobject,卸载a的包(自动根据引用卸载了b) 3、调用GC.Collect() 4、调用Resources.UnloadUnusedAssets() 5、用Profiler看内存里的Texture2D 现象:b的图集不在内存里 情况三: 1、不用自己的ab包系统加载,在测试代码里写个最简单的加载 2、先加载b,再加载a,然后实例化a 3、destroy这个gameobject,unload b,unload a 4、调用Resources.UnloadUnusedAssets() 5、用Profiler看内存里的Texture2D 现象:b的图集不在内存里 从情况三来看,正常加载、卸载ab包后调用UnloadUnusedAssets是可以把资源卸载掉的 从情况二来看,GC.Collect后能够卸载掉资源,说明并没有代码引用了资源导致删不掉 由此可以基本确定情况一是自己写的ab包系统导致的,但是情况二又说明没有代码错误的引用了资源导致卸载不掉 问题: 一、导致情况一的原因可能是什么,既然情况二说明了没有代码错误的引用了资源导致卸载不掉,那么怎么才能出现必须调一次GC.Collect后再调UnloadUnusedAssets才能真正卸载掉资源的现象? 二、在unity论坛上查了下,有官方人员说UnloadUnusedAssets里是包含GC.Collect的,但是实际测下来感觉不太对。GC.Collect每次调用明显能在Profiler的CPU曲线里看到消耗时间,而调用UnloadUnusedAssets在CPU里则看不到。 帖子地址:https://forum.unity.com/threads/resources-unloadunusedassets-vs-gc-collect.358597/

1 年前 1 630

profiler里Assets和Scene Memory的区别是什么?粒子、模型之类的在这2个下面都有统计

有一些资源(比如某个Particle System)在2边都有,感觉像是冗余或者创建了多份之类的,这个可能是什么导致的?

1 年前 1 902

在某些安卓机上(比如oppo r9),用2个摄像机特定情况下渲染会出问题

在oppo r9上满足以下条件 1、用2个摄像机渲染,一个渲染场景,一个渲染角色/特效等 2、有一个方向光,会产生阴影的 这时候画面渲染看起就就会像卡住了一样,从profiler看逻辑还是在走的,盲操游戏把2个摄像机的状态取消掉之类的就会恢复正常。 请问有人知道这个的具体原因和解决方法吗?

2 年前 0 399