Jump to content
主视角中国

S-22

网站管理
  • 帖子总数

    11,783
  • 注册时间

  • 上次访问

由 S-22 发布的全部内容

  1. 沈阳。秋日阳光洒满幽静的院落。在这里,我们见到了当年志愿军“奇袭白虎团”战斗的历史见证人、沈阳军区原副参谋长黄在渔。老将军谈起当年的“奇袭”战斗,思绪飞扬——   “那是1953年7月,当时抗美援朝战争即将结束。我所在的609团是师里的第一梯队,任务是突破驻守在直木洞、栗洞等高地一线的韩军首都师第一团的坚固防御阵地。我们二营担任穿插任务,迂回到敌后战斗,切断敌人的退路,配合我正面主力部队歼灭敌人。607团的侦察排由副排长杨育才带队,配合我们营的穿插行动。 “韩军首都师第一团是李承晚的嫡系部队,全部美式装备,团旗上画着一只白色的老虎头,因此,叫‘白虎团’ 。我当时是2营6连7班班长,一听说要打‘白虎团’,大家情绪来了。我带领全班找到连领导,坚决要求担任尖刀班任务。 “7月13日晚11时40分,上级下达了出发命令。当时阴云密布,雨水涟涟,天黑得连我们左臂上系的白毛巾都看不清。我们尖刀班来到敌人的380高地前沿,就遭遇到敌人增援的车队。我把全班分成三个战斗小组,分工两人负责对付敌人的一辆汽车。 “我们迅速在公路边埋伏好,将先头几辆放过去,中间的几辆过来的时候,我端起冲锋枪,瞄准一辆车的驾驶室,高喊了一声‘打’!只见那辆车轮子一歪,一头栽到了路旁的沟里。这时,敌人的另外两辆车被其他的战友打中,歪在路边,车上的敌人乱成了一锅粥。 “打了一阵子后,我考虑到身负穿插任务,立即带领战友们主动撤离,继续挺进。行进到二青洞时,听见公路左侧山沟里传来隆隆的炮声,我们判断是敌人在打炮,决定抄到敌阵地后面,突然袭击打它个稀巴烂。就在这时,前面敌人两辆坦克开了过来。指导员郭树昌命令我带领两名战士打坦克,他带领其余的战士打敌炮阵地。 “那是我第一次打坦克,那家伙浑身是铁,横冲直撞,我对两个战友说,我打第一辆,你俩掩护。说完,我躬着身子,手握爆破筒,在离坦克三四米的时候,突然冲到坦克侧面,迅速把爆破筒插进坦克履带里,拉响了导火索,没想到,快速旋转的齿轮将爆破筒甩了出来,在地上嗤嗤冒烟。我再次抓起即将爆炸的爆破筒,斜着扔到了那辆坦克履带的前面,然后就地一滚,只听得轰地一声巨响,坦克变成了一堆废钢铁。 “敌人的第二辆坦克距离第一辆坦克大约50米,前面的坦克被炸了,后面的坦克吓得停了下来,车里的敌人架起高射机枪,朝第一辆坦克左右方向猛烈扫射。战士张树勤悄悄地摸到第二辆坦克背后,将一颗手榴弹甩到了坦克尾部的油箱上,油箱燃起了烈火。不一会儿,跟指导员打敌炮阵地的几名战友回来了,告诉我,他们缴获了敌人8门榴弹炮,杨育才带的侦察排已经捣毁了‘白虎团’的团部。大家听了非常振奋,忘了饥饿和疲劳,继续穿插搜索。 “远处不时传来敌人的炮声。炮声就是命令!我们勇猛快速地接近新发现的敌炮阵地。敌人炮阵地设在一条山沟的平地上,共有4门24管火箭炮,对我正面进攻的志愿军部队构成巨大威胁。我们在敌阵地后面的山坡上,一边观察敌阵地,一边研究歼敌方案。 “爬进敌人的铁丝网,偷袭!大家统一了意见。我带着一起打坦克的张树勤、马头保和另一名战友前去袭击,其他人掩护。在离敌人40米左右的时候,敌人发现了我们,子弹像雨点一样地扫射过来。 “负责掩护的战友用重机枪,向敌人猛烈开火,把敌人的火力吸引了过去。趁着这个机会,我们三人迅速靠近铁丝网,顺着一条小水沟往里爬。铁丝网撕开了我们衣服后背,划伤了皮肉,可这个时候,大家什么也顾不上了,忍痛钻了过去。敌人发现我们已经钻进了铁丝网,向我们猛烈地射击。马头保中弹牺牲,张树勤和另一名战友腿部受伤,我的左臂中弹,不能动弹。 “拼了!我把冲锋枪往右臂底下一夹,站起来朝敌人冲去,两名腿部受伤的战士不顾伤痛,趴在地上朝敌人更加猛烈地射击。敌人被我们的气势吓住了,撒腿逃命,但他们哪有我们的子弹跑得快,20多名敌人很快被消灭掉。后来,连队的其他战友赶来,全歼了阵地上的敌人。 “我们圆满完成了穿插任务,配合主力痛歼了‘白虎团’,缴获了他们的团旗。如今,这面团旗收藏在中国人民革命军事博物馆。 “由于我在这次战斗中完成任务出色,志愿军总部给我记了一等功,授予我‘二级战斗英雄’称号,朝鲜民主主义人民共和国授予我一级国旗勋章,我执行任务时用过的冲锋枪被朝鲜解放战争纪念馆收藏。”
  2. 这里可以下载论坛: http://bbs.guomin.net/index.php?showtopic=395
  3. 本站针对于 IPB 2.x.x 汉化加工的论坛按钮,欢迎下载。呵呵~~ 想不到本站正式发布的第一个作品竟然跟游戏灭有关系。样品么,就是这些按钮了。
  4. =============================================================================== 2005年4月13日 =============================================================================== MOHAA V1.11 迷你服务器 V0.92 请大家自觉使用一两个线程下载。镜像下载: [=JS=战队镜像 ] 本站专门为架设独立主机而推出的特别版本,与用完全安装的游戏建立独立主机相比,软件体积减少了93%;系统资源占用减少了70%;可以直接修改文本格式的主机配置文件;在未来的版本中将具备强大的扩展能力。 注意:随便解压缩到哪里都能运行,就是不要解压缩到原来的游戏目录里,这个迷你服务器版与原来的游戏没有任何关系!只要有了这个,没有原来的游戏一样开服务器的。 使用方法: 1. 随便解压缩到哪里。 2. 修改 main 目录中的 server.txt 内容,某些情况下不改也行。 3. 运行 111.exe 即可启动 V1.11 服务器。 4. 当控制台最后出现 Hitch warning: xxxx msec frame time 字样表示服务器成功运行。 港澳台玩家请下载繁体中文标注文件 -> [繁体中文标注文件使用方法:将 V0.9 Mini Server 安装完成后,把繁体标注文件覆盖到相应的文件夹即可。其实只有两个文本文件:readme.txt 和 main\server.txt ]
  5. 是不是链接没有改好?图片不能显示是因为这个论坛是动态的,有些图片的链接方式不是传统的.....gif 或者 ........jpg 的形式,所以另存为网页这些图片是不能显示的。 可以去下载一个 ipb 2.x.x 版本,里面有图片可以拿来用。
  6. 有啊,游戏现场能看到波光粼粼。。。。 Oct.31 20:40 -> 完成度 45% 。增加了爬出泳池的梯子。从跳台上看泳池。那些小人都是AI。 泳池边。
  7. 看看BIOS里的键盘Type Rate部分是否改动过。 换个键盘看看。
  8. 有浅淫哪。。。。
  9. 可以在防火墙的属性里允许相关端口的访问。
  10. 水下会有反应。 Oct.31 02:50 -> 完成度 35% 。跳台雏形,加入了水。游戏现场是波光粼粼的,截图体现不出来。 Oct.31 17:10 -> 完成度 40% 。加入跳水台雏形,泳池分为三级深度,每个深度放入一名 AI 进行比例测定。 从跳台上掉进没有水的泳池,摔死了。
  11. 本站地图制作计划,目前进行中的是泳池地图。详细情况请 点击查看 。
  12. S-22

    s-22

    还是用关卡编辑器建立互动脚本吧,建好后直接复制脚本就行了。10分钟差不多等于手工改1小时,能省不少时间。 这里有两个东东,一个是m1l1的坦克带原始.map文件,一个是坦克教学,我刚才看了一下非常非常全面,希望对你能有所帮助。
  13. S-22

    s-22

    太长了,还是用MOHRadiant做好再把代码复制下来吧。直接改太麻烦,容易出错。
  14. S-22

    资料备查

    1. Make your door as usual, texture it. 2. Now we need a hinge for the rotation. Use the "Origin" texture from the "Common" pack for it. 3. Highlight both the door & hinge & add func - rotatingdoor. 4. Hit "N", set the angle. 5. key=alwaysaway value=1 is obvious. the door will always open away from the player. 6. If you want a double door you just repeat that process, and if the doors are touching they work as 1.
  15. S-22

    资料备查

    1. Make your door brush, texture it, etc... 2. Add a door function: highlight your door brush, rightclick on it in the 2D view, select: func - door 3. Specify direction: Select your door, hit "N". Direction is best done from the top view. The little angle pad (90,180,270,360 etc.) matches the angles with the top view. Just click a button and values are entered automatically. in this case key=angle value=0. 0=360. 4. Sound: by default sound is set for a wooden door. in this case we need a metal sound. key=doortype value=metal You should now have a functional sliding door.
  16. S-22

    资料备查

    Here is how it works... the door only moves as far as it is thick/long/wide... depending on which angle you set it to move. We will be faking the vertical size with a invisible brush. Once you have your elevator constructed and the fake height brush, highlight them all and add the door function. Give it a -1 angle by hitting the "U" button since it's going up. You can set the speed then make it wait on top with the key: wait, value: 3 (secs). Change the sounds or use the wood default or metal "doortype". Not sure about changing individual sounds on the door, haven't toyed with that yet. This is very simple but you can set up the triggers on top and bottom and control it from wherever you choose. Only 2 levels but it works, no need to get fancy with scripting for something simple. The invisible brush... I applied clip texture against the wall, you can use others. For some reason origin didn't do the trick. Here's a simple reference shot:
  17. S-22

    资料备查

    20/01/2001 © William 'SmallPileofGibs' Joseph Thanks to MrElusive and Maj Geometry Definitions A Point A in a map is stored as a single set of coordinates (X,Y,Z) using Integer (whole number) arbitrary units. A Line AB is represented by two Points A and B with a straight line of infinite extent passing through both points. A Plane ABC is represented by three Points, A B and C with a 2-Dimensional (flat) surface of infinite extent passing through all three points. A plane has a front and a back. An Area is a finite part of a Plane bounded by Lines. A Polygon is an Area bounded by 3 or more Lines A Volume is a finite part of a 3-Dimensional space. It is bounded by four or more Planes. An Axial Plane is a Plane perpendicular to one of the grid axes, X Y or Z. A Plane is perpendicular to the X axis when all points on the Plane have the same X coordinate, eg. X=0. A Vertex is a Point (plural Vertices). A Vertex in a BSP is stored as a single set of coordinates (X,Y,Z) using Floating Point (decimal fractions) arbitrary units. A Triangle is a Polygon with three Vertices (plural Triangles or "Tris") A Strip is an arrangement of multiple Triangles in a strip shape, each new Triangle sharing Vertices with an adjacent Triangle. A Fan is an arrangement of multiple Triangles in a fan shape, each new Triangle sharing Vertices with an adjacent Triangle. 2-Dimensions: Areas Starting with a Plane seen in 2D (2dstuff1.gif) we can draw a single Line of infinite length dividing the Plane in two (2dstuff2.gif). Adding more non-parallel Lines (2dstuff3.gif, 2dstuff4.gif) allows us to define an Area on the Plane. An Area bounded by three or more Lines in this way is always a convex Polygon. It is impossible to bound a non-convex Polygon with straight lines of infinite length. 3-Dimensions: Volumes Starting with an infinite Volume of space, imagine a Plane dividing it into two child Volumes, front and back. Four or more non-parallel Planes are required to define a finite Volume in an infinite space. A finite Volume defined by four or more Planes is always a convex Volume. Map Definitions Brushes A brush is a convex Volume. This Volume is always bounded by four or more Planes, each Plane forming one Face of the Brush (bface.gif, bplane1.jpg, bplane2.jpg). Each Brush Face has a set of Texture, Surface and Content properties. Texture properties are a small number of values defining: ONE Shader Name, XYZ Scale/Stretch values, rotation. These values are stored along with each face in the mapname.map file. One Brush Face can only have one set of Texture properties. Surface and Content properties are stored in an external Shader script. However, some Content properties may still be stored along with the Texture properties in the mapname.map file, one example being detail. Bezier Patch Surfaces Bezier Patches or "curves" are one type of Parametric Surface. A parametric surface is a surface with a shape defined by a set of parameters, so the shape of the surface can change depending on the values of the parameters. For Bezier Patches in Quake 3, the parameter is the LOD, or Level Of Detail. Patches in Quake 3 are rendered with triangles, so the curves must be 'tessellated' (subdivided) into a number of triangles. The higher the LOD value, the more the curve is subdivided, and the more triangles are created in tessellation. The LOD can be set to change with the viewer's distance from the Patch, decreasing as they get further away. In Q3 "r_lodCurveError" controls how much the LOD changes with distance, and "r_subdivisions" fixes the maximum LOD for all curves. A Patch is stored as a 2-dimensional matrix of points. A 2-dimensional matrix is a table containing sets of values arranged in rows and columns. Each point is stored as two sets of values. One set contains the XYZ coordinates defining the location of the point in the 3-dimensional volume of the map. The other set contains the UV coordinates defining the location of that point on the 2-dimensional area of the Shader. One Patch can only have one Shader, for the same reason one brush face can only have one Shader. Shaders A Shader is a collection of properties that controls how a surface is treated by the compilers, and how the surface is rendered by the Quake 3 engine. Every Surface has a default set of Shader properties, unless an external shader script is specified. Combinations of a number of pre-defined properties control the way the compiler treats the surface. See the Shader Manual for more information. "SurfaceParm" is the shader keyword for universal shader properties. SurfaceParms are either Brush "Content" Properties or Brush "Surface" Properties. A Content Property applies to the contents of an entire Brush if the first face of the brush (face 0) has that property. Because of this, identical Content Properties should be applied to all faces of a brush to avoid unpredictable results. A Surface Property applies only to the surface with that property. Relevant SurfaceParms (for full list see the shader manual) Content: solid(default contents unless alternative specified. Brush is solid, casts shadows, clips players and all entities) nonsolid (Brush is not solid) structural (default contents unless alternative specified. Brushes split BSP, but only block visibility if not trans) detail (Brush faces do not split BSP or block visibility) playerclip (Brush clips players only, faces do not split BSP) trans (Brush does not cast shadows) Surface: nodraw (Face removed at compile) nolightmap (Lightmap not created for face) SurfaceParm combinations in common shaders: DEFAULT - Content: solid, structural - Surface: Visible, has lightmap. common/caulk - Content: solid, structural - Surface: nodraw, nolightmap common/hint - Content: nonsolid, structural, trans - Surface: nodraw, nolightmap common/nodrawnonsolid - Content: nonsolid, structural - Surface: nodraw, nolightmap common/clip - Content: playerclip, trans - Surface: nodraw, nolightmap common/weapclip - Content: solid, trans - Surface: nodraw, nolightmap Entities A Quake3 map is a collection of Entities, numbered from 0 upwards. Some Entities can have Brushes and Bezier Patch Surfaces belonging to them. All Brushes and Bezier Patch Surfaces belong to the Worldspawn Entity (entity 0) by default. The Worldspawn is the solid hull around the map (the game "World"), containing all other entities within the space inside. All entities in a map have an Origin Point and an Axis-Aligned bounding Volume (or bounding-box). The Worldspawn's Origin is the point (0,0,0). Each entity has a set of Properties. These properties are predefined "Keys", each Key having a variable value, which can be numerical values or a string of text. Mapobjects Each Mapobject is a collection of triangle surfaces arranged in Strips. The Strips are stored as one frame in a single objectname.md3 file. A Mapobject strip is similar to a Bezier Patch surface in that it cannot be structural and can only have a single shader. Each Mapobject strip has a shader name and and a set of texture coordinates assigned to it, which are stored in the objectname.md3. The md3 format is the same as the format used for item and player models in Quake3, so Mapobjects require no pre-processing other than being added to the BSP at the first compile stage. Mapobject strips cannot have content properties, and do not have a lightmap, but they can emit light or cast shadows, depending on the strip's shader properties. The Q3 compile process has four stages: BSP, VIS, LIGHT, BSPC. Stage 1. "BSP" (q3map mapname.map) mapname.bsp is the format that compiled Q3 levels are stored as. The important part of this process is the actual creation of the BSP Tree from the brushes of a map. What does the BSP stage do? The player-navigable space inside the World is split into convex volumes bounded by planes. These convex volumes are called Leaf Nodes. The Leaf Nodes are stored in a binary tree called a BSP Tree. Note: The "player-navigable space" inside the World means: everywhere in the game World that isn't a brush which is both solid and structural. The area the player can navigate around in the World using noclip, without passing through a Solid structural Brush. All World Brushes are Solid and structural unless they have a different content property set. Non-structural content properties are detail, playerclip, trans. Non-Solid properties are WATER, LAVA, nonsolid detail brushes are set by surfaceparm detail, or by making the brush detail in Radiant (viewing detail is toggled by ctrl+d). Some of the common/ shaders are structural, but not visible, including: CAULK, HINT, nodrawnonsolid, AREAPORTAL. The rest are either non-structural, are only used on Entities, or are not commonly used in maps. How and why is the BSP created? A map is a 3-dimensional volume of space extending +/- 4096 units from the origin in X Y and Z, containing smaller solid convex volumes bounded by planes (structural brushes). The goal is to use the fewest splits possible to split the space of the map into convex volumes, each of which do not contain any structural brushes. A simple cube room is a convex volume bounded by six planes. Convex volumes are important for visibility, because it is simple and fast to determine whether two convex volumes can see one another. These convex volumes are stored as Leaf Nodes in a binary tree, making it easy to determine which Leaf Node the viewpoint or objects (entities, tris, patches) are in. This is called a Binary Space Partitioning Tree, or BSP Tree. A BSP tree is produced using a recursive operation. A recursive operation is one that causes itself to repeat within itself. The operation is performed on a Volume, starting with the entire map as a single Volume: If the Volume contains structural Brushes... Then split the volume along the Plane of the Face of one structural Brush. Continue to the first child Volume produced and repeat the operation. Else, if the Volume does not contain structural Brushes, it contains no Planes for splitting, and a Leaf Node is created for the volume. Then return to the next child Volume up the tree and repeat the operation. If there is no child Volume, end the operation. Note: Each split-plane does not always divide the volume exactly in half. Axial split-planes are chosen before non-axial split-planes. The split-plane which cuts through the maximum number of brushes is chosen. It is important to split the tree roughly in half each time in order that each Leaf Node is roughly the same distance from the tree's root, balancing the branches of the tree. How can I control the BSP splits? (a way to use detail and Hint brushes) ALL structural brush face-planes, Including completely hidden or nodraw faces, are possible candidates to split the BSP and create extra Leaf Nodes. Leaf Nodes are currently NEVER merged, even if the result of the merge would be a new convex leaf. The ideal situation is to have all structural brush faces axial and perpendicular to the grid lines every 128 units. Any more complex brushes can be made detail, and all hidden structural or detail Brush faces can be made nodraw as well, by applying the common/caulk shader. The effect is similar to using Bezier Patch surfaces, which also do not block vis or have any other visible faces than the front surface. Hint Brushes are structural, trans, and nonsolid. This means they are totally invisible in a compiled Quake3 level, but their Face-Planes are used to split the BSP like other structural Brush Face. A large Axial Hint brush face will be an ideal candidate to be used for a BSP Split. Adding Hints with Axial faces (perpendicular to the 128-unit grid lines) aligned with other Axial Planes from structural Brush faces, minimises the number of extra split-Planes and Leaf Nodes. Basing a map on the 128-unit grid allows you to hugely simplify the visibility process. If the leaf nodes are all 128-unit cubes, its very easy for the designer to predict whether one area can see into another, and place simple axial hint brushes to reduce visibility with minimal increase in vis pre-processing time. As detail brushes and bezier patch surfaces do not affect the shape of nodes they can be used to build up complex architecture in front of simple axial structural nodraw brushes What is a leak? A quake3 map is a hollow space made up from a number of convex volumes (Leaf Nodes) contained within a solid outer hull. The Leaf Nodes "outside" the map are discarded (pruned =) after the BSP Tree is created. There is a "leak" if you cannot separate the Entities on the inside from the "void" outside the radiant grid. If there is a leak q3map generates a detailed error message (seen if you use q3map -v) and records the path of the leak to the Pointfile "mapname.lin". Usually a leak will be displayed in Radiant as a path from the origin of an entity to a Leaf Node touching the area outside the radiant grid without passing through a solid brush. What is the .prt file? The Leaf Nodes remaining in the BSP Tree after the outside Leaf Nodes are removed are bounded either by other nodes or by structural brush faces. A Portal is created for every face of a Leaf Node that is bounded by another Leaf Node. Each Portal is like a window from one node looking outwards into another. The Portal information is not needed in the BSP, but it is essential to VIS, so it is stored in the portal file "mapname.prt". How are the brushes/patches turned into triangles? For brushes, a convex polygon is defined for the area of each visible brush-face that touches one or more Convex Leaf Nodes. Brush-faces with surfaceParm nodraw are ignored. Extra vertices on are created on the edges of each polygon where other polygon vertices meet the edge and create a T-junction. The extra vertices 'fix' the T-junction by turning it into a point where three polygon edges meet. If a vertex lies on an edge that cannot be split, there will be a tiny crack in the hull of the map (along the edge that cannot be split). These tiny cracks are known as "sparklies", because of the way they look when a bright surface is drawn behind the crack and 'sparkles' through it. Finally, each polygon is divided into triangles and stored as an OpenGL primitive called a Triangle-Strip, or as a Triangle-Fan in some cases. Patch Surfaces are treated as a collection of points during the BSP compile, and are turned into Triangle-Strips when the map is loaded. For this reason, T-junctions involving Patch-surfaces cannot be fixed automatically. Texture coordinates are generated for each vertex. Texture coordinates are two values U and V (UV Coordinates or 'UVs') which specify the position of the vertex on the texture image as a percentage. These coordinates are normalized decimal (Floating Point) values between 0 and 1: If the texture dimension are 256*128, and a vertex has the UV coords (0.5,0.75), the texel (texture pixel) at 50% of 256 horizontally and 75% of 128 vertically will be drawn on the vertex. Note: each brush-face or patch-surface is a separate primitive, enabling it to have its own set of Texture Coordinates and Shader properties. Stage 2. "VIS" (q3map -vis mapname.bsp) bsp_fullvis VIS is short for Visibility. The relevant part of this process is the creation of the PVS Table for the Portals in the map. As the player's viewpoint moves around a FULLY vis'ed bsp different areas become visible or hidden, depending on which area the viewpoint is in. How is the PVS created? Every Portal in the portal file is checked against every other Portal for visibility. Portal 1 is visible to Portal 2 if a straight line of sight can be drawn between any part of Portal 1 and Portal 2 without passing through a solid structural brush. Every Portal then gets a list of the other Portals that can be seen from it. This information is the Potentially Visible Set and is stored in the PVS Table. What does -vis -fast do? Otherwise know as "bsp_fastvis", using the -vis -fast option does not create a PVS, leaving every Portal visible to every other Portal. How do Portals affect visibility? Every Leaf Node has one or more Portals (unless there is only one node in the BSP tree). If a Portal belonging to Node 1 can see a Portal belonging to Node 2, Node 1 is visible to Node 2. When the player Viewpoint is anywhere in Node 1, every object in Node 2 is drawn. When the player Viewpoint is in Leaf Node x, every object in every other Leaf Node visible from x will be drawn. Objects include Brush Faces, Bezier Patches, Entities. One object can be in more than one Leaf Node at the same time. A Brush Face is drawn when any part of the face is touching a visible Leaf Node. A Bezier patch is drawn when any of its control points are touching a visible Leaf Node. An entity is drawn when any part of its bounding box is touching a visible Leaf Node. To summarise: Effectively, solid structural brushes block visibility between the contents of Leaf Nodes. Curves, detail brushes and Entities do not block visibility. Visibility between two areas will only be blocked when both areas are completely hidden from each other. Generally, the more Leaf Nodes visible from the Leaf containing the Viewpoint, the more objects will be drawn. The aim when optimising for visibility, is to have the smallest number of other Leaf Nodes visible from any one Leaf Node. More of the map will be drawn if the BSP has a small number of large leaf Nodes, or an innefficient arrangement of Leaf Nodes. You can reduce the number of Leaf Nodes created by reducing the number of unique structural Planes in the map, by making all unnecessary structural Face-Planes into detail Brushes. You can control visibility by placing Hints to create the Leaf Nodes and their Portals exactly where you want them to be, splitting the space into more Leaf Nodes only in areas where they are needed. How can I make VIS more efficient? (and reduce -vis processing time) The time -vis takes is roughly proportional to the number of Portals in the map. The number of portals is displayed when you start VIS, as "numportals xxxx". The visdatasize is the size the PVS table takes up in the mapname.bsp file - this is limited to around 2MB. A lot of Leaf Nodes means a lot of Portals. A lot of Portals means a long vis time. The number of Leaf Nodes depends entirely on the complexity of the BSP. Solution: detail brushes - Making a brush detail will stop it from affecting the BSP Tree, reducing the number of Leaf Nodes formed. To make any brush a detail brush, select it and press ctrl+m or Selection > Make detail. Toggle viewing of detail brushes with ctrl+D or use the View > Show menu. The drawback of wide use of detail is that over-simplifying the Leaf Nodes can hurt your visibility efficiency (see visibility summary). Solution: HINT brushes - A Hint brush (common/hint) will be invisible in Q3, but is structural, so it will affect the BSP Tree and create more Leaf Nodes. This gives you a lot of control over WHERE the Leaf Nodes are created. Placing a hint brush in an area of open space will force creation of a Leaf Node within the area of that hint brush. Hints can also intersect with other structural solid brushes or Hints, creating multiple Leaf Nodes or isolating groups of Leaf Nodes. Hint brushes use a shader which makes the brushes nonsolid and nodraw, called common/hint. Hints are best used to make large axial cuts along planes shared by other structural brushes, to maximise the amount of area hidden by each vis-blocking structural brush, by minimising the number and size of the Leaf Nodes visible. Intelligent use of detail and Hint brushes in combination can reduce vis time and r_speeds in almost any map. However the map must be designed from the start with this in mind. Redoing an inneffiently made map is a lot of work. Note: Making a brush detail will stop it from blocking visibility, so don't make your vis-blocking walls into detail brushes. Stage 3. "LIGHT" (q3map -light mapname.bsp) This is the lighting stage, where lightmaps are generated for every world surface in the map. It has no effect on bsp, hints, vis or r_speeds. How do lightmaps work? The Q3map -light algorithm creates a lightmap pixel for every 16 game world units on a brush, and every 20 units on a patch, stored in 128*128 pages. The lightmaps are 24bit RGB, and are blended with the textures by multiplying the lightmap RGB values with the RGB values of the texture (see the Shader Manual: blendfunc filter). How are lightmaps generated? All lightmap pixels start pure black (RGB 0 0 0). A straight line is traced from the centre of each lightmap pixel towards the origin of each point light source. The distance between the pixel and the light source decides the brightness the light adds to the RGB values of that pixel. If the line is blocked by any visible non-transparent brush, the light source does not have any effect on the lightmap pixel. The time taken by the LIGHT stage is proportional the number of lightmap pixels multiplied by the number of point light sources. What about surface lights? Surface lights are subdivided using the q3map_lightsubdivide value (default 64), creating a point light source on the surface every 64 units. These are used in the light calculations in the same way as other point light sources. What does -light -extra do? Using the -extra option a straight line is traced from four extra points on each lightmap pixel in addition to the original one. The average of the result is taken, which helps to smooth out jagged shadows. Unfortunately it also makes -light take five times as long. Stage 4. "BSPC" (bspc -bsp2aas mapname.bsp) This stage uses the bspc tool, and generates an Area file mapname.aas. The Area file is used by bots to navigate the map. BSPC is a separate process from the other compile stages, and and it has no effect on and ignores any information created in those stages. BSPC requires only a mapname.bsp which does not leak. How does BSPC interpret the map? BSPC uses the Brush Face information in the mapname.bsp to make a list of Faces which clip the bots. Bezier Patches are tessellated into into planar Faces called "curve brushes" and are then treated the same as other Brush Faces. Face content properties which clip bots include: structural (all brushes or curves are structural by default), detail, Trans, playerclip. All Faces which clip the player are considered solid to bots, so they are all treated identically as "solid" and any other content property is forgotten. What is the "Brush CSG" stage of BSPC? During this stage unnecessary Brushes are discarded. If any Brush is completely contained within another Brush it will be discarded, by CSG-Subtracting the container brush from the contained brush. The more brushes BSPC ignores the better - use large simple clip brushes to completely contain any complex architecture made from multiple brushes. How is the area file created? BSPC splits the bot-navigable space in the map up into convex volumes called Areas, in a process similar to q3map BSP. Each Area must be convex, like the Leaf Nodes in a BSP Tree. BSPC also tries to minimise the number of Areas by merging any two Areas where the result is another convex Area. BSPC stores the Areas in groups called Clusters, in the Area file "mapname.aas". A Cluster is a group of connected Areas, separated from other Clusters by Solid walls or Clusterportals. Without Clusterportals, most maps will have a single large Cluster of Areas. You can see the Cluster/area info in bspc.log after creating the area file. Note: Bot-navigable space in a map is anywhere on the inside that isn't a solid player-clipping brush. Solid player-clipping brush content properties include: solid(default for all brushes unless nonsolid), playerclip. How do Bots use the area file Bots use the Areas in the Area file to navigate between Entities in the map. At any point in time they have to be thinking about all the areas in whichever Cluster they are in. If there are a large number of areas in that Cluster, the bots' cpu usage will be noticeably larger while they are in it. More than 1000 areas in the Cluster gives a very noticable performance hit - below 500 is much better, and the smaller the number of areas in the largest Cluster the better. How do I make Clusterportals? Clusterportal Brushes are used to control the way BSPC creates Clusters, by adding potential Clusterportals for BSPC to consider. Clusterportal Brushes should not be confused with Areaportal Brushes as there are a few important differences in their use. Clusterportal Brushes should be thin axial brushes, up to 32 units thick. For a Clusterportal brush to be accepted by BSPC as a ClusterPortal it must have two opposite faces touching two separate Clusters. It must be placed in a doorway or a horizontal passage where bots can freely walk through it rather than falling through vertically. The two opposite faces should be identical in shape and size, and the other four faces should be against solid brushes or clip brushes. Note: In the same way as Areaportals, Clusterportals must be used to entirely separate parts of the map from each other. If a bot can reach area 2 from area 1 (via any other areas) without passing through a Clusterportal, both areas are connected and will be part of the same Cluster.
  18. S-22

    资料备查

    There has been a great deal of discussion and speculation about what Vis brushes and the Vis compile process do. Much of it is erroneous. It doesn't work the same way for the MOH engine as it did in previous iterrations of the Q2 and Q3 engines. The purpose of the Vis brush is to tell the Vis process to create a view portal (a node in the Vis tree structures). You are telling the Vis process this is a logical break in the view, It will create a view portal for each Vis area. It should result in longer trees and make your compile run slower, but should improve performance, if used intelligently. Using the Vis brush presumes you have a reasonable understanding of what can and can't be seen; and that the area you choose to make a seperate Vis area really can't be seen from everywhere. From the maps people have sent me to check out, these are not concepts many of you understand. Putting a Vis brush around a building that can be seen from everywhere on the map does absolutely nothing other than create breaks in the trees where none would have existed and generate additional leaf nodes. It will frequently result in more vis data. The same applies to hint brushes. The BSP compile process creates trees. A tree is a series of flag settings that indicate what triangles can or can't be seen from various locations on the map. Only structural brushes and entities that are not affected by culling and LOD operations are included in BSP process. The leaves on the tree represent potential breaks in the view and are translated to view portals. The Vis compile takes all view portals and determines what can be seen from one view portal to all others. This process increases in time exponentially with the number of view portals your map has. For example, if you have 2 view portals, portal 1 can see portal 2 and portal 2 can see portal 1 (2 entries). If you have 4 portals, portal 1 can see 2, 3, and 4; portal 2 can see 1, 3 and 4, etc. A total of 12 potential entries. The difference in Vis levels is in the granularity, range and accuracy of the Vis data created. A fast Vis says all portals are visible from all other portals. This sounds disasterous, but given the nature of today's map designs, it may not mean much. The MOH engine (as well as some other new versions of the Q3 engine) perform a lot more real-time rendering than their predecessors and do not rely on Vis data as much. Real-time culling, maxplane and LOD functions have made Vis data less meaningful. UT doesn't use it at all. The engine decides what it will render and uses the vis data to determine how to render it. If it doesn't have complete Vis data, it extrapolates it from surrounding triangles. This is quite a departure from older games where the Vis data determined what was rendered, almost entirely. If you follow the old "Q2 corner shooter" design philosophy and limit your brush count and feature usage, you will realize some significant differences in framerate with increased vis quality. The problem is maps have gotten much bigger and more complex and the compile processes we use have not kept pace. There is still very finite limits to vis data and light patches. We are forced to use a lot more detail brushes than we would have used in the past, making areas of our map visible that may not have been. In addition, most maps contain significant outdoor areas and afford little or no blocking opportunities. Consequently, you won't realize much in the way of framerate savings over fast vis. Detail brushes prevent branches in the BSP tree structure from occuring, so consequently they have no affect on Vis. But they are not without cost. They have no blocking capabilites and still must be rendered in real-time, without the aid of precompiled data. I have one more wrinkle to throw at you. We are accustomed to the engine being able to see over, under and around everything but a blind corner. The MOH engine is a lot more sensitive and directional than what we are accustomed to, particularly up close. What would not have been a blocking brush previously, may now be. Q:You say Detail has no affect on VIS then how come a map with 2,100,000 wont compile but if you go in and detail a couple of say round objects or something that has a lot of pieces to it and come out, with no other changes and recompile the VIS may be anywhere from 100,000 to 200,000 or more lower and now you have a map that is 2,000,000 or 1,900,000 and it will compile A:I think we have a symantics issue here. It is not the presence of detail brushes that reduces your vis count, it's the removal of structural brushes. Detail brushes are ignored, hence they have no (adverse) affect on vis. Actually, to be entirely correct, vis doesn't see any brushes, it sees view portals. Q:Hey bro do you have the know on the vis_leafgroup entitie in mohaa?The m4l0 map uses em and my pal wombat said even though he doesnt understand them they greatly reduce compile time. Thing is they target each other and its wierd. So if you know about em please blah me Hey your the greatest may the whole world smile on you A:Sumo, great to here from you again! Unfortunately vis/leafgroup is unique to MOH and I can't find any documentation for it. I've tried it and I also have no idea what it's doing or why. But, come back soon, anyway. Q:Some questions... What's the difference between vis and hint brushes? Can I overlap playerclip brushes with regular ones? And what other utility brushes am I allowed/not-allowed to overlap? How do I make closed doors block vis like in v2? Would it really affect anything if I have mixed fence masks? I don't want to use extra brushes if I don't really need to.
  19. S-22

    s-22

    Tank的生命值设定为多少?看看某个Tread是不是没有正确完结?
  20. 创意提供:一直以来的想法 MOD介绍:独立的单人游戏MOD,也会考虑多人模式的存在。模型贴图几乎全部需要自己制作,目前已经搜集了不少资料,在几个关键制作测试后就动工。 制作进度:0%
  21. 创意提供:S-22 地图介绍:取材于去年买的一张DVD,关于德国雷玛根大桥的战事。这个我也得再看几遍DVD。模型全部走游戏原版。 制作进度:0%
  22. 创意提供:GamesBond 地图介绍:很久以前GamesBond跟我提到过,取材于拯救大兵瑞恩的一段盟军破坏德军雷达站的影片。这个我还得再看几遍DVD。模型全部走游戏原版。 制作进度:0%
×
×
  • 创建新的...