HLFX.Ru Forum - Custom version of ZHLT by vluzacn

Хочу сказать что тема будет вестись на английском языке. Т.к. перевод требует некоторое время и ресурсы. Но если кто то возьмется перевести я буду только за.

Старые версии постить не буду, начну с 25 той.

Update:

version 25

Improve hlrad's ability to handle the case of too many dynamic light styles on a face.
When a face gets more than 3 different dynamic light styles, some of the light styles must be discarded. Now hlrad ensures that the brightest 3 dynamic light styles will be kept.
The 'too many styles' error will no longer occur. But any style darker than the 3 brightest styles will be discarded without any warnings, because I haven't created a warning for that.

Add 'func_detail' entity, which is similar in function to the func_detail in Source, though I probably implement it in a rather different way.

What is func_detail:
(Brushes that are not in any entities are called world brushes, and brushes in func_details are called detail brushes.)
Detail brushes are almost same to world brushes. They cannot be distinguished from world brushes once the compile has finished. For example, when viewing the bsp with 'BSP Viewer', func_details don't disappear after unchecking 'render entities'.
What makes detail brushes different from world brushes is that they don't participate in visibility calculation, which means they won't slow down hlvis.
A better description can be found here: http://developer.valvesoftware.com/wiki/Func_detail

Differences between detail brushes, world brushes and func_walls:
Compared to world brushes, detail brushes don't block vis or slow down vis process, and don't chop faces from world brushes, and don't cause the 'Ambiguous leafnode content' warning.
Note that detail brushes cannot be used to seal a map, and must not be made of water or sky (but SKIP and CLIP can be used in func_details).
Compared to func_wall, func_detail don't consume engine's model precache slots (which is 512 max), and will give player mdl (and any other mdl) correct brightness when he steps over it.
In addition, there is an option that allows a func_detail to chop faces of world brushes in order to reduce face area and produce better lighting.
But unlike func_wall, the faces in func_detail will be cut if it happens to span across a splitting plane of the BSP structure generated from world brushes and func_details, thus increasing bsp file size and wpoly.

Usage:
Convert any brushes, that are not parts of the basic structure of the map, to func_detail. They cannot be water brushes or sky brushes.
You can leave 'Detail level' to 1. For tiny objects, you might set it to 2, so that they won't chop the faces of other func_details.
For large shapes such as terrain and walls, you can set 'Lower its level to cut others' to no less than its detail level, so that they can chop adjacent world brushes like world brushes.
Before compiling the map, hide all entities and func_details, make sure there are no leaks and the structure is good enough for vis calculation.

Further explanations:
To add the feature of detail brushes, I introduced a concept called 'detail level', which is a number assigned to each brush, which can be 0, 1, 2, 3,... .
--I will refer to all brushes that have the same detail level as a 'layer':
All world brushes are in the layer of detail level 0.
All brushes in a func_detail go to the layer corresponding to the func_detail's 'detail level' which is default to 1.
Brushes in brush entities such as func_wall are not in consideration here, because they are in seperated entities.
--In the CSG process:
Every layer will not be affected by any more detailed layers (with only one exception).
Every layer will be chopped by all less detailed layers. That is, if a brush in this layer is embedded into less detailed layers, then the embedded part will be chopped off.
Brushes in the same layer always chop each other.
The exception is, if you want a brush from a more detailed layer to chop the faces of a brush from a less detailed layer, you can either set the former's 'Lower its level to cut others' or the latter's 'Raise its level to get cut' to no less than the difference of their detail level.
--In the BSP process:
First, the surfaces of the layer of detail level 0 split the space into large leafs, which are also portal leafs that are used in vis calculation.
And the layer of detail level 0 is not allowed to have leaks, so detail brushes cannot be used to 'seal' a map.
Then the surfaces the layer of detail level 1 split every leaf into smaller leafs, but they no longer act as portal leafs.
Then does layer of detail level 2, 3,... .
Note that number of visleafs reported in the bsp statistics chart is the number of final leafs generated by all layers.
--In the VIS process:
The visibility data is calculated only according to portal leafs generated by the layer of detail level 0.
So, func_details will not increase the time of VIS process significantly. But they may have some impact on the VIS process, because when the BSP program is processing the layer of detail level 0, it has to also try to optimize the total number of faces, nodes and leafs.
After the calculation, the vis data between portal leafs is then converted to the vis data between final leafs. So adding func_details will increase the total size of vis data.

Other notes:
The detail layers uses an advanced method to decide leafnode content, so detail brushes will not cause "Ambiguous leafnode contents" warnings and related problems.
Usually merely using detail level 0, 1 and 2 is enough. Using too many detail levels may make the BSP process inefficient and increase the bsp file size. For the same reason, 'Detail level of cliphulls' should always be 0 or 1 unless you are trying to solve some cliphull errors by adjusting this value.
Changing the 'Detail level of cliphulls' to 0 will reduce the number of clipnodes, but the cliphull of this func_detail will not use the new leafnode content method.

When CLIP texture is used together with normal textures, which is not allowd before this update, the brush will act like a CLIP brush (block players, don't block bullets, grenades or flashlight) while its faces remain visible.
Note that this brush will also not block light, unless it is tied to an entity with 'opaque' option on.
A typical usage is wire mesh. Create a thin brush with wire mesh texture, and texture the thin side faces with CLIP. Then convert the brush to a func_wall with appropriate properties. You don't need to convert it to func_illusionary.
This feature also makes it possible to let bullet pass through wire meshes which are parts of a moving entity.

Add 'SOLIDHINT' texture which can help create better BSP structure for terrain and other complicated shapes.
The BSP process is to use planes to split the entire space into convex leafs. On each split, every face which spans across the splitting plane must be cut into two fragments by the plane.
In most cases, hlbsp can find a good splitting plane for each split, such that only a few faces are cut.
However, for some complicated shaped surfaces such as terrain and another chimney-like object in the sample map, you may find out that their faces are cut into a lot of fragments, when you view the map in BSPviewer or type gl_wireframe command in game.
This is because hlbsp chooses splitting plane only from the planes of existing faces on the surface, and all faces that are not on the surface of the object are ignored.
In the case of terrain, you can see that the surface only contains the triangle slopes, so it's hard for hlbsp to choose a good splitting plane from these slopes.

SOLIDHINT makes it possibe to manually add extra faces for hlbsp to choose from, in order to help reduce face count and other counts.
For example, for the terrain created by 'Terrain Generator', the vertical planes on the grid lines cut no faces. So we can place SOLIDHINT faces along these planes.

There are two ways of adding SOLIDHINT faces:
1. Like how you add a HINT face, create a brush with SOLIDHINT texture on one face and SKIP texture on other faces. The face with SOLIDHINT texture will become a SOLIDHINT face.
or 2. Replace the the texture of an invisible face of a normal brush to SOLIDHINT. Then a SOLIDHINT face will be copied from that face.

The sample map uses the second way. In the sample map, a SOLIDHINT texture is applied to the shared face of two adjacent solid brushes. So it seems that the SOLIDHINT can "seperate" the two adjacent brushes and stop them from cutting each other.
If you want SOLIDHINT to "seperate" brushes that are part of func_details, make sure the SOLIDHINT is in the same detail level.

Differences between SOLIDHINT and HINT:
1. HINT always cause the space to be cut into more but smaller leafs and increase the size of bsp file, while SOLIDHINT can reduce the number of cuts and decrease the size of bsp file. Placing more SOLIDHINT than needed will usually cause no side effect, except longer compile time in hlbsp stage.
2. There is no need to place HINT inside solid brushes because the purpose of HINT is better vis, while SOLIDHINT faces can be inside solid brushes.

Add 'AllocBlock' amount report for '-chart'.
The main problem one may face while building large maps is the 'AllocBlock:full' error that occurs when the map is being loaded by the game engine.
This new feature can tell the mapper how close to 'AllocBlock:full' error a map is.

Change the condition of MAX_MAP_LEAFS warning.
Now this warning only appears if the number of visleafs (leafs formed from world brushes) exceeds 8192.
The bsp statistics chart can show the number of visleafs.
I'm sure that having more than 8192 leafs will not cause any problems as long as the number of visleafs does not exceed 8192.
I'm not sure whether having more than 8192 visleafs will make the game crush or cause any serious problem.

Increase the limit of different textures from 512 to 4096.
There are no evidence showing that 512 is an engine limit, and there seems to be no errors when I test a map with 2048 textures. So I decide to increase the limit.

Replace the 'wad.cfg' system with a new way of configuring wad list, because the old way is very buggy and hard to understand.
Now every wad config file only contains one set of wad files. The syntax is shown in the 'samplewadconfig.txt'.
If you have more than one configuration, you should put them in different wad config files.
To use a wad config file, you must add parameter '-wadcfgfile ' for hlcsg. The '' can either be a full path, or be the relative path from map folder or tools folder.
For example, the 'samplewadconfig.txt' is in the tools folder, so you can use '-wadcfgfie samplewadconfig.txt'.

Fix the issue of water brushes leaking light.
This only affects world brushes with liquid texture. This doesn't affect func_water.
Now the underwater area will be totally dark unless you add light sources. (As for light sources, turning the water texture into texture light is a good idea)

Fix the bug that the surface of func_water only emits texture light upwards and fails to emit texture light downwards.

Remove the old weird and buggy way how hlbsp deals with HINT texture.
Now HINT will probably work more efficiently than before.

All 'aaatrigger' texture will automatically become invisible.

Change hlrad's default '-gamma' from 0.5 to 0.55 and default '-texreflectgamma' from 2.5 to 2.2
These values are more suitable for Half-Life's default gamma value for lighting and texture and Windows's gamma value.

Change hlrad's default vismatrix method to sparse, because sparse is often a must for large maps.
The parameters for each vismatrix methods have been changed to '-vismatrix sparse', '-vismatrix normal' and '-vismatrix off'. (But you can still use the old '-sparse' or '-nomatrix')

Some other changes:
Fix the broken '-nullfile' parameter.
Opaque entities that are beyond sky brushes will not cast shadows.
Increase the limit of visibility data size.
The light_surface entity may automatically determine whether the texture light uses fast mode according to its brightness and the '-dlight' parameter.
Remove hlrad's '-maxlight' parameter because it is useless and a little uncompatible with dynamic light styles.
'-wadcfgfile', '-hullfile' and '-nullfile' will not require full path.

The tools are compiled by vs2010. So their sizes are much bigger and they may run 10% slower than the older versions.

Оригинал:
http://forums.svencoop.com/showpost...1&postcount=368

Зеркала:
http://design.cs-mapping.com.ua/dow...20vluzacn25.zip

http://design.cs-mapping.com.ua/downloads/samplemap.zip

Чанжлог переведеный с китайского (на английском).

__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!

FiEctro писал:
The tools are compiled by vs2010. So their sizes are much bigger and they may run 10% slower than the older versions.

По любому при 4 гигах оперативы и четырех ядрах не должно тормозить...

KiQ писал:
По любому при 4 гигах оперативы и четырех ядрах не должно тормозить...

XaeroX писал:
Так рождаются легенды о том, что новые компиляторы производят менее эффективный и быстрый код, чем старые...

underworlddemon писал:
а ты думаешь куча программистов пишущих код компиляторов просто так деньги получают ?

А эти компиляторы соотвтсвуют государственому качеству?

XaeroX писал:
Ты о чём?

Если мне не изменяет память, товарищ Тренсфер как-то давно при мне лазил с лупой по ассемблерному коду, генерируемому 6-й, 2005-й и 2008-й студиями. Новые студии генерируют гораздо более короткий код, чем старые, и распознают больше случаев для оптимизации. 2010-я студия если я правильно понял, и вовсе научилась генерировать инструкции SSE и SSE2 - по крайней мере какую-то опцию с этим связанную я в настройках проекта видел...

Больший же размер бинарников я думаю связан лишь с распуханием рантаймовой либы.

Government-Man писал:
Больший же размер бинарников я думаю связан лишь с распуханием рантаймовой либы.

__________________
"Злобным гениям не нужна харизма." © Shooter__Andy
"Making stuff for an "old ugly game" can be ten times more fun than grinding on a map for a dull, next-gen title." © Lunaran

Ну давайте рассуждать. Научилась студия юзать SSE/SSE2, юзверь радостно включил его в настройках, скомпилил - а потом прога запускается на процессоре без поддержки SSE2. Что делать? Хороший конпелятор в таких случаях делает две альтернативные ветки кода - с SSE и без SSE. Кода в два раза больше - вот вам и размер.

Scrama писал:
Со сборкой в дебаге/ не отключенном/не полностью отключенном дебагтрекинге в релизе.