SwnzL2000 SwnzL2000
一个人睡双人枕
关注数: 4 粉丝数: 42 发帖数: 1,572 关注贴吧数: 9
郁闷,大障碍!!危险中 担心的最终还是出现了?希望不是啊,全图整理后终于觉得可以再次编译看看效果再进行后续的补充调整了。上次编译成功地图源14M多大,4万多个面。这次地图封口为近23M,6万多面。结果还是遇上了编译不能!还不知道是哪里的问题,有提示什么max_map_brushsides, 似乎每次提示所指固体位置?都不同。找到删了下次仍重复提示只是所指固体又为另一个固体。都是些无关紧要的小固体,看来此提示意义不在此。尝试初期有次不知怎地什么都没动居然又顺利编译下去了!其后终止于其它看得懂的错误如A。之后试了数次编译都是一开始就提示max_map_brushsides就结束了。 难道是面数超了?删除降面数,直到4万多面可以进行编译了并终止于之前提到的错误A。但过程中合并细节固体时有个警告提示内存溢出,要叫去除不必要什么什么的东西。回顾过往编译的那个14M源地图,也是4万面却没有这个编译警告。不得而解啊。 初步用那个CSGO的新实体来把地图一分二在合并编译,心说怕是不行吧?果然只是看起来面数锐减而已吧....一编译就导致Vbsp文件非法了,试了几次都如此.....。 现时心中不安难耐,数月的努力.....现在无力在试,上来记录下。还只算初尝试,应该还有希望能找出方法克服此巨大障碍吧?希望不要和图容量有关,这图还要往上加上几千面才能算完啊。
nnd,鼠标坏了啊!!!!另:地图构建基本完成。 原来还以为是4.1的兼容问题,最近才确认是鼠标出毛病了。单击左键会出现反复点击。nnd,2012新年才买的微软3.0加强版的什么闪灵鲨?200元啊!原来在网吧的老3.0比这个新货耐用多多了,网吧啊!那是多少人用啊!结果这个超好用的加强3.0如此不经用!!才一年多点点就失灵了。亏我如此小心使用,买七个月CSGO才玩了七八十个小时!都在做图了,按说左键用的根本不算多啊!坑大爷啊!查了下网,似乎这是微软这类鼠标的通病?? 3个多月前就如此了,单击变双击甚至数击,试想如要选中一个物体或拉个固体,需重复4--5次!!点个粘贴搞不好就给你在原位重叠复制2-3个,你不注意还看不出来白白浪费资源!一直以为是csgoSDK不完善会不时抽疯,我忍了,结果过完年后突然变本加厉了,仔细一试才发现是鼠标的事!!!!作图严重拖慢不说(好也快不起来,哇哈哈),主要太痛苦干扰了。 看来只能拿去换?修?不知还在质保期没?或再买一个了,还买这款好用不耐用的吗?话说打CS就是这款用的不错啊,纠结中........200元在常规鼠标来看不便宜了。 图终于基本算完成全部基本构建封口了,下步开始重头整理细化润几遍,看国外有的图确实有水平(所以国外作图综合质量确已不是当年CS时代,水平效果是与时递进),而我这图场景较多固体面怕是难得再加了,只有不到1000面的剩余空间了,当初故意留了一些多余固体没删,现在看删了能不能多挤下再多出1千多面?有心无力,画面怕难得有大突破了,现在有了创意工坊受众什么没见过,地图面子上不到一定标准如何得行哟。好在目前达到心中的严苛的及格线是没问题的。哇哈哈哈啊哈 然后再下步实体,再下步优化...等等还有好几个下一步.....(以后如在作图坚决不做复杂的了,时代在前进,游戏画面也是,CSGO要顾及的方面太多,以后更将慢慢超出我这个老倌儿驾驭范围了,有心无力。孤岛,BF那些画面更是无心无力了。看来一个人要搞确实难,搞点精致小图算逑了。 图虽封口了,但这次不再经过一次整理初优化是不敢编译的,就发不出游戏图了,来张3D图看个毛糙大概了。还有太多未完成,甚至贴图也空着好多。
CSS地图容量编译上限参数问题 下面报告中,那两个very full!和其它占到接近70%及以上的项谁能解释下含义所指,好像快不够了的样子。 Object names Objects/Maxobjs Memory / Maxmem Fullness ------------ --------------- --------------- -------- models 47/1024 2256/49152 ( 4.6%) brushes 6388/8192 76656/98304 (78.0%) brushsides 57454/65536 459632/524288 (87.7%) VERY FULL! planes 50236/65536 1004720/1310720 (76.7%) vertexes 42737/65536 512844/786432 (65.2%) nodes 3321/65536 106272/2097152 ( 5.1%) texinfos 8561/12288 616392/884736 (69.7%) texdata 364/2048 11648/65536 (17.8%) dispinfos 533/0 93808/0 ( 0.0%) disp_verts 25925/0 518500/0 ( 0.0%) disp_tris 38656/0 77312/0 ( 0.0%) disp_multiblend 0/0 0/0 ( 0.0%) disp_lmsamples 380348/0 380348/0 ( 0.0%) faces 20124/65536 1126944/3670016 (30.7%) hdr faces 0/65536 0/3670016 ( 0.0%) origfaces 17906/65536 1002736/3670016 (27.3%) facebrushes 1548/0 3096/0 ( 0.0%) facebrushlists 20124/0 80496/0 ( 0.0%) leaves 3369/65536 107808/2097152 ( 5.1%) leaffaces 24117/65536 48234/131072 (36.8%) leafbrushes 10738/65536 21476/131072 (16.4%) areas 16/256 128/2048 ( 6.3%) surfedges 172267/512000 689068/2048000 (33.6%) edges 115209/256000 460836/1024000 (45.0%) LDR worldlights 45/8192 4500/819200 ( 0.5%) HDR worldlights 0/8192 0/819200 ( 0.0%) leafwaterdata 2/32768 24/393216 ( 0.0%) waterstrips 2819/32768 28190/327680 ( 8.6%) waterverts 0/65536 0/786432 ( 0.0%) waterindices 55398/65536 110796/131072 (84.5%) VERY FULL! cubemapsamples 45/1024 720/16384 ( 4.4%) overlays 104/512 36608/180224 (20.3%) LDR lightdata [variable] 9888527/0 ( 0.0%) HDR lightdata [variable] 0/0 ( 0.0%) visdata [variable] 318928/16777216 ( 1.9%) entdata [variable] 85750/393216 (21.8%) LDR ambient table 3369/65536 13476/262144 ( 5.1%) HDR ambient table 3369/65536 13476/262144 ( 5.1%) LDR leaf ambient 12539/65536 351092/1835008 (19.1%) HDR leaf ambient 3369/65536 94332/1835008 ( 5.1%) occluders 0/0 0/0 ( 0.0%) occluder polygons 0/0 0/0 ( 0.0%) occluder vert ind 0/0 0/0 ( 0.0%) detail props [variable] 1/12 ( 8.3%) static props [variable] 1/112396 ( 0.0%) pakfile [variable] 7041448/0 ( 0.0%) physics [variable] 2469784/4194304 (58.9%) physics terrain [variable] 70825/1048576 ( 6.8%)
小议func_instance实体的作用,待研究。 现在还搞不太明白func_instance这个实体好处的具体体现。杂乱体会发上来整理 目前只知道这个实体可把一整个地图A(包含此地图所有固,固实,模型,点实及其它属性相关全部信息)都算为一个func_instance实体a从而在另一个地图B中被调用。然后在B地图可再添加其它想加的东西(反过了也可以)。 同理还可再建一个地图C再次调用B(func_instance b),这样C图到A图关系上应该是两层调用关联关系了。但在C地图中检查实体报告看func_instance,a和b都是同时显示的,貌似都算作同一级别,按理c图中应该只显示调用了func_instance b这一个才好理解啊?目前这样分级调用但又混在一起显示搞得人有点混乱。 可能问题,如地图A中已包含影响地图的整体信息,如太阳,雾,地图参数等等。那么在地图B中就要小心了,最好不要在添加太阳什么的,地图参数要和地图A一致,否则最后将以地图B中的为准,或不可知的问题。除非这种2套地图信息混合方案可让地图出现什么新奇效果。 例子:官方图似乎也不是所有总的编译地图都是大卸八块然后最后组合调用完成一个完整地图的。 有的最终地图和被调用的地图差异很小,如office只是把地图中散落的物理模型和区域声音实体单独作为一个整体地图如office.bsp,而它调用的office_main.bsp其实已经达到完整地图构建的95%, 有的被分的很多,像aztec就被分为一个地图调用多个小地图,像有的重复建筑就以小地图形式在主地图中被各处调用,传统做法是把此建筑直接复制放地图各处。相比前者或许可以在hammer中作图时换来较顺畅的操作. 而有的被调用小地图仅仅是5个玩家的出生点(搞不懂这么做的好处是什么啊?这玩家出生点直接放在地图中就费资源了说?搞得这么高科技意义是?)。 最后最终地图完成编译后看,传统的一整个地图被编译出来的效果,和这个地图是组合编译效果(用了func_instance),结果是一样的。func_instance具体好处应该只是体现在hammer做图时操作顺畅防溢出?另外不知编译地图进程运算时用无什么具体好处(可能很关键)? 个人觉得如还搞不清func_instance具体带来的优势,不必太纠结,一些中小型图没有必要用,而大型图说道底,用来做主图编辑的部分其实还是和传统一整个图的差不多,都已经很大了,所以可先按老方法先做着图在说
CSS地图RAD编译的光影差异问题深入追问????? 我对CSS编译参数不明,rad下来还各种问题:以下为同一实验图完全一样设置下不同编译!! 1:编译界面的标准模式:rad 用了不知道是什么参数(但肯定不是专家模式里的默认无参数) 编译结果:模型光影自身及相互较混乱,太阳下模型易自发光,房间里又不发光较暗了(自然暗),但如有背光较黑处暗的较自然。整体光(天,地,无模型的普通迎光墙)自然 完成大小:10m 2:full compile -HDR only模式 参数 -textureshadows -hdr -StaticPropLighting -StaticPropPolys -game 编译结果:模型光影自身及相互极自然,太阳下模型自然暗,房间里又自然亮了(和1相反),但如有背光较黑处暗的极其黑!整体光和1对比貌似稍浅或稍亮? 完成大小:8m 3: 2:full compile -both -final(slow!)模式 参数 -both -final -textureshadows -StaticPropLighting -StaticPropPolys -game 编译结果:参看2,肉眼几乎一模一样,除了整体光更接近1。 完成大小:12m 问题:整体光影无异2.3好于1,3比1好太多地图体积也大好理解,但为什么2编译下和3看似效果一样体积却小许多甚至比1还小?1到底有什么参数什么好处比2好所以体积要大点?2 的-hdr 和3的 -both -final具体有什么差别?2,3效果一样,为什么3的参数有那么费资源怕PC崩溃,不敢用-final? 还有下列附带主要问题:1也有好过2,3的地方?? 下图编译方式为1,(树的自身阴影及什么光都已禁止)树荫清晰可见!用了2,3方式:树荫变一坨了?为什么?方式1:背光且凹进处暗的自然方式2,3:黑的都.........标准编译1到底有什么参数使其上面效果比2,3 还好? 所以问的如此繁复,主要想搞清参数的相互关系用途到时捡适合的用。 费力打字大家参考,所以也请各位辛苦多打几个字有一说一就综合上面问题一一解答。 并详细讲讲这几个参数的用途以共享下?
首页 1 2 下一页