Blood Wiki - User contributions [en]

Repository Reference/Introduction

2012-10-11T14:43:10Z

Twinchenzo:

{{navigation title|}}
{{grammar checked|darth}}
Blood Omnicide repository stores all files needed for the development process. It contains game files, media, sourcecodes, useful tools and other helpful stuff that makes life easier when working on various aspects of the game. Blood Omnicide repository stores project at its very latest development state and all previous versions.

Before you start working with Blood Omnicide repository, be sure to learn how version control systems works and particulary [http://en.wikipedia.org/wiki/Apache_Subversion subversion].

==Getting a working copy==
This is actually first step on work with Blood Omnicide repository - get a working copy of the repository.

Install SVN client (for Windows [http://tortoisesvn.net/ TortoiseSVN] is recommended). For executing '''svn checkout''' command you only need to get repository address, password is not required.
{{Important|Make sure path to working copy folder is nice and doesn't contain non-latin characters and whitespaces:}}
// Wrong
c:\Documents and Settings\Администратор\Desktop\Blood Omnicide Repository
// Correct
c:\OmnicideSVN

Downloading full working copy takes about 3GB of bandwidth. Downloaded working copy takes about 10GB, make sure you have at least double of that as it will grow up with time.
{{Tip|Download can be stopped and resumed at any time}}

==Looking around==
Once download is completed, you will see:

<div style="border: 1px #999 dotted; padding: 8px; margin: 4px;vertical-align:bottom">
{|
| [[File:Icon folder.png|16px|alt=|link=]]
| '''bin32'''
| game binaries for x86 platform
|-
| [[File:Icon folder.png|16px|alt=|link=]]
| '''bin64'''
| game binaries for x64 platform
|-
| [[File:Icon folder.png|16px|alt=|link=]]
| '''devkit'''
| game sourcecodes and tools
|-
| [[File:Icon folder.png|16px|alt=|link=]]
| '''kain'''
| gamedir storing all of Blood Omnicide files (textures, maps, scripts etc.)
|-
| [[File:Icon folder.png|16px|alt=|link=]]
| '''kain_make'''
| installation scripts and scripts to build release version of the game.
|-
| [[File:Icon folder.png|16px|alt=|link=]]
| '''mapeditor'''
| level editor
|-
| [[File:Icon folder.png|16px|alt=|link=]]
| '''misc'''
| help files, icons, map shots etc.
|-
| [[File:Icon file.png|16px|alt=|link=]]
| '''gpl.txt'''
| GNU GPL v2 license
|-
| [[File:Icon omnicide.png|16px|alt=|link=]]
| '''launch.exe'''
| Blood Omnicide launcher
|-
| [[File:Icon omnicide.png|16px|alt=|link=]]
| '''omnicide.exe'''
| Blood Omnicide game executable
|-
| [[File:Icon omnicide.png|16px|alt=|link=]]
| '''omnicide-dev.exe'''
| Blood Omnicide development-only executable (has raised entity limits)
|}
</div>

{{navigation footer|Key Concepts}}
{{finished}}

Repository Reference/Introduction

2012-10-11T14:42:41Z

Twinchenzo: /* Looking around */

{{navigation title|}}
{{grammar}}
Blood Omnicide repository stores all files needed for the development process. It contains game files, media, sourcecodes, useful tools and other helpful stuff that makes life easier when working on various aspects of the game. Blood Omnicide repository stores project at its very latest development state and all previous versions.

Before you start working with Blood Omnicide repository, be sure to learn how version control systems works and particulary [http://en.wikipedia.org/wiki/Apache_Subversion subversion].

==Getting a working copy==
This is actually first step on work with Blood Omnicide repository - get a working copy of the repository.

Install SVN client (for Windows [http://tortoisesvn.net/ TortoiseSVN] is recommended). For executing '''svn checkout''' command you only need to get repository address, password is not required.
{{Important|Make sure path to working copy folder is nice and doesn't contain non-latin characters and whitespaces:}}
// Wrong
c:\Documents and Settings\Администратор\Desktop\Blood Omnicide Repository
// Correct
c:\OmnicideSVN

Downloading full working copy takes about 3GB of bandwidth. Downloaded working copy takes about 10GB, make sure you have at least double of that as it will grow up with time.
{{Tip|Download can be stopped and resumed at any time}}

==Looking around==
Once download is completed, you will see:

<div style="border: 1px #999 dotted; padding: 8px; margin: 4px;vertical-align:bottom">
{|
| [[File:Icon folder.png|16px|alt=|link=]]
| '''bin32'''
| game binaries for x86 platform
|-
| [[File:Icon folder.png|16px|alt=|link=]]
| '''bin64'''
| game binaries for x64 platform
|-
| [[File:Icon folder.png|16px|alt=|link=]]
| '''devkit'''
| game sourcecodes and tools
|-
| [[File:Icon folder.png|16px|alt=|link=]]
| '''kain'''
| gamedir storing all of Blood Omnicide files (textures, maps, scripts etc.)
|-
| [[File:Icon folder.png|16px|alt=|link=]]
| '''kain_make'''
| installation scripts and scripts to build release version of the game.
|-
| [[File:Icon folder.png|16px|alt=|link=]]
| '''mapeditor'''
| level editor
|-
| [[File:Icon folder.png|16px|alt=|link=]]
| '''misc'''
| help files, icons, map shots etc.
|-
| [[File:Icon file.png|16px|alt=|link=]]
| '''gpl.txt'''
| GNU GPL v2 license
|-
| [[File:Icon omnicide.png|16px|alt=|link=]]
| '''launch.exe'''
| Blood Omnicide launcher
|-
| [[File:Icon omnicide.png|16px|alt=|link=]]
| '''omnicide.exe'''
| Blood Omnicide game executable
|-
| [[File:Icon omnicide.png|16px|alt=|link=]]
| '''omnicide-dev.exe'''
| Blood Omnicide development-only executable (has raised entity limits)
|}
</div>

{{navigation footer|Key Concepts}}
{{finished}}

Repository Reference/Introduction

2012-10-11T14:41:36Z

Twinchenzo:

{{navigation title|}}
{{grammar}}
Blood Omnicide repository stores all files needed for the development process. It contains game files, media, sourcecodes, useful tools and other helpful stuff that makes life easier when working on various aspects of the game. Blood Omnicide repository stores project at its very latest development state and all previous versions.

Before you start working with Blood Omnicide repository, be sure to learn how version control systems works and particulary [http://en.wikipedia.org/wiki/Apache_Subversion subversion].

==Getting a working copy==
This is actually first step on work with Blood Omnicide repository - get a working copy of the repository.

Install SVN client (for Windows [http://tortoisesvn.net/ TortoiseSVN] is recommended). For executing '''svn checkout''' command you only need to get repository address, password is not required.
{{Important|Make sure path to working copy folder is nice and doesn't contain non-latin characters and whitespaces:}}
// Wrong
c:\Documents and Settings\Администратор\Desktop\Blood Omnicide Repository
// Correct
c:\OmnicideSVN

Downloading full working copy takes about 3GB of bandwidth. Downloaded working copy takes about 10GB, make sure you have at least double of that as it will grow up with time.
{{Tip|Download can be stopped and resumed at any time}}

==Looking around==
Once download is completed, you will see:

<div style="border: 1px #999 dotted; padding: 8px; margin: 4px;vertical-align:bottom">
{|
| [[File:Icon folder.png|16px|alt=|link=]]
| '''bin32'''
| game binaries for x86 platform
|-
| [[File:Icon folder.png|16px|alt=|link=]]
| '''bin64'''
| game binaries for x64 platform
|-
| [[File:Icon folder.png|16px|alt=|link=]]
| '''devkit'''
| game sourcecodes and tools
|-
| [[File:Icon folder.png|16px|alt=|link=]]
| '''kain'''
| gamedir storing all of Blood Omnicide files (textures, maps, scripts etc.)
|-
| [[File:Icon folder.png|16px|alt=|link=]]
| '''kain_make'''
| installation scripts and scripts to build release version of the game.
|-
| [[File:Icon folder.png|16px|alt=|link=]]
| '''mapeditor'''
| level editor
|-
| [[File:Icon folder.png|16px|alt=|link=]]
| '''misc'''
| help files, icons, map shots etc.
|-
| [[File:Icon file.png|16px|alt=|link=]]
| '''gpl.txt'''
| GNU GPL v2 license
|-
| [[File:Icon omnicide.png|16px|alt=|link=]]
| '''launch.exe'''
| Blood Omnicide launcher
|-
| [[File:Icon omnicide.png|16px|alt=|link=]]
| '''omnicide.exe'''
| Blood Omnicide game executable
|-
| [[File:Icon omnicide.png|16px|alt=|link=]]
| '''omnicide-dev.exe'''
| Blood Omnicide development-only executable (have raised entity limits)
|}
</div>

{{navigation footer|Key Concepts}}
{{finished}}

Repository Reference/Key Concepts

2012-10-11T14:37:39Z

Twinchenzo:

{{navigation title|Introduction}}
{{grammar checked|darth}}
==Development vs Release==
Blood Omnicide release version is different from what you get in repository.

For development version:
* All files are real files (except for test installation)
* All textures are uncompressed, DDS cache is optional
* Sources and development files included
* SDK and tools included

In release version:
* All files packed into game archives
* Textures are compressed (DDS cache only)
* Source files and development files are deleted
* SDK in separate download

Release version for the game is about 800 Mb and has shorter loading times.

==Linked to Blood Omen==
By just downloading a working copy of repository you don't get a working game. Since Blood Omnicide is a port, it heavily depends on original game media files.

Blood Omen files got copied when Blood Omnicide release version is being installed on a computer. Development version doesn't have such installer, but it has a '''test installation script''' that does the same job. The process of getting a working copy of Blood Omnicide is called '''test installation'''.

==Sources are saved==
All media file sources get saved to SVN, including source files for tools, textures and models. The only reason a source file doesn't get saved is when its size is too big (>100Mb). Sources are saved in the same folder as the exported files. The code sources don't need a further explanation, but textures and models apparently do:

'''Texture sources'''
:Source is the base image (PSD or whatever) you are exporting to [[TGA]] texture.

'''Model sources'''
:These have a lot of variations. For static models it is best to save sources as [[ASE]] files, if models are animated, store whatever source file you have (MAX, blend etc.)

==Common conventions==
A number of rules that should be followed in order to keep repository clean.

'''Files names'''
:All files, folders, file extensions must be lowercase with all-latin characters and with no spacers. Failing this rule can throw a number of problems like limited portability and SVN errors.

'''Commits'''
:Dont commit files no one will use. SVN is not a light version of FTP. It stores all file versions, even if it was deleted. So abusing it with many unused files will waste HDD space.

{{navigation footer|Building a Game}}
{{finished}}

Repository Reference/Key Concepts

2012-10-11T14:36:53Z

Twinchenzo: /* Sources are saved */

{{navigation title|Introduction}}
{{grammar}}
==Development vs Release==
Blood Omnicide release version is different from what you get in repository.

For development version:
* All files are real files (except for test installation)
* All textures are uncompressed, DDS cache is optional
* Sources and development files included
* SDK and tools included

In release version:
* All files packed into game archives
* Textures are compressed (DDS cache only)
* Source files and development files are deleted
* SDK in separate download

Release version for the game is about 800 Mb and has shorter loading times.

==Linked to Blood Omen==
By just downloading a working copy of repository you don't get a working game. Since Blood Omnicide is a port, it heavily depends on original game media files.

Blood Omen files got copied when Blood Omnicide release version is being installed on a computer. Development version doesn't have such installer, but it has a '''test installation script''' that does the same job. The process of getting a working copy of Blood Omnicide is called '''test installation'''.

==Sources are saved==
All media file sources get saved to SVN, including source files for tools, textures and models. The only reason a source file doesn't get saved is when its size is too big (>100Mb). Sources are saved in the same folder as the exported files. The code sources don't need a further explanation, but textures and models apparently do:

'''Texture sources'''
:Source is the base image (PSD or whatever) you are exporting to [[TGA]] texture.

'''Model sources'''
:These have a lot of variations. For static models it is best to save sources as [[ASE]] files, if models are animated, store whatever source file you have (MAX, blend etc.)

==Common conventions==
A number of rules that should be followed in order to keep repository clean.

'''Files names'''
:All files, folders, file extensions must be lowercase with all-latin characters and with no spacers. Failing this rule can throw a number of problems like limited portability and SVN errors.

'''Commits'''
:Dont commit files no one will use. SVN is not a light version of FTP. It stores all file versions, even if it was deleted. So abusing it with many unused files will waste HDD space.

{{navigation footer|Building a Game}}
{{finished}}

Repository Reference/Key Concepts

2012-10-11T14:34:42Z

Twinchenzo: /* Linked to Blood Omen */

{{navigation title|Introduction}}
{{grammar}}
==Development vs Release==
Blood Omnicide release version is different from what you get in repository.

For development version:
* All files are real files (except for test installation)
* All textures are uncompressed, DDS cache is optional
* Sources and development files included
* SDK and tools included

In release version:
* All files packed into game archives
* Textures are compressed (DDS cache only)
* Source files and development files are deleted
* SDK in separate download

Release version for the game is about 800 Mb and has shorter loading times.

==Linked to Blood Omen==
By just downloading a working copy of repository you don't get a working game. Since Blood Omnicide is a port, it heavily depends on original game media files.

Blood Omen files got copied when Blood Omnicide release version is being installed on a computer. Development version doesn't have such installer, but it has a '''test installation script''' that does the same job. The process of getting a working copy of Blood Omnicide is called '''test installation'''.

==Sources are saved==
All media file sources get saved to SVN, including source files for tools, textures and models. The only reason some source file dont get saved, is when it's size are too big (>100Mb). Sources are saved in the same folder as their exported files. The code sources doesnt need an futher explanation, but textures and models apparently are:

'''Texture sources'''
:Source are the base image (PSD or whatever) you are exporting to [[TGA]] texture.

'''Model sources'''
:This have alot of variations. For static models it is best to save sources as [[ASE]] files, if models are animated, store whatever source file you have (MAX, blend etc.)

==Common conventions==
A number of rules that should be followed in order to keep repository clean.

'''Files names'''
:All files, folders, file extensions must be lowercase with all-latin characters and with no spacers. Failing this rule can throw a number of problems like limited portability and SVN errors.

'''Commits'''
:Dont commit files no one will use. SVN is not a light version of FTP. It stores all file versions, even if it was deleted. So abusing it with many unused files will waste HDD space.

{{navigation footer|Building a Game}}
{{finished}}

Repository Reference/Key Concepts

2012-10-11T14:32:38Z

Twinchenzo: /* Development vs Release */

{{navigation title|Introduction}}
{{grammar}}
==Development vs Release==
Blood Omnicide release version is different from what you get in repository.

For development version:
* All files are real files (except for test installation)
* All textures are uncompressed, DDS cache is optional
* Sources and development files included
* SDK and tools included

In release version:
* All files packed into game archives
* Textures are compressed (DDS cache only)
* Source files and development files are deleted
* SDK in separate download

Release version for the game is about 800 Mb and has shorter loading times.

==Linked to Blood Omen==
By just downloading a working copy of repository you dont get a working game. Since Blood Omnicide is a port, it heavily depends on original game media files.

Blood Omen files got copied when Blood Omnicide release version is being installed on a computer. Development version doesnt have such installer, but it have a '''test installation script''' that does the same job. The process of getting a working copy of Blood Omnicide is called '''test installation'''.

==Sources are saved==
All media file sources get saved to SVN, including source files for tools, textures and models. The only reason some source file dont get saved, is when it's size are too big (>100Mb). Sources are saved in the same folder as their exported files. The code sources doesnt need an futher explanation, but textures and models apparently are:

'''Texture sources'''
:Source are the base image (PSD or whatever) you are exporting to [[TGA]] texture.

'''Model sources'''
:This have alot of variations. For static models it is best to save sources as [[ASE]] files, if models are animated, store whatever source file you have (MAX, blend etc.)

==Common conventions==
A number of rules that should be followed in order to keep repository clean.

'''Files names'''
:All files, folders, file extensions must be lowercase with all-latin characters and with no spacers. Failing this rule can throw a number of problems like limited portability and SVN errors.

'''Commits'''
:Dont commit files no one will use. SVN is not a light version of FTP. It stores all file versions, even if it was deleted. So abusing it with many unused files will waste HDD space.

{{navigation footer|Building a Game}}
{{finished}}

Repository Reference/Automation scripts

2012-10-11T14:28:11Z

Twinchenzo:

{{navigation title|}}
{{grammar checked|darth}}
Blood Omnicide repository contains a number of automation scripts used to make life easier by making some repeated actions. [[Repository Reference/Building a Game|Building a game chapter]] is one of the big automation scripts you already know about. This appendix chapter lists other automation scripts.

==Materials automation==
Various scripts to help with materials, all scripts are located in '''kain/scripts/automation/'''

===Build terrain materials===
Terrain materials in Blood Omnicide are already generated using about 20 terrain textures (rock, grass, ground etc.) and all combinations of materials (rock-grass, grass-ground, grass-rock etc.).

All available terrain textures are listed in '''kain/scripts/terraintypes.txt'''

* '''make_terrain_pics.cmd''': generate radiant/textures for materials (you need ImageMagick 6.6.7 Q8 installed in C:\Program Files (x86)\ImageMagick-6.6.7-Q8)
* '''make_terrain_shaders.cmd''': generate terrain textures_terrain.shader

===Build shaderlist.txt===
File scripts/shaderlist.txt is used by map compiler and level editor to load .shader files. Whenever new material scripts are added, this file should be re-generated.

* '''make_shaderlist.cmd''': generate shaderlist.txt

===Build skip shaders===
Level editor is dumb, it doesn't know what a normalmap is. So it shows normalmaps, specular textures, and all other additional textures in the texture window, which is incorrect. To prevent that a special material file is made for level editor that flags all this textures as skipped. This script must be executed each time new normalmaps, specular and other additional textures are added.

* '''make_shaders_skip.cmd''': generate radiant/scripts/skip.shader

==Music automation==
Music automation scritps are created to help publishing new Bloody Sounds tracks. They are pretty simple. All scripts are located in '''kain\music\automation'''.

* '''make_files.bat''': make Bloody Sounds .mp3 files and ZIP containing all OGG files
* '''make_html.bat''': make HTML code for Bloody Sounds page (russian)
* '''make_html_en.bat''': make HTML code for Bloody Sounds page (english)

==Map automation==
There are many temporary files created during compilation. These files are: .prt, .srf, .autosave.map, .bad, .log, .pts.

'''kain/maps/cleanup.bat''': remove all temporary files

{{important|This script will remove all autosaves created for maps. Be careful!}}

{{navigation footer|}}
{{finished}}

Repository Reference/Automation scripts

2012-10-11T14:27:54Z

Twinchenzo: /* Map automation */

{{navigation title|}}
{{grammar}}
Blood Omnicide repository contains a number of automation scripts used to make life easier by making some repeated actions. [[Repository Reference/Building a Game|Building a game chapter]] is one of the big automation scripts you already know about. This appendix chapter lists other automation scripts.

==Materials automation==
Various scripts to help with materials, all scripts are located in '''kain/scripts/automation/'''

===Build terrain materials===
Terrain materials in Blood Omnicide are already generated using about 20 terrain textures (rock, grass, ground etc.) and all combinations of materials (rock-grass, grass-ground, grass-rock etc.).

All available terrain textures are listed in '''kain/scripts/terraintypes.txt'''

* '''make_terrain_pics.cmd''': generate radiant/textures for materials (you need ImageMagick 6.6.7 Q8 installed in C:\Program Files (x86)\ImageMagick-6.6.7-Q8)
* '''make_terrain_shaders.cmd''': generate terrain textures_terrain.shader

===Build shaderlist.txt===
File scripts/shaderlist.txt is used by map compiler and level editor to load .shader files. Whenever new material scripts are added, this file should be re-generated.

* '''make_shaderlist.cmd''': generate shaderlist.txt

===Build skip shaders===
Level editor is dumb, it doesn't know what a normalmap is. So it shows normalmaps, specular textures, and all other additional textures in the texture window, which is incorrect. To prevent that a special material file is made for level editor that flags all this textures as skipped. This script must be executed each time new normalmaps, specular and other additional textures are added.

* '''make_shaders_skip.cmd''': generate radiant/scripts/skip.shader

==Music automation==
Music automation scritps are created to help publishing new Bloody Sounds tracks. They are pretty simple. All scripts are located in '''kain\music\automation'''.

* '''make_files.bat''': make Bloody Sounds .mp3 files and ZIP containing all OGG files
* '''make_html.bat''': make HTML code for Bloody Sounds page (russian)
* '''make_html_en.bat''': make HTML code for Bloody Sounds page (english)

==Map automation==
There are many temporary files created during compilation. These files are: .prt, .srf, .autosave.map, .bad, .log, .pts.

'''kain/maps/cleanup.bat''': remove all temporary files

{{important|This script will remove all autosaves created for maps. Be careful!}}

{{navigation footer|}}
{{finished}}

Repository Reference/Automation scripts

2012-10-11T14:27:16Z

Twinchenzo: /* Music automation */

{{navigation title|}}
{{grammar}}
Blood Omnicide repository contains a number of automation scripts used to make life easier by making some repeated actions. [[Repository Reference/Building a Game|Building a game chapter]] is one of the big automation scripts you already know about. This appendix chapter lists other automation scripts.

==Materials automation==
Various scripts to help with materials, all scripts are located in '''kain/scripts/automation/'''

===Build terrain materials===
Terrain materials in Blood Omnicide are already generated using about 20 terrain textures (rock, grass, ground etc.) and all combinations of materials (rock-grass, grass-ground, grass-rock etc.).

All available terrain textures are listed in '''kain/scripts/terraintypes.txt'''

* '''make_terrain_pics.cmd''': generate radiant/textures for materials (you need ImageMagick 6.6.7 Q8 installed in C:\Program Files (x86)\ImageMagick-6.6.7-Q8)
* '''make_terrain_shaders.cmd''': generate terrain textures_terrain.shader

===Build shaderlist.txt===
File scripts/shaderlist.txt is used by map compiler and level editor to load .shader files. Whenever new material scripts are added, this file should be re-generated.

* '''make_shaderlist.cmd''': generate shaderlist.txt

===Build skip shaders===
Level editor is dumb, it doesn't know what a normalmap is. So it shows normalmaps, specular textures, and all other additional textures in the texture window, which is incorrect. To prevent that a special material file is made for level editor that flags all this textures as skipped. This script must be executed each time new normalmaps, specular and other additional textures are added.

* '''make_shaders_skip.cmd''': generate radiant/scripts/skip.shader

==Music automation==
Music automation scritps are created to help publishing new Bloody Sounds tracks. They are pretty simple. All scripts are located in '''kain\music\automation'''.

* '''make_files.bat''': make Bloody Sounds .mp3 files and ZIP containing all OGG files
* '''make_html.bat''': make HTML code for Bloody Sounds page (russian)
* '''make_html_en.bat''': make HTML code for Bloody Sounds page (english)

==Map automation==
There is many of temp files created during compilation. This files are: .prt, .srf, .autosave.map, .bad, .log, .pts.

'''kain/maps/cleanup.bat''': remove all temporary files

{{important|This script will remove all autosaves created for maps. Be careful!}}

{{navigation footer|}}
{{finished}}

Repository Reference/Automation scripts

2012-10-11T14:26:30Z

Twinchenzo: /* Build skip shaders */

{{navigation title|}}
{{grammar}}
Blood Omnicide repository contains a number of automation scripts used to make life easier by making some repeated actions. [[Repository Reference/Building a Game|Building a game chapter]] is one of the big automation scripts you already know about. This appendix chapter lists other automation scripts.

==Materials automation==
Various scripts to help with materials, all scripts are located in '''kain/scripts/automation/'''

===Build terrain materials===
Terrain materials in Blood Omnicide are already generated using about 20 terrain textures (rock, grass, ground etc.) and all combinations of materials (rock-grass, grass-ground, grass-rock etc.).

All available terrain textures are listed in '''kain/scripts/terraintypes.txt'''

* '''make_terrain_pics.cmd''': generate radiant/textures for materials (you need ImageMagick 6.6.7 Q8 installed in C:\Program Files (x86)\ImageMagick-6.6.7-Q8)
* '''make_terrain_shaders.cmd''': generate terrain textures_terrain.shader

===Build shaderlist.txt===
File scripts/shaderlist.txt is used by map compiler and level editor to load .shader files. Whenever new material scripts are added, this file should be re-generated.

* '''make_shaderlist.cmd''': generate shaderlist.txt

===Build skip shaders===
Level editor is dumb, it doesn't know what a normalmap is. So it shows normalmaps, specular textures, and all other additional textures in the texture window, which is incorrect. To prevent that a special material file is made for level editor that flags all this textures as skipped. This script must be executed each time new normalmaps, specular and other additional textures are added.

* '''make_shaders_skip.cmd''': generate radiant/scripts/skip.shader

==Music automation==
Music automation scritps is created to help with publishing new Bloody Sounds tracks. They are pretty simple. All scripts is located in '''kain\music\automation'''.

* '''make_files.bat''': make Bloody Sounds .mp3 files and ZIP containing all OGG files
* '''make_html.bat''': make HTML code for Bloody Sounds page (russian)
* '''make_html_en.bat''': make HTML code for Bloody Sounds page (english)

==Map automation==
There is many of temp files created during compilation. This files are: .prt, .srf, .autosave.map, .bad, .log, .pts.

'''kain/maps/cleanup.bat''': remove all temporary files

{{important|This script will remove all autosaves created for maps. Be careful!}}

{{navigation footer|}}
{{finished}}

Repository Reference/Automation scripts

2012-10-11T14:23:38Z

Twinchenzo: /* Build terrain materials */

{{navigation title|}}
{{grammar}}
Blood Omnicide repository contains a number of automation scripts used to make life easier by making some repeated actions. [[Repository Reference/Building a Game|Building a game chapter]] is one of the big automation scripts you already know about. This appendix chapter lists other automation scripts.

==Materials automation==
Various scripts to help with materials, all scripts are located in '''kain/scripts/automation/'''

===Build terrain materials===
Terrain materials in Blood Omnicide are already generated using about 20 terrain textures (rock, grass, ground etc.) and all combinations of materials (rock-grass, grass-ground, grass-rock etc.).

All available terrain textures are listed in '''kain/scripts/terraintypes.txt'''

* '''make_terrain_pics.cmd''': generate radiant/textures for materials (you need ImageMagick 6.6.7 Q8 installed in C:\Program Files (x86)\ImageMagick-6.6.7-Q8)
* '''make_terrain_shaders.cmd''': generate terrain textures_terrain.shader

===Build shaderlist.txt===
File scripts/shaderlist.txt is used by map compiler and level editor to load .shader files. Whenever new material scripts are added, this file should be re-generated.

* '''make_shaderlist.cmd''': generate shaderlist.txt

===Build skip shaders===
Level editor is dumb, it doesnt know what a normalmap is. So it shows normalmaps, specular textures, and all other additional textures in texture window. Which is incorrect. To prevent that a special material file is maked for level editor that flags all this textures as skipped. This script must be executed each time new normalmaps, specular and other additional textures get added.

* '''make_shaders_skip.cmd''': generate radiant/scripts/skip.shader

==Music automation==
Music automation scritps is created to help with publishing new Bloody Sounds tracks. They are pretty simple. All scripts is located in '''kain\music\automation'''.

* '''make_files.bat''': make Bloody Sounds .mp3 files and ZIP containing all OGG files
* '''make_html.bat''': make HTML code for Bloody Sounds page (russian)
* '''make_html_en.bat''': make HTML code for Bloody Sounds page (english)

==Map automation==
There is many of temp files created during compilation. This files are: .prt, .srf, .autosave.map, .bad, .log, .pts.

'''kain/maps/cleanup.bat''': remove all temporary files

{{important|This script will remove all autosaves created for maps. Be careful!}}

{{navigation footer|}}
{{finished}}

Repository Reference/Automation scripts

2012-10-11T14:23:18Z

Twinchenzo: /* Build shaderlist.txt */

{{navigation title|}}
{{grammar}}
Blood Omnicide repository contains a number of automation scripts used to make life easier by making some repeated actions. [[Repository Reference/Building a Game|Building a game chapter]] is one of the big automation scripts you already know about. This appendix chapter lists other automation scripts.

==Materials automation==
Various scripts to help with materials, all scripts are located in '''kain/scripts/automation/'''

===Build terrain materials===
Terrain materials in Blood Omnicide are already generated using about 20 terrain textures (rock, grass, ground etc.) and all combinations of materials (rock-grass, grass-ground, grass-rock etc.).

All available terrain textures are listed in '''kain/scripts/terraintypes.txt'''

* '''make_terrain_pics.cmd''': generates radiant/textures for materials (you need ImageMagick 6.6.7 Q8 installed in C:\Program Files (x86)\ImageMagick-6.6.7-Q8)
* '''make_terrain_shaders.cmd''': generates terrain textures_terrain.shader

===Build shaderlist.txt===
File scripts/shaderlist.txt is used by map compiler and level editor to load .shader files. Whenever new material scripts are added, this file should be re-generated.

* '''make_shaderlist.cmd''': generate shaderlist.txt

===Build skip shaders===
Level editor is dumb, it doesnt know what a normalmap is. So it shows normalmaps, specular textures, and all other additional textures in texture window. Which is incorrect. To prevent that a special material file is maked for level editor that flags all this textures as skipped. This script must be executed each time new normalmaps, specular and other additional textures get added.

* '''make_shaders_skip.cmd''': generate radiant/scripts/skip.shader

==Music automation==
Music automation scritps is created to help with publishing new Bloody Sounds tracks. They are pretty simple. All scripts is located in '''kain\music\automation'''.

* '''make_files.bat''': make Bloody Sounds .mp3 files and ZIP containing all OGG files
* '''make_html.bat''': make HTML code for Bloody Sounds page (russian)
* '''make_html_en.bat''': make HTML code for Bloody Sounds page (english)

==Map automation==
There is many of temp files created during compilation. This files are: .prt, .srf, .autosave.map, .bad, .log, .pts.

'''kain/maps/cleanup.bat''': remove all temporary files

{{important|This script will remove all autosaves created for maps. Be careful!}}

{{navigation footer|}}
{{finished}}

Repository Reference/Automation scripts

2012-10-11T14:22:26Z

Twinchenzo:

{{navigation title|}}
{{grammar}}
Blood Omnicide repository contains a number of automation scripts used to make life easier by making some repeated actions. [[Repository Reference/Building a Game|Building a game chapter]] is one of the big automation scripts you already know about. This appendix chapter lists other automation scripts.

==Materials automation==
Various scripts to help with materials, all scripts are located in '''kain/scripts/automation/'''

===Build terrain materials===
Terrain materials in Blood Omnicide are already generated using about 20 terrain textures (rock, grass, ground etc.) and all combinations of materials (rock-grass, grass-ground, grass-rock etc.).

All available terrain textures are listed in '''kain/scripts/terraintypes.txt'''

* '''make_terrain_pics.cmd''': generates radiant/textures for materials (you need ImageMagick 6.6.7 Q8 installed in C:\Program Files (x86)\ImageMagick-6.6.7-Q8)
* '''make_terrain_shaders.cmd''': generates terrain textures_terrain.shader

===Build shaderlist.txt===
File scripts/shaderlist.txt is used by map compiler and level editor to load .shader files. When new material scripts is added, this files should be re-generated.

* '''make_shaderlist.cmd''': generate shaderlist.txt

===Build skip shaders===
Level editor is dumb, it doesnt know what a normalmap is. So it shows normalmaps, specular textures, and all other additional textures in texture window. Which is incorrect. To prevent that a special material file is maked for level editor that flags all this textures as skipped. This script must be executed each time new normalmaps, specular and other additional textures get added.

* '''make_shaders_skip.cmd''': generate radiant/scripts/skip.shader

==Music automation==
Music automation scritps is created to help with publishing new Bloody Sounds tracks. They are pretty simple. All scripts is located in '''kain\music\automation'''.

* '''make_files.bat''': make Bloody Sounds .mp3 files and ZIP containing all OGG files
* '''make_html.bat''': make HTML code for Bloody Sounds page (russian)
* '''make_html_en.bat''': make HTML code for Bloody Sounds page (english)

==Map automation==
There is many of temp files created during compilation. This files are: .prt, .srf, .autosave.map, .bad, .log, .pts.

'''kain/maps/cleanup.bat''': remove all temporary files

{{important|This script will remove all autosaves created for maps. Be careful!}}

{{navigation footer|}}
{{finished}}

Brush

2012-10-10T10:52:20Z

Twinchenzo:

{{finished}}
[[File:Radiant brush.jpg|320px|right|thumb|Brush of the crypt entrance in NetRadiant]]

A brush is a basic building block in a level. It is used primarily to define the physical structure of the area being designed. The term "brush" originally was used by Radiant to refer to anything that is not an entity, and therefore also encompasses [[patch mesh|patch meshes]] (which is different from CSG brush in both construction and texturing).

A brush can be made to represent anything from solid matter (metal, dirt, wood, etc.) to liquids (lava, water, etc.) depending on the textures and materials applied to them.

Brush is constructive solid geometry (CSG). It uses a form made of its sides and a volume which is anyting inside. CSG brushes are presented in Unreal Engine (1/2/3), Torgue engine, Cryengine 3. Hammer (native editor for Source engine games) is using it too. CSG is popular because a modeler can use a set of relatively simple objects to create very complicated geometry. User can revise their complex geometry by changing the position of objects or by changing brush attributes.

== Shape ==

Properly constructed brush follows this rules:

* Has at least 3 sides
* Each side is plane forming polyhedron (maximum 16-24 corners)
* If sliced by the plane of any of its sides, the whole brush will be on one side of the plane

{{Important|If modifying brush shape, all these rules must be followed. Radiant have tools to move/transform brush vertexes, sides and planes. If you apply transformation that will lead to CSG rules breakage, resulting brush will become invalid. For most cases Radiant does not allow you to do that.}}

[[File:Brush rules.jpg|600px]]

== Texturing ==

Since brush internal structure doesn't have vertices, it is using special projection technique to get texture mapping:

# Texture gets projected from axis planes (XY, XZ, YZ) to the sides of the brush, optimal projection plane is selected by brush side orientation.
# Texture is rotated by plane's ''rotate'' parameter.
# Texture position is scaled by plane's ''stretch'' (x and y).
# Texture position is shifted by plane's ''offset'' (x and y).
# When using texture dimensions, positions are converted to texture coordinates.

This leads to a number of limitations applied for brushes:

* Rotating texture is tricky as no rotation origin is specified, this leads to texture breakage when brush is rotated to small angles (90 degrees rotation works fine).
* Texturing may break if texture resolution is changed (there is a material trick to bypass that).

Along with limitations, there is a number of benefits:

* No texture coordinates = no UVW unwrap work.
* A little easier to control [[texture detail]].
* No texture UV breakage when model is sliced/expanded.
* Can scale model with keeping original texture detail.
* Can modify brush in various ways with no texture breakage (make a wall longer for example).

== Volume ==

==== Brush contents ====

Physics-related contents of the brush. Could be one of the following:

* Solid
* Non-solid
* Water
* Slime
* Lava
* Sky

Brush contents are defined from the materials brush has on its sides. Usually all brush sides must have same contents (mixed contents will give a compiler warning and could lead to bugged behavior).

==== VIS transparency ====

This is not real transparency but any brush that does not provide structure/seal to a room, and merely is there to detail the room.

Detail brushes (Radiant feature) and [[BModel | bmodels]] are always 'transparent'.

Also if a brush have sides marked detailed or transparent, it will be forced transparent.

== Brush vs Patch mesh vs Triangle model ==

Brushes are essential when making:
* Geometry that requires a volume to function properly (water, triggers).
* Level hull structure (the geometry that forms [[VIS]] portal tree).
* Geometry used to connect rooms together.

Brushes are good when making:
* Simple detail objects used to cover corners and connect parts of level together.
* Semi-complex objects, which are derived version of some generic object (think house or other building) but with altered proportions/moved walls.
* Geometry that is more convenient to make with brushes (using it's features - CSG operators, projection texturing and ability to be edited in level editor).

For all other cases, [[patch mesh|patch meshes]] and triangle models are better and easier alternative to work with.

Some examples of good and bad usage of brushes:

{| cellspacing=0 cellpadding=2 border=1 style="width:100%;border-collapse:collapse"
| width=10% | Room floors
| width=10% | Good choice
| width=80% | Most of room floors are part of world hull. It is useful to edit them inside radiant. For physics floors have priority because gravity always make object to fall, so high mathematical precision of brushes will help with making physics more stable.
|-
| Walls
| Good choice
| Same as for the floor. Walls are part of map hull and when working with map, you ofter reconfigure your walls.
|-
| Statue
| Not a good choice
| Since complex models are broken into many brushes, it is hard to control texturing on them. Also texture projection is only capable of making simple UV. So you statue will be either crude or take insane amount of time to build with brushes.
|-
| Chair
| Not a good choice
| Same as for statue. Chair is too complex for brushes. It is easier to make it with misc_gamemodel.
|-
| Terrain
| May be good choice
| Small chunks of terrain are good to make with brushes, as they can be reconfigured in editor and don't require working with exporting/importing as for models. Brushes are also part of the .map file, so they don't generate any external files. Vertex alpha should be handled by colormod brushes. The big landscapes are not good to make with brushes, because big terrain takes 5000+ brushes and per-brush works is quite ineffective for it.
|-
| House
| May be good choice
| Since brush have projection texturing, its easy to move house walls/alter its height without texture breakage, which may be easy way to make villages. But house is a complex object, and making it with brushes may get hard and ineffective, depending on house design. So it's up to designer whether use brushes or triangle models for buildings.
|}

== See also ==
* [[Radiant/Glossary|Radiant glossary]]
* [[BModel]]
* [[BSP]]

[[Category:Glossary]]
{{grammar checked|darth}}
__NOTOC__

Brush

2012-10-10T10:51:27Z

Twinchenzo: /* Brush vs Patch mesh vs Triangle model */

Brush

2012-10-10T10:21:05Z

Twinchenzo: /* VIS transparency */

{{finished}}
[[File:Radiant brush.jpg|320px|right|thumb|Brush of the crypt entrance in NetRadiant]]

A brush is a basic building block in a level. It is used primarily to define the physical structure of the area being designed. The term "brush" originally was used by Radiant to refer to anything that is not an entity, and therefore also encompasses [[patch mesh|patch meshes]] (which is different from CSG brush in both construction and texturing).

A brush can be made to represent anything from solid matter (metal, dirt, wood, etc.) to liquids (lava, water, etc.) depending on the textures and materials applied to them.

Brush is constructive solid geometry (CSG). It uses a form made of its sides and a volume which is anyting inside. CSG brushes are presented in Unreal Engine (1/2/3), Torgue engine, Cryengine 3. Hammer (native editor for Source engine games) is using it too. CSG is popular because a modeler can use a set of relatively simple objects to create very complicated geometry. User can revise their complex geometry by changing the position of objects or by changing brush attributes.

=== Shape ===

Properly constructed brush follows this rules:

* Has at least 3 sides
* Each side is plane forming polyhedron (maximum 16-24 corners)
* If sliced by the plane of any of its sides, the whole brush will be on one side of the plane

{{Important|If modifying brush shape, all these rules must be followed. Radiant have tools to move/transform brush vertexes, sides and planes. If you apply transformation that will lead to CSG rules breakage, resulting brush will become invalid. For most cases Radiant does not allow you to do that.}}

[[File:Brush rules.jpg|600px]]

=== Texturing ===

Since brush internal structure doesn't have vertices, it is using special projection technique to get texture mapping:

# Texture gets projected from axis planes (XY, XZ, YZ) to the sides of the brush, optimal projection plane is selected by brush side orientation.
# Texture is rotated by plane's ''rotate'' parameter.
# Texture position is scaled by plane's ''stretch'' (x and y).
# Texture position is shifted by plane's ''offset'' (x and y).
# When using texture dimensions, positions are converted to texture coordinates.

This leads to a number of limitations applied for brushes:

* Rotating texture is tricky as no rotation origin is specified, this leads to texture breakage when brush is rotated to small angles (90 degrees rotation works fine).
* Texturing may brake if texture resolution is changed (there is a material trick to bypass that).

Along with limitations, there is a number of benefits:

* No texture coordinates = no UVW unwrap work.
* A little easier to control [[texture detail]].
* No texture UV breakage when model is sliced/expanded.
* Can scale model with keeping original texture detail.
* Can modify brush in various ways with no texture breakage (make a wall longer for example).

=== Volume ===

==== Brush contents ====

Physics-related contents of the brush. Could be one of the following:

* Solid
* Non-solid
* Water
* Slime
* Lava
* Sky

Brush contents are defined from the materials brush has on its sides. Usually all brush sides must have same contents (mixed contents will give a compiler warning and could lead to bugged behavior).

==== VIS transparency ====

This is not real transparency but any brush that does not provide structure/seal to a room, and merely is there to detail the room.

Detail brushes (Radiant feature) and [[BModel | bmodels]] are always 'transparent'.

Also if a brush have sides marked detailed or transparent, it will be forced transparent.

=== Brush vs Patch mesh vs Triangle model ===

Brushes are essential things to make:
* Geometry that requires a volume to function properly (water, triggers)
* Level hull structure (the geometry that forms [[VIS]] portal tree)
* Geometry used to connect rooms together.

Brushes are good things to make:
* Simple detail objects used to cover corners and connect parts of level together
* Semi-complex objects, which are derived version of some generic object (think house or other building) but with altered proportions/moved walls.
* Geometry that is more convenient to make with brushes (using it's features - CSG operators, projection texturing and ability to be edited in level editor)

For all other cases, [[patch mesh|patch meshes]] and triangle models are better and more easier alternative to work with.

Some examples of good and bad usage of brushes:

{| cellspacing=0 cellpadding=2 border=1 style="width:100%;border-collapse:collapse"
| width=10% | Room floors
| width=10% | Good choice
| width=80% | Most of room floors are part of world hull. It is useful to edit them inside radiant. For physics floors have priority because gravity always make object to fall, so high mathematical precision of brushes will help with making physics more stable.
|-
| Walls
| Good choice
| Same as for the floor. Walls are part of map hull and when working with map, you are ofter reconfiguring your walls.
|-
| Statue
| Not a good choice
| Since complex models are broken into many brushes, it is hard to control texturing on them. Also texture projection is only capable of making simple UV. So you statue withg be either crude or will take insane abount of time to build with brushes.
|-
| Chair
| Not a good choice
| Same as for statue. Chair is too complex for brushes. It is easier to make it with misc_gamemodel.
|-
| Terrain
| may be good choice
| Small chunks of terrain is good to make with brushes, as they can be reconfigured in editor and dont need a works with exporting/importing as for models. Brushes also part of the .map file, so it dont generates any external files. Vertex alpha should be handled by colormod brushes. The big landscapes is not good to make with brushes, because big terrain takes 5000+ brushes and per-brush works is quite uneffective for it.
|-
| House
| may be good choice
| Since brush have projection texturing, its easy to move house walls/alter it's height without texture breakage, which may be easy way to make villages. But house is complex object, and making it with brushes may get hard and uneffective, depending on house design. So it's up to designer whether use brushes or triangle models for buildings.
|}

== See also ==
* [[Radiant Glossary]]
* [[BModel]]
* [[BSP]]

[[Category:Glossary]]
{{grammar}}
__NOTOC__

Brush

2012-10-10T09:59:30Z

Twinchenzo: /* Brush contents */

{{finished}}
[[File:Radiant brush.jpg|320px|right|thumb|Brush of the crypt entrance in NetRadiant]]

A brush is a basic building block in a level. It is used primarily to define the physical structure of the area being designed. The term "brush" originally was used by Radiant to refer to anything that is not an entity, and therefore also encompasses [[patch mesh|patch meshes]] (which is different from CSG brush in both construction and texturing).

A brush can be made to represent anything from solid matter (metal, dirt, wood, etc.) to liquids (lava, water, etc.) depending on the textures and materials applied to them.

Brush is constructive solid geometry (CSG). It uses a form made of its sides and a volume which is anyting inside. CSG brushes are presented in Unreal Engine (1/2/3), Torgue engine, Cryengine 3. Hammer (native editor for Source engine games) is using it too. CSG is popular because a modeler can use a set of relatively simple objects to create very complicated geometry. User can revise their complex geometry by changing the position of objects or by changing brush attributes.

=== Shape ===

Properly constructed brush follows this rules:

* Has at least 3 sides
* Each side is plane forming polyhedron (maximum 16-24 corners)
* If sliced by the plane of any of its sides, the whole brush will be on one side of the plane

{{Important|If modifying brush shape, all these rules must be followed. Radiant have tools to move/transform brush vertexes, sides and planes. If you apply transformation that will lead to CSG rules breakage, resulting brush will become invalid. For most cases Radiant does not allow you to do that.}}

[[File:Brush rules.jpg|600px]]

=== Texturing ===

Since brush internal structure doesn't have vertices, it is using special projection technique to get texture mapping:

# Texture gets projected from axis planes (XY, XZ, YZ) to the sides of the brush, optimal projection plane is selected by brush side orientation.
# Texture is rotated by plane's ''rotate'' parameter.
# Texture position is scaled by plane's ''stretch'' (x and y).
# Texture position is shifted by plane's ''offset'' (x and y).
# When using texture dimensions, positions are converted to texture coordinates.

This leads to a number of limitations applied for brushes:

* Rotating texture is tricky as no rotation origin is specified, this leads to texture breakage when brush is rotated to small angles (90 degrees rotation works fine).
* Texturing may brake if texture resolution is changed (there is a material trick to bypass that).

Along with limitations, there is a number of benefits:

* No texture coordinates = no UVW unwrap work.
* A little easier to control [[texture detail]].
* No texture UV breakage when model is sliced/expanded.
* Can scale model with keeping original texture detail.
* Can modify brush in various ways with no texture breakage (make a wall longer for example).

=== Volume ===

==== Brush contents ====

Physics-related contents of the brush. Could be one of the following:

* Solid
* Non-solid
* Water
* Slime
* Lava
* Sky

Brush contents are defined from the materials brush has on its sides. Usually all brush sides must have same contents (mixed contents will give a compiler warning and could lead to bugged behavior).

==== VIS transparency ====

This is not real transparency but any brush that does not provide structure/seal to a room, and merely is there to detail the room.

Detail brushes (Radiant feature) and [[BModel | bmodels]] are always 'transparent'.

Also if brush have sides which is marked detailed or transparent, it will be forced transparent.

=== Usage ===

Brushes are essential thing to make geometry that requires a volume to function properly (water, triggers), level hull structure (the geometry that forms [[VIS]] portal tree) and grude procedural geometry which is used to connect rooms together. It can also be used to create semi-complex geometry on detail objects. For quite complex and small objects, [[patch mesh|patch meshes]] and triangle models are better and more easier to make.

Examples of usage:

{| cellspacing=0 cellpadding=2 style="width:100%"
| width=5% align=right | Room floors
| width=10% | Good choice
| width=85% | Most of room floors are part of world hull. It is useful to edit them inside radiant. For physics floors have priority because gravity always make object to fall, so high mathematical precision of brushes will help with making physics more stable.
|-
| align=right | Walls:
| Good choice
| Description is pretty same as for the floor. Walls are part of map hull and when working with map, you are ofter reconfiguring your walls.
|-
| align=right | Statue:
| Not a good choice
| Since complex models are broken into many brushes, it is hard to control texturing on them. Also texture projection is only capable of making simple UV. So you statue withg be either crude or will take insane abount of time to build with brushes.
|-
| align=right | Chair:
| Not a good choice
| Actually its pretty same as for statue. Chair is too complex for brushes, and also it's pretty stock at its form. So its easier to make it with misc_gamemodel.
|-
| align=right | Terrain:
| may be good choice
| Small chunks of terrain is good to make with brushes, as they can be reconfigured in editor and dont need a works with exporting/importing as for models. Brushes also part of the .map file, so it dont generates any external files. Vertex alpha should be handled by colormod brushes. The big landscapes is not good to make with brushes, because big terrain takes 5000+ brushes and per-brush works is quite uneffective for it.
|}

== See also ==
* [[Radiant Glossary]]
* [[BModel]]
* [[BSP]]

[[Category:Glossary]]
{{grammar}}
__NOTOC__

Brush

2012-10-10T09:56:38Z

Twinchenzo: /* Texturing */

{{finished}}
[[File:Radiant brush.jpg|320px|right|thumb|Brush of the crypt entrance in NetRadiant]]

A brush is a basic building block in a level. It is used primarily to define the physical structure of the area being designed. The term "brush" originally was used by Radiant to refer to anything that is not an entity, and therefore also encompasses [[patch mesh|patch meshes]] (which is different from CSG brush in both construction and texturing).

A brush can be made to represent anything from solid matter (metal, dirt, wood, etc.) to liquids (lava, water, etc.) depending on the textures and materials applied to them.

Brush is constructive solid geometry (CSG). It uses a form made of its sides and a volume which is anyting inside. CSG brushes are presented in Unreal Engine (1/2/3), Torgue engine, Cryengine 3. Hammer (native editor for Source engine games) is using it too. CSG is popular because a modeler can use a set of relatively simple objects to create very complicated geometry. User can revise their complex geometry by changing the position of objects or by changing brush attributes.

=== Shape ===

Properly constructed brush follows this rules:

* Has at least 3 sides
* Each side is plane forming polyhedron (maximum 16-24 corners)
* If sliced by the plane of any of its sides, the whole brush will be on one side of the plane

{{Important|If modifying brush shape, all these rules must be followed. Radiant have tools to move/transform brush vertexes, sides and planes. If you apply transformation that will lead to CSG rules breakage, resulting brush will become invalid. For most cases Radiant does not allow you to do that.}}

[[File:Brush rules.jpg|600px]]

=== Texturing ===

Since brush internal structure doesn't have vertices, it is using special projection technique to get texture mapping:

# Texture gets projected from axis planes (XY, XZ, YZ) to the sides of the brush, optimal projection plane is selected by brush side orientation.
# Texture is rotated by plane's ''rotate'' parameter.
# Texture position is scaled by plane's ''stretch'' (x and y).
# Texture position is shifted by plane's ''offset'' (x and y).
# When using texture dimensions, positions are converted to texture coordinates.

This leads to a number of limitations applied for brushes:

* Rotating texture is tricky as no rotation origin is specified, this leads to texture breakage when brush is rotated to small angles (90 degrees rotation works fine).
* Texturing may brake if texture resolution is changed (there is a material trick to bypass that).

Along with limitations, there is a number of benefits:

* No texture coordinates = no UVW unwrap work.
* A little easier to control [[texture detail]].
* No texture UV breakage when model is sliced/expanded.
* Can scale model with keeping original texture detail.
* Can modify brush in various ways with no texture breakage (make a wall longer for example).

=== Volume ===

==== Brush contents ====

Physics-related contents of the brush. Could be one of the followed:

* Solid
* Non-solid
* Water
* Slime
* Lava
* Sky

Brush contents are defined from the materials brush have on it's sides. Usually all brush sides must have same contents (mixed contents will give a compiler warning and could lead to bugged behavior).

==== VIS transparency ====

This is not real transparency but any brush that does not provide structure/seal to a room, and merely is there to detail the room.

Detail brushes (Radiant feature) and [[BModel | bmodels]] are always 'transparent'.

Also if brush have sides which is marked detailed or transparent, it will be forced transparent.

=== Usage ===

Brushes are essential thing to make geometry that requires a volume to function properly (water, triggers), level hull structure (the geometry that forms [[VIS]] portal tree) and grude procedural geometry which is used to connect rooms together. It can also be used to create semi-complex geometry on detail objects. For quite complex and small objects, [[patch mesh|patch meshes]] and triangle models are better and more easier to make.

Examples of usage:

{| cellspacing=0 cellpadding=2 style="width:100%"
| width=5% align=right | Room floors
| width=10% | Good choice
| width=85% | Most of room floors are part of world hull. It is useful to edit them inside radiant. For physics floors have priority because gravity always make object to fall, so high mathematical precision of brushes will help with making physics more stable.
|-
| align=right | Walls:
| Good choice
| Description is pretty same as for the floor. Walls are part of map hull and when working with map, you are ofter reconfiguring your walls.
|-
| align=right | Statue:
| Not a good choice
| Since complex models are broken into many brushes, it is hard to control texturing on them. Also texture projection is only capable of making simple UV. So you statue withg be either crude or will take insane abount of time to build with brushes.
|-
| align=right | Chair:
| Not a good choice
| Actually its pretty same as for statue. Chair is too complex for brushes, and also it's pretty stock at its form. So its easier to make it with misc_gamemodel.
|-
| align=right | Terrain:
| may be good choice
| Small chunks of terrain is good to make with brushes, as they can be reconfigured in editor and dont need a works with exporting/importing as for models. Brushes also part of the .map file, so it dont generates any external files. Vertex alpha should be handled by colormod brushes. The big landscapes is not good to make with brushes, because big terrain takes 5000+ brushes and per-brush works is quite uneffective for it.
|}

== See also ==
* [[Radiant Glossary]]
* [[BModel]]
* [[BSP]]

[[Category:Glossary]]
{{grammar}}
__NOTOC__

Brush

2012-10-10T09:51:40Z

Twinchenzo:

{{finished}}
[[File:Radiant brush.jpg|320px|right|thumb|Brush of the crypt entrance in NetRadiant]]

A brush is a basic building block in a level. It is used primarily to define the physical structure of the area being designed. The term "brush" originally was used by Radiant to refer to anything that is not an entity, and therefore also encompasses [[patch mesh|patch meshes]] (which is different from CSG brush in both construction and texturing).

A brush can be made to represent anything from solid matter (metal, dirt, wood, etc.) to liquids (lava, water, etc.) depending on the textures and materials applied to them.

Brush is constructive solid geometry (CSG). It uses a form made of its sides and a volume which is anyting inside. CSG brushes are presented in Unreal Engine (1/2/3), Torgue engine, Cryengine 3. Hammer (native editor for Source engine games) is using it too. CSG is popular because a modeler can use a set of relatively simple objects to create very complicated geometry. User can revise their complex geometry by changing the position of objects or by changing brush attributes.

=== Shape ===

Properly constructed brush follows this rules:

* Has at least 3 sides
* Each side is plane forming polyhedron (maximum 16-24 corners)
* If sliced by the plane of any of its sides, the whole brush will be on one side of the plane

{{Important|If modifying brush shape, all these rules must be followed. Radiant have tools to move/transform brush vertexes, sides and planes. If you apply transformation that will lead to CSG rules breakage, resulting brush will become invalid. For most cases Radiant does not allow you to do that.}}

[[File:Brush rules.jpg|600px]]

=== Texturing ===

Since brush internal structure doesn't have vertices, it is using special projection technique to get texture mapping:

# Texture get projected from axis planes (XY, XZ, YZ) to the sides of the brush, optimal projection plane is selected by brush side orientation.
# Texture is rotated by plane's ''rotate'' parameter.
# Texture position is scaled by plane's ''stretch'' (x and y).
# Texture position is shifted by plane's ''offset'' (x and y).
# When using texture dimensions, positions are converted to texture coordinates.

This leads to a number of limitations applied for brushes:

* Rotating texture is tricky as no rotation origin is specified, this leads to texture breakage when brush is rotated to small angles (90 degrees rotation work fine)
* Texturing may brake if texture resolution is changed (there is a material trick to bypass that)

Along with limitations, there is a number of benefits:

* No texture coordinates = no UVW unwrap work.
* A little easier to control [[texture detail]].
* No texture UV breakage when model is sliced/expanded.
* Can scale model with keeping original texture detail.
* Can modify brush in various ways with no texture breakage (make wall longer for example).

=== Volume ===

==== Brush contents ====

Physics-related contents of the brush. Could be one of the followed:

* Solid
* Non-solid
* Water
* Slime
* Lava
* Sky

Brush contents are defined from the materials brush have on it's sides. Usually all brush sides must have same contents (mixed contents will give a compiler warning and could lead to bugged behavior).

==== VIS transparency ====

This is not real transparency but any brush that does not provide structure/seal to a room, and merely is there to detail the room.

Detail brushes (Radiant feature) and [[BModel | bmodels]] are always 'transparent'.

Also if brush have sides which is marked detailed or transparent, it will be forced transparent.

=== Usage ===

Brushes are essential thing to make geometry that requires a volume to function properly (water, triggers), level hull structure (the geometry that forms [[VIS]] portal tree) and grude procedural geometry which is used to connect rooms together. It can also be used to create semi-complex geometry on detail objects. For quite complex and small objects, [[patch mesh|patch meshes]] and triangle models are better and more easier to make.

Examples of usage:

{| cellspacing=0 cellpadding=2 style="width:100%"
| width=5% align=right | Room floors
| width=10% | Good choice
| width=85% | Most of room floors are part of world hull. It is useful to edit them inside radiant. For physics floors have priority because gravity always make object to fall, so high mathematical precision of brushes will help with making physics more stable.
|-
| align=right | Walls:
| Good choice
| Description is pretty same as for the floor. Walls are part of map hull and when working with map, you are ofter reconfiguring your walls.
|-
| align=right | Statue:
| Not a good choice
| Since complex models are broken into many brushes, it is hard to control texturing on them. Also texture projection is only capable of making simple UV. So you statue withg be either crude or will take insane abount of time to build with brushes.
|-
| align=right | Chair:
| Not a good choice
| Actually its pretty same as for statue. Chair is too complex for brushes, and also it's pretty stock at its form. So its easier to make it with misc_gamemodel.
|-
| align=right | Terrain:
| may be good choice
| Small chunks of terrain is good to make with brushes, as they can be reconfigured in editor and dont need a works with exporting/importing as for models. Brushes also part of the .map file, so it dont generates any external files. Vertex alpha should be handled by colormod brushes. The big landscapes is not good to make with brushes, because big terrain takes 5000+ brushes and per-brush works is quite uneffective for it.
|}

== See also ==
* [[Radiant Glossary]]
* [[BModel]]
* [[BSP]]

[[Category:Glossary]]
{{grammar}}
__NOTOC__

VIS

2012-10-08T14:09:43Z

Twinchenzo:

{{need screenshot}}
{{grammar checked|darth}}
VIS (stands for ''visibility'') - name of a map compilation phase during which and data is created and used for visibility checking. VIS can be estimated as a group of areas called portals with each portal having a link to all other postals visible from it. If entity standing in a portal that is visible from a portal of current eye position, it will get drawn.

===Building VIS===
VIS portals are created during BSP stage, links are established during VIS stage.

Structural brushes will define a shape for portals to fill. This process sometimes is called 'breaking VIS' because by nature it is breaking space for visible and not visible zones. All entities (including [[BModel|bmodels]]]) are meant to be changed/removed at any time, so they are always excluded from portals creation. The only entity that breaks VIS is [[func_group]].

====Leak====
VIS requires the map to be internally sealed so it can distinguish what part of the map is inside and what is outside. When some inner part of the map is connected with void, the map is leaked. When a leak occurs, the tools cannot know which part of the level is inside, and which part is outside, and portals cannot have visibility data generated.
Most notable mistakes leading to leak:
* Small gaps between brushes leading to a void
* Detail brushes and entities being used as structural walls (they are not blocking VIS)
* Entities placed outside of the map hull
When map compiler detects a leak, it will stop making portals and cast an error. Map editor will show the spot where leak was occured.
{{tip|Map compiler is using entities to determine what map part is inside. If your map have no entities, compiler will cast a leak error because it cannot decide what part of the map is inside.}}

===Optimizing VIS===
It is important that portal tree is balanced. It should be detailed enough to make accurate culling, and it should be small enough to have less RAM overhead and small processing time (VIS helps to save some processing time, it should not be allowed to take that time for its own processing). Optimizing portals is one of tasks map designer should care of:
* Mark small brushes that should not break VIS as detail (Detail brushes are opposed to Structural)
* Place hint brushes that will make additional portals for more accurate culling

== Console variables ==
{{cvar|r_lockvisibility|disables visibility updates so you can walk around and inspect what is visible from locked position.}}
{{cvar|r_drawportals|draw portal surfaces in different colors.}}
{{cvar|r_novis|Disable visibility info (whole level will be drawn).}}
{{cvar|r_useportalculling|Improve framerate of r_novis by using portal culling. Still not as good as precompiled visibility data, but it is helpful on complex maps. A value of 2 will force portal culling even if VIS data is presented, which improves framerate on maps without too much complexity but hurts on complex maps.}}

==Tutorials==
* [[Tutorials:Understanding a VIS and Hint brushes|Understanding a VIS and Hint brushes]]

==See also==
* [[PVS|Potentially visible set]]

__NOTOC__
[[Category:Glossary]]
[[Category:Darkplaces engine]]
{{finished}}

VIS

2012-10-08T14:09:31Z

Twinchenzo:

{{need screenshot}}
{{grammar checked|darth}}
VIS (stands for *visibility*) - name of a map compilation phase during which and data is created and used for visibility checking. VIS can be estimated as a group of areas called portals with each portal having a link to all other postals visible from it. If entity standing in a portal that is visible from a portal of current eye position, it will get drawn.

===Building VIS===
VIS portals are created during BSP stage, links are established during VIS stage.

Structural brushes will define a shape for portals to fill. This process sometimes is called 'breaking VIS' because by nature it is breaking space for visible and not visible zones. All entities (including [[BModel|bmodels]]]) are meant to be changed/removed at any time, so they are always excluded from portals creation. The only entity that breaks VIS is [[func_group]].

====Leak====
VIS requires the map to be internally sealed so it can distinguish what part of the map is inside and what is outside. When some inner part of the map is connected with void, the map is leaked. When a leak occurs, the tools cannot know which part of the level is inside, and which part is outside, and portals cannot have visibility data generated.
Most notable mistakes leading to leak:
* Small gaps between brushes leading to a void
* Detail brushes and entities being used as structural walls (they are not blocking VIS)
* Entities placed outside of the map hull
When map compiler detects a leak, it will stop making portals and cast an error. Map editor will show the spot where leak was occured.
{{tip|Map compiler is using entities to determine what map part is inside. If your map have no entities, compiler will cast a leak error because it cannot decide what part of the map is inside.}}

===Optimizing VIS===
It is important that portal tree is balanced. It should be detailed enough to make accurate culling, and it should be small enough to have less RAM overhead and small processing time (VIS helps to save some processing time, it should not be allowed to take that time for its own processing). Optimizing portals is one of tasks map designer should care of:
* Mark small brushes that should not break VIS as detail (Detail brushes are opposed to Structural)
* Place hint brushes that will make additional portals for more accurate culling

== Console variables ==
{{cvar|r_lockvisibility|disables visibility updates so you can walk around and inspect what is visible from locked position.}}
{{cvar|r_drawportals|draw portal surfaces in different colors.}}
{{cvar|r_novis|Disable visibility info (whole level will be drawn).}}
{{cvar|r_useportalculling|Improve framerate of r_novis by using portal culling. Still not as good as precompiled visibility data, but it is helpful on complex maps. A value of 2 will force portal culling even if VIS data is presented, which improves framerate on maps without too much complexity but hurts on complex maps.}}

==Tutorials==
* [[Tutorials:Understanding a VIS and Hint brushes|Understanding a VIS and Hint brushes]]

==See also==
* [[PVS|Potentially visible set]]

__NOTOC__
[[Category:Glossary]]
[[Category:Darkplaces engine]]
{{finished}}

VIS

2012-10-08T14:09:11Z

Twinchenzo:

{{need screenshot}}
{{grammar checked|darth}}
VIS (stands for visibility) - name of a map compilation phase during which and data is created and used for visibility checking. VIS can be estimated as a group of areas called portals with each portal having a link to all other postals visible from it. If entity standing in a portal that is visible from a portal of current eye position, it will get drawn.

===Building VIS===
VIS portals are created during BSP stage, links are established during VIS stage.

Structural brushes will define a shape for portals to fill. This process sometimes is called 'breaking VIS' because by nature it is breaking space for visible and not visible zones. All entities (including [[BModel|bmodels]]]) are meant to be changed/removed at any time, so they are always excluded from portals creation. The only entity that breaks VIS is [[func_group]].

====Leak====
VIS requires the map to be internally sealed so it can distinguish what part of the map is inside and what is outside. When some inner part of the map is connected with void, the map is leaked. When a leak occurs, the tools cannot know which part of the level is inside, and which part is outside, and portals cannot have visibility data generated.
Most notable mistakes leading to leak:
* Small gaps between brushes leading to a void
* Detail brushes and entities being used as structural walls (they are not blocking VIS)
* Entities placed outside of the map hull
When map compiler detects a leak, it will stop making portals and cast an error. Map editor will show the spot where leak was occured.
{{tip|Map compiler is using entities to determine what map part is inside. If your map have no entities, compiler will cast a leak error because it cannot decide what part of the map is inside.}}

===Optimizing VIS===
It is important that portal tree is balanced. It should be detailed enough to make accurate culling, and it should be small enough to have less RAM overhead and small processing time (VIS helps to save some processing time, it should not be allowed to take that time for its own processing). Optimizing portals is one of tasks map designer should care of:
* Mark small brushes that should not break VIS as detail (Detail brushes are opposed to Structural)
* Place hint brushes that will make additional portals for more accurate culling

== Console variables ==
{{cvar|r_lockvisibility|disables visibility updates so you can walk around and inspect what is visible from locked position.}}
{{cvar|r_drawportals|draw portal surfaces in different colors.}}
{{cvar|r_novis|Disable visibility info (whole level will be drawn).}}
{{cvar|r_useportalculling|Improve framerate of r_novis by using portal culling. Still not as good as precompiled visibility data, but it is helpful on complex maps. A value of 2 will force portal culling even if VIS data is presented, which improves framerate on maps without too much complexity but hurts on complex maps.}}

==Tutorials==
* [[Tutorials:Understanding a VIS and Hint brushes|Understanding a VIS and Hint brushes]]

==See also==
* [[PVS|Potentially visible set]]

__NOTOC__
[[Category:Glossary]]
[[Category:Darkplaces engine]]
{{finished}}

SaveId

2012-09-28T13:55:54Z

Twinchenzo:

{{grammar checked|darth}}
SaveId - entity savegame identificator key. It is a number, unique within a level, assigned with [[RWGTools]] to a "sid" entity field. It is required for gamecode to store information about levels that were already visited. Instead of entity number (assigned by engine when entity is spawned) SaveId cannot be reused when new entity is created. Also SaveId survives level editing and recompilation, allowing to extend existing game levels without [[break savegame | breaking saved games]].

== Operations with SaveId ==
RWGTools have this options to manipulate SaveId's:

* Mark - mark SaveId's on new entities.
* Remap - this will re-mark all entities (will break savegames).
* Clear - remove all SaveId's and clear world counter (will break savegames).
* Check - checks map for duplicate SaveId's and other errors.

== How 're-entering' works ==

SaveID's are courtesy of level re-entering which is core game feature in Blood Omen, but has no core support in Darkplaces engine. Re-entering is a part of Blood Omnicide gamelogic. It follows this rules:

* On level exit, all entities with a SaveId launch their saving function (class-dependent) which forms a savestring for each entity (storing entity properties that was changed comparing to level initial state), then all savestrings get packed into the level save lumps.
* When level is loaded, gamecode checks if this level has a save lump, and loads it into the reenter array of savestrings.
* Each entity when spawned, checks for corresponding record in the reenter table and loads properties from there.

[[Category:Glossary]]
{{finished}}

Repository Reference

2012-09-28T13:49:40Z

Twinchenzo:

{{grammar checked|darth}}
This reference explains a structure of Blood Omnicide SVN repository.

==Chapters==

# [[Repository Reference/Introduction|Introduction]]
# [[Repository Reference/Key Concepts|Key Concepts]]
# [[Repository Reference/Building a Game|Building a Game]]
# [[Repository Reference/Naming conventions|Naming conventions]]


==Appendix==

* [[Repository Reference/Repository structure in-depth‎|Repository structure in-depth‎]]
* [[Repository Reference/Automation scripts|Automation scripts]]


{{finished}}

Diffuse

2012-09-28T13:49:07Z

Twinchenzo:

{{grammar checked|darth}}
[[File:Color_vs_diffuse.jpg|thumb|400px|Color texture (on the left) and diffuse texture]]
Diffuse texture - a version of color texture applicable to Phong shading. Usually color texture contains shadowing and specular applied - info that is not required for Phong shading as it has shading and specular done during rendering (using [[normalmap]] and [[specular | specular map]]).

In Darkplaces, there is no special texture slot for a diffuse, it is a replacing color texture. So it matters how your surface world be lit (with phong shading or just with [[lightmap]]) to determine, if should draw a diffuse texture or a generic color texture.

{{important|Lighting up a non-diffuse texture with Phong shading will decrease an effect of it, as both calculated and baked shades will appear.}}
{{tip|Blood Omnicide uses Phong shading on all surfaces.}}

[[Category:Glossary]]
[[Category:Darkplaces engine]]
{{finished}}
__NOTOC__

Shader

2012-09-28T13:45:12Z

Twinchenzo:

{{grammar checked|darth}}
Shader (verb ''to shade'') may refer to:

* [http://en.wikipedia.org/wiki/Shader Program for 3D rendering pipeline] which could be written in special shader language (GLSL, HLSL, Cg, ARB etc.). E.g. vertex shader, pixel shader, geometry shader etc.

* Quake 3 Material. In Id Tech 3, materials are named shaders (this includes many techical papers that describe [[MD3]], [[Q3BSP]] etc.). In this regard, sometimes materials may be called shaders. Since Darkplaces engine's [[Darkplaces material system|material system]] is using Id Tech 3 material approach as a base, its materials sometimes called shaders as well (also material files extension is ''.shader'').

* Programmable block for anything that is processed in realtime. E.g. sound shaders, light shaders, entity shaders etc. ''Shader'' is different from script as it runs in realtime.

[[Category:Glossary]]
{{finished}}

BSP

2012-09-28T13:39:44Z

Twinchenzo:

{{grammar checked|darth}}
BSP may refer to:

* ([http://en.wikipedia.org/wiki/Binary_space_partitioning Binary Space Partitioning]) ‒ a technique used in games for rendering and collision detection.
* Extension of [[BSP (file) | level files]] for Quake engine and all of it's successors.
* First stage of level files compilation (see above).

[[Category:Darkplaces engine]]
[[Category:Glossary]]
{{finished}}

BSP

2012-09-28T13:37:48Z

Twinchenzo:

{{grammar checked|darth}}
BSP refers to:

* ([http://en.wikipedia.org/wiki/Binary_space_partitioning Binary Space Partitioning]) ‒ a technique used in games for rendering and collision detection.
* Extension of [[BSP (file) | level files]] for Quake engine and all of it's successors.
* First stage of level files compilation (see above).

[[Category:Darkplaces engine]]
[[Category:Glossary]]
{{finished}}

DDS

2012-09-28T13:34:05Z

Twinchenzo:

{{grammar checked|darth}}
Direct Draw Suface is a file format developed by Microsoft for DirectX SDK. This format is used in many games to store [[texture compression | compressed textures]].

Darkplaces engine can load DDS storing images of the following formats:
* '''BGRA''' : 32-bit uncompressed image
* '''DXT1''' : 4-bit compressed DXT1 texture
* '''DXT2''' : 8-bit compressed DXT2 texture
* '''DXT3''' : 8-bit compressed DXT3 texture
* '''DXT4''' : 8-bit compressed DXT4 texture
* '''DXT5''' : 8-bit compressed DXT5 texture

In Darkplaces, DDS is not a general texture format like [[TGA]] or [[JPEG]] but an override texture (dds/filename.dds) that get loaded instead of it's base texture (filename.tga), if present.

All DDS files should be stored under dds/ directory, rest of the path should mimic file path of the base texture:

dds/textures/mausoleum/outerwall1_1 // override textures/mausoleum/outerwall1_1
dds/models/mapobjects/inn/barrel1_1_norm // override models/mapobjects/inn/barrel1_1_norm
dds/models/mapobjects/inn/barrel1_1 // override models/mapobjects/inn/barrel1_1

DDS files should have mipmaps pre-generated. If there are no mipmaps generated, it is implied that this texture is not using mipmaps.

{{important|Engine shouldn't try to use mipmaps if they do not exist in DDS (see [[Darkplaces_material_system/General_Keywords#noMipMaps | noPicMip]], also gfx/ images never use mipmaps) or it may crash.}}

{{bug|Some drivers don't deal with non-power-of-two compressed textures (giving the black walls). Best way is to always make DDS textures to be [[power-of-two]].}}

===DDS for NetRadiant===

Unfortunately, NetRadiant can't load DDS images, it always loads base texture instead. This becomes a problem when supplying Radiant with the builded game (which only include DDS, no base textures). In order to avoid missing textures and broken brush texturing, every world texture that gotta be applied on [[brush | brushes]], should have separate radiant-only image (see [[Darkplaces_material_system/Special_Keywords#qer_editorImage_.3CtextureName.3E | qer_editorImage]]).

By a convention, radiant-only image should be stored in ''gamedir/radiant/path_to_base_texture'':
'''textures/town/wall1_1'''
{
qer_editorImage '''radiant/textures/town/wall1_1'''
...
}

==Tools==
You can use following tools to produce compressed DDS images:
* [[RwgTex]] - recommended commandline tool used by Blood Omnicide
* [http://developer.amd.com/tools/compressonator/pages/default.aspx ATI Compressonator]
* [http://www.imgtec.com/powervr/insider/powervr-pvrtextool.asp PVRTexTool] (requires registration)

==Future alternatives==
In 2010 Khronos group introduced [http://www.khronos.org/opengles/sdk/tools/KTX/file_format_spec/ KTX] format (covering OpenGL and OpenGL ES texture formats). This format can be used as a replacement to DDS in future.

==Console variables==
{{cvar|r_texture_dds_load|load compressed dds/filename.dds instead of filename.tga. If file exists (requires driver support).}}
{{cvar|r_texture_dds_load_alphamode|trust DDPF_ALPHAPIXELS flag, 1: texture format and brute force search if ambiguous, 2: texture format only}}
{{cvar|r_texture_dds_load_logfailure|log missing DDS textures to ddstexturefailures.log, 0: done log, 1: log with no optional textures (_norm, glow etc.). 2: log all}}
{{cvar|r_texture_dds_save|save compressed dds/filename.dds texture when filename.tga is loaded, so that it can be loaded instead next time}}
{{cvar|r_texture_dds_swdecode|0: don't software decode DDS, 1: software decode DDS if unsupported, 2: always software decode DDS. Software decoding breaks all benefits of DDS and should be used if driver dont support DDS or for debugging purposes.}}

==See also==
* [[texture compression | Texture compression]]

[[Category:Glossary]]
[[Category:File formats]]
{{finished}}
__NOTOC__

MD3 Compiler

2012-09-28T13:13:01Z

Twinchenzo:

{{grammar checked|darth}}
[[File:Tutorial_md3_01.jpg|thumb|300px|Compiler main window]]
NPherno's MD3 Compiler is a small but useful tool to preview and tweak [[MD3]] models.

==Features==
* MD3, [[ASE]], 3DS files support
* Export as MD3
* Inspection of model structure (surfaces, materials, shading, frames, tags)
* Alter materials assigned to surface
* Remove selected frame/surface
* Rebuild normals using UV seams or smooth mode

==Known bugs==
{{bug|When altering surface material or name, changes are not saved until some another surface is selected. To apply changes click on dropbox and select some surface.}}
{{bug|Normals are not loaded for ASE and 3DS, must rebuild them.}}

==Tutorials==
* [[Tutorials:Altering a material using NPherno MD3 Compiler|Altering a material using NPherno MD3 Compiler]]

==Download==
http://omnicide.legacy-of-kain.ru/files/tools/md3_compiler.zip

[[Category:Tools]]
{{finished}}

Tutorials:Altering a material using NPherno MD3 Compiler

2012-09-28T13:11:06Z

Twinchenzo:

{{DISPLAYTITLE:Tutorial: Altering a skin-path using Npherno MD3 Compiler}}
{{imported|Tabun|www.tabun.nl/tutorials/md3skinpath_tutorial/}}
{{grammar checked|darth}}

==Whats needed==
* [[MD3 Compiler|Npherno's MD3 compiler]]
* An MD3 model

==What's this about?==
This tutorial gets you acquainted with a useful and concise tool titled 'Npherno's MD3 Compiler', which can be used to alter MD3 models. More specifically, it shows you exactly how to set or change the material of a surface.

[[Darkplaces material system|Materialnames]] are stored in the MD3's themselves. When the game loads a model, it uses the embedded material name to load the proper material or texture.

Altering MD3's can be tricky at first, but it's rather easy and doesn't take more than half a minute at most.

==Step 1: Importing objects==
Launch the MD3 Compiler. It's the "MD3Compile.exe" file.
This is what you'll see:

[[File:Tutorial_md3_01.jpg|Pic 1. MD3 Compiler window]]

Now, click the button labeled "Import objects", and select the MD3 you wish to alter.
It shows the following popup:

[[File:Tutorial_md3_02.jpg|Pic 2. Importing an MD3]]

Select all parts of the model, and click "OK".
The model should now appear in the center as a red and blue set of objects.

[[File:Tutorial_md3_03.jpg|Pic 3. Imported model]]

The window should look something like pic 3.
{{important|Now, click the "All" button (located directly above "Import objects"). Make sure the checkbox in pic 4 is checked before you proceed!}}

[[File:Tutorial_md3_04.jpg|Pic 4. After clicking "All"]]

==Step 2: Altering the material==
Now we can alter the material of any of the imported objects.
Usually, you'll find the MD3 only has one object. If you've selected more than one object in the import pop-up (see pic 2), there might be objects with a path need to be edited.

Use the top-most dropdown-list to select an object (in this case, we can see that w_nailgun has been selected). The embedded path to the skin will be shown in the field immediately below it. You can edit the path now.
{{important|Remember to always use forward slashes in paths. No matter what the original path shows, use forward slashes. Failure to do so means you won't see a texture in-game.}}
{{tip|If you are change material to empty or malicious string (like ''<nowiki>%@#====6%$!!!! ----</nowiki>'') it will not be drawn}}

==Step 3: Final step==
Once you've edited the paths of all the objects, it's time to export the model, saving all of your changes.
Click "Export objects" and give the MD3 a nice name. You can overwrite the MD3 you imported without problems, by the way.

A pop-up will appear asking for an "Internal name". Unless you're editing a player model, ignore this - leave it blank.
Just click "OK".

==Recap==
To recap the tutorial stated above, here are the basic steps:
# Import objects
# Alter name (remember, FORWARD slashes)
# Export objects

==See also==
* [[Darkplaces material system]]
* [[Texture]]

[[Category:Tutorials]]
{{finished}}

Tutorials:Altering a material using NPherno MD3 Compiler

2012-09-28T13:07:50Z

Twinchenzo: /* Step 3: Final step */

{{DISPLAYTITLE:Tutorial: Altering a skin-path using Npherno MD3 Compiler}}
{{imported|Tabun|www.tabun.nl/tutorials/md3skinpath_tutorial/}}
{{grammar}}

==Whats needed==
* [[MD3 Compiler|Npherno's MD3 compiler]]
* An MD3 model

==What's this about?==
This tutorial gets you acquainted with a useful and concise tool titled 'Npherno's MD3 Compiler', which can be used to alter MD3 models. More specifically, it shows you exactly how to set or change the material of a surface.

[[Darkplaces material system|Materialnames]] are stored in the MD3's themselves. When the game loads a model, it uses the embedded material name to load the proper material or texture.

Altering MD3's can be tricky at first, but it's rather easy and doesn't take more than half a minute at most.

==Step 1: Importing objects==
Launch the MD3 Compiler. It's the "MD3Compile.exe" file.
This is what you'll see:

[[File:Tutorial_md3_01.jpg|Pic 1. MD3 Compiler window]]

Now, click the button labeled "Import objects", and select the MD3 you wish to alter.
It shows the following popup:

[[File:Tutorial_md3_02.jpg|Pic 2. Importing an MD3]]

Select all parts of the model, and click "OK".
The model should now appear in the center as a red and blue set of objects.

[[File:Tutorial_md3_03.jpg|Pic 3. Imported model]]

The window should look something like pic 3.
{{important|Now, click the "All" button (located directly above "Import objects"). Make sure the checkbox in pic 4 is checked before you proceed!}}

[[File:Tutorial_md3_04.jpg|Pic 4. After clicking "All"]]

==Step 2: Altering the material==
Now we can alter the material of any of the imported objects.
Usually, you'll find the MD3 only has one object. If you've selected more than one object in the import pop-up (see pic 2), there might be objects with a path need to be edited.

Use the top-most dropdown-list to select an object (in this case, we can see that w_nailgun has been selected). The embedded path to the skin will be shown in the field immediately below it. You can edit the path now.
{{important|Remember to always use forward slashes in paths. No matter what the original path shows, use forward slashes. Failure to do so means you won't see a texture in-game.}}
{{tip|If you are change material to empty or malicious string (like ''<nowiki>%@#====6%$!!!! ----</nowiki>'') it will not be drawn}}

==Step 3: Final step==
Once you've edited the paths of all the objects, it's time to export the model, saving all of your changes.
Click "Export objects" and give the MD3 a nice name. You can overwrite the MD3 you imported without problems, by the way.

A pop-up will appear asking for an "Internal name". Unless you're editing a player model, ignore this - leave it blank.
Just click "OK".

==Recap==
To recap the tutorial stated above, here are the basic steps:
# Import objects
# Alter name (remember, FORWARD slashes)
# Export objects

==See also==
* [[Darkplaces material system]]
* [[Texture]]

[[Category:Tutorials]]
{{finished}}

Tutorials:Altering a material using NPherno MD3 Compiler

2012-09-28T13:06:28Z

Twinchenzo: /* Step 2: Altering the material */

{{DISPLAYTITLE:Tutorial: Altering a skin-path using Npherno MD3 Compiler}}
{{imported|Tabun|www.tabun.nl/tutorials/md3skinpath_tutorial/}}
{{grammar}}

==Whats needed==
* [[MD3 Compiler|Npherno's MD3 compiler]]
* An MD3 model

==What's this about?==
This tutorial gets you acquainted with a useful and concise tool titled 'Npherno's MD3 Compiler', which can be used to alter MD3 models. More specifically, it shows you exactly how to set or change the material of a surface.

[[Darkplaces material system|Materialnames]] are stored in the MD3's themselves. When the game loads a model, it uses the embedded material name to load the proper material or texture.

Altering MD3's can be tricky at first, but it's rather easy and doesn't take more than half a minute at most.

==Step 1: Importing objects==
Launch the MD3 Compiler. It's the "MD3Compile.exe" file.
This is what you'll see:

[[File:Tutorial_md3_01.jpg|Pic 1. MD3 Compiler window]]

Now, click the button labeled "Import objects", and select the MD3 you wish to alter.
It shows the following popup:

[[File:Tutorial_md3_02.jpg|Pic 2. Importing an MD3]]

Select all parts of the model, and click "OK".
The model should now appear in the center as a red and blue set of objects.

[[File:Tutorial_md3_03.jpg|Pic 3. Imported model]]

The window should look something like pic 3.
{{important|Now, click the "All" button (located directly above "Import objects"). Make sure the checkbox in pic 4 is checked before you proceed!}}

[[File:Tutorial_md3_04.jpg|Pic 4. After clicking "All"]]

==Step 2: Altering the material==
Now we can alter the material of any of the imported objects.
Usually, you'll find the MD3 only has one object. If you've selected more than one object in the import pop-up (see pic 2), there might be objects with a path need to be edited.

Use the top-most dropdown-list to select an object (in this case, we can see that w_nailgun has been selected). The embedded path to the skin will be shown in the field immediately below it. You can edit the path now.
{{important|Remember to always use forward slashes in paths. No matter what the original path shows, use forward slashes. Failure to do so means you won't see a texture in-game.}}
{{tip|If you are change material to empty or malicious string (like ''<nowiki>%@#====6%$!!!! ----</nowiki>'') it will not be drawn}}

==Step 3: Final step==
Once you've edited the paths of all objects, it's time to export the model, saving all of your changes.
Click "Export objects" and give the MD3 a nice name. You can overwrite the MD3 you imported without problems, by the way.

A popup will show, asking for an "Internal name". Unless you're editing a player model, ignore this - leave it blank.
Just click "OK".

That's all there is to it.

==Recap==
To recap the tutorial stated above, here are the basic steps:
# Import objects
# Alter name (remember, FORWARD slashes)
# Export objects

==See also==
* [[Darkplaces material system]]
* [[Texture]]

[[Category:Tutorials]]
{{finished}}

Tutorials:Altering a material using NPherno MD3 Compiler

2012-09-28T12:55:54Z

Twinchenzo: /* What's this about? */

{{DISPLAYTITLE:Tutorial: Altering a skin-path using Npherno MD3 Compiler}}
{{imported|Tabun|www.tabun.nl/tutorials/md3skinpath_tutorial/}}
{{grammar}}

==Whats needed==
* [[MD3 Compiler|Npherno's MD3 compiler]]
* An MD3 model

==What's this about?==
This tutorial gets you acquainted with a useful and concise tool titled 'Npherno's MD3 Compiler', which can be used to alter MD3 models. More specifically, it shows you exactly how to set or change the material of a surface.

[[Darkplaces material system|Materialnames]] are stored in the MD3's themselves. When the game loads a model, it uses the embedded material name to load the proper material or texture.

Altering MD3's can be tricky at first, but it's rather easy and doesn't take more than half a minute at most.

==Step 1: Importing objects==
Launch the MD3 Compiler. It's the "MD3Compile.exe" file.
This is what you'll see:

[[File:Tutorial_md3_01.jpg|Pic 1. MD3 Compiler window]]

Now, click the button labeled "Import objects", and select the MD3 you wish to alter.
It shows the following popup:

[[File:Tutorial_md3_02.jpg|Pic 2. Importing an MD3]]

Select all parts of the model, and click "OK".
The model should now appear in the center as a red and blue set of objects.

[[File:Tutorial_md3_03.jpg|Pic 3. Imported model]]

The window should look something like pic 3.
{{important|Now, click the "All" button (located directly above "Import objects"). Make sure the checkbox in pic 4 is checked before you proceed!}}

[[File:Tutorial_md3_04.jpg|Pic 4. After clicking "All"]]

==Step 2: Altering the material==
Now we can alter the material of any of the imported objects.
Usually, you'll find the MD3 only has one object. If you've had to select more than one object in the import popup (see pic 2), there are more objects whose path may need editing.

Use the top-most dropdown-list to select an object (in this case, we can see that w_nailgun has been selected). The embedded path to the skin will be shown in the field immediately below it. You can edit the path now.
{{important|Remember to always use forward slashes in paths. No matter what the original path shows, use forward slashes. Failure to do so means you won't see a texture in-game.}}
{{tip|If you are change material to empty or malicious string (like ''<nowiki>%@#====6%$!!!! ----</nowiki>'') it will not be drawn}}

==Step 3: Final step==
Once you've edited the paths of all objects, it's time to export the model, saving all of your changes.
Click "Export objects" and give the MD3 a nice name. You can overwrite the MD3 you imported without problems, by the way.

A popup will show, asking for an "Internal name". Unless you're editing a player model, ignore this - leave it blank.
Just click "OK".

That's all there is to it.

==Recap==
To recap the tutorial stated above, here are the basic steps:
# Import objects
# Alter name (remember, FORWARD slashes)
# Export objects

==See also==
* [[Darkplaces material system]]
* [[Texture]]

[[Category:Tutorials]]
{{finished}}

DDS

2012-08-02T14:32:42Z

Twinchenzo:

{{grammar}}
Direct Draw Suface is a file format developed by Microsoft for DirectX SDK. This format is used in many games to store [[texture compression | compressed textures]].

Darkplaces engine can load DDS storing the images of the following formats:
* '''BGRA''' : 32-bit uncompressed image
* '''DXT1''' : 4-bit compressed DXT1 texture
* '''DXT2''' : 8-bit compressed DXT2 texture
* '''DXT3''' : 8-bit compressed DXT3 texture
* '''DXT4''' : 8-bit compressed DXT4 texture
* '''DXT5''' : 8-bit compressed DXT5 texture

In Darkplaces, DDS are not general texture format like [[TGA]] or [[JPEG]] but an override texture (dds/filename.dds) that get loaded instead of it's base texture (filename.tga), if presented.

All DDS files should be stored under dds/ directory, rest of the path should mimic file path of the base texture:

dds/textures/mausoleum/outerwall1_1 // override textures/mausoleum/outerwall1_1
dds/models/mapobjects/inn/barrel1_1_norm // override models/mapobjects/inn/barrel1_1_norm
dds/models/mapobjects/inn/barrel1_1 // override models/mapobjects/inn/barrel1_1

DDS files should have mipmaps pre-generated. If there are no mipmaps generated, it is implied that this texture is not using mipmaps.

{{important|Engine shouldn't try to use mipmaps if they do not exist in DDS (see [[Darkplaces_material_system/General_Keywords#noMipMaps | noPicMip]], also gfx/ images never use mipmaps) or it may crash.}}

{{bug|Some drivers don't deal with non-power-of-two compressed textures (giving the black walls). Best way is to always make DDS textures to be [[power-of-two]].}}

===DDS for NetRadiant===

Unfortunately, NetRadiant can't load DDS images, it always loads base texture instead. This becomes a problem when supplying Radiant with the builded game (which only include DDS, no base textures). In order to avoid missing textures and broken brush texturing, every world texture that gotta be applied on [[brush | brushes]], should have separate radiant-only image (see [[Darkplaces_material_system/Special_Keywords#qer_editorImage_.3CtextureName.3E | qer_editorImage]]).

By a convention, radiant-only image should be stored in ''gamedir/radiant/path_to_base_texture'':
'''textures/town/wall1_1'''
{
qer_editorImage '''radiant/textures/town/wall1_1'''
...
}

==Tools==
You can use following tools to produce compressed DDS images:
* [[RwgTex]] - recommended commandline tool used by Blood Omnicide
* [http://developer.amd.com/tools/compressonator/pages/default.aspx ATI Compressonator]
* [http://www.imgtec.com/powervr/insider/powervr-pvrtextool.asp PVRTexTool] (requires registration)

==Future alternatives==
In 2010 Khronos group introduced [http://www.khronos.org/opengles/sdk/tools/KTX/file_format_spec/ KTX] format (covering OpenGL and OpenGL ES texture formats). This format can be used as a replacement to DDS in future.

==Console variables==
{{cvar|r_texture_dds_load|load compressed dds/filename.dds instead of filename.tga. If file exists (requires driver support).}}
{{cvar|r_texture_dds_load_alphamode|trust DDPF_ALPHAPIXELS flag, 1: texture format and brute force search if ambiguous, 2: texture format only}}
{{cvar|r_texture_dds_load_logfailure|log missing DDS textures to ddstexturefailures.log, 0: done log, 1: log with no optional textures (_norm, glow etc.). 2: log all}}
{{cvar|r_texture_dds_save|save compressed dds/filename.dds texture when filename.tga is loaded, so that it can be loaded instead next time}}
{{cvar|r_texture_dds_swdecode|0: don't software decode DDS, 1: software decode DDS if unsupported, 2: always software decode DDS. Software decoding breaks all benefits of DDS and should be used if driver dont support DDS or for debugging purposes.}}

==See also==
* [[texture compression | Texture compression]]

[[Category:Glossary]]
[[Category:File formats]]
{{finished}}
__NOTOC__

MD3 Compiler

2012-08-02T14:28:26Z

Twinchenzo: /* Known bugs */

{{grammar}}
[[File:Tutorial_md3_01.jpg|thumb|300px|Compiler main window]]
NPherno's MD3 Compiler is a small but useful tool to preview and tweak [[MD3]] models.

==Features==
* MD3, [[ASE]], 3DS files support
* Export as MD3
* Inspection of model structure (surfaces, materials, shading, frames, tags)
* Alter materials assigned to surface
* Remove selected frame/surface
* Rebuild normals using UV seams or smooth mode

==Known bugs==
{{bug|When altering surface material or name, changes are not saved until some another surface is selected. To apply changes click on dropbox and select some surface.}}
{{bug|Normals are not loaded for ASE and 3DS, must rebuild them.}}

==Tutorials==
* [[Tutorials:Altering a material using NPherno MD3 Compiler|Altering a material using NPherno MD3 Compiler]]

==Download==
http://omnicide.legacy-of-kain.ru/files/tools/md3_compiler.zip

[[Category:Tools]]
{{finished}}

MD3 Compiler

2012-08-02T14:27:24Z

Twinchenzo: /* Features */

{{grammar}}
[[File:Tutorial_md3_01.jpg|thumb|300px|Compiler main window]]
NPherno's MD3 Compiler is a small but useful tool to preview and tweak [[MD3]] models.

==Features==
* MD3, [[ASE]], 3DS files support
* Export as MD3
* Inspection of model structure (surfaces, materials, shading, frames, tags)
* Alter materials assigned to surface
* Remove selected frame/surface
* Rebuild normals using UV seams or smooth mode

==Known bugs==
{{bug|When altering surface material or name, changes arent saved until some another surface is selected. To apply changes click on dropbox and select some surface.}}
{{bug|Normals are not loaded for ASE and 3DS, should rebuild them.}}

==Tutorials==
* [[Tutorials:Altering a material using NPherno MD3 Compiler|Altering a material using NPherno MD3 Compiler]]

==Download==
http://omnicide.legacy-of-kain.ru/files/tools/md3_compiler.zip

[[Category:Tools]]
{{finished}}

Tutorials:Altering a material using NPherno MD3 Compiler

2012-08-02T14:21:37Z

Twinchenzo: /* Recap */

{{DISPLAYTITLE:Tutorial: Altering a skin-path using Npherno MD3 Compiler}}
{{imported|Tabun|www.tabun.nl/tutorials/md3skinpath_tutorial/}}
{{grammar}}

==Whats needed==
* [[MD3 Compiler|Npherno's MD3 compiler]]
* An MD3 model

==What's this about?==
This tutorial gets you acquainted with the useful and concise tool titled 'Npherno's MD3 Compiler', which can be used to alter MD3 models. More specifically, it shows you exactly how to set or change a material of surface.

[[Darkplaces material system|Materialnames]] are stored in the MD3's themselves. When the game loads a model, it uses the embedded material name to load the proper material or texture.

Altering MD3's can be tricky at first, but it's rather easy and doesn't take more than half a minute at most.

==Step 1: Importing objects==
Launch the MD3 Compiler. It's the "MD3Compile.exe" file.
This is what you'll see:

[[File:Tutorial_md3_01.jpg|Pic 1. MD3 Compiler window]]

Now, click the button labeled "Import objects", and select the MD3 you wish to alter.
It shows the following popup:

[[File:Tutorial_md3_02.jpg|Pic 2. Importing an MD3]]

Select all parts of the model, and click "OK".
The model should now appear in the center as a red and blue set of objects.

[[File:Tutorial_md3_03.jpg|Pic 3. Imported model]]

The window should look something like pic 3.
{{important|Now, click the "All" button (located directly above "Import objects"). Make sure the checkbox in pic 4 is checked before you proceed!}}

[[File:Tutorial_md3_04.jpg|Pic 4. After clicking "All"]]

==Step 2: Altering the material==
Now we can alter the material of any of the imported objects.
Usually, you'll find the MD3 only has one object. If you've had to select more than one object in the import popup (see pic 2), there are more objects whose path may need editing.

Use the top-most dropdown-list to select an object (in this case, we can see that w_nailgun has been selected). The embedded path to the skin will be shown in the field immediately below it. You can edit the path now.
{{important|Remember to always use forward slashes in paths. No matter what the original path shows, use forward slashes. Failure to do so means you won't see a texture in-game.}}
{{tip|If you are change material to empty or malicious string (like ''<nowiki>%@#====6%$!!!! ----</nowiki>'') it will not be drawn}}

==Step 3: Final step==
Once you've edited the paths of all objects, it's time to export the model, saving all of your changes.
Click "Export objects" and give the MD3 a nice name. You can overwrite the MD3 you imported without problems, by the way.

A popup will show, asking for an "Internal name". Unless you're editing a player model, ignore this - leave it blank.
Just click "OK".

That's all there is to it.

==Recap==
To recap the tutorial stated above, here are the basic steps:
# Import objects
# Alter name (remember, FORWARD slashes)
# Export objects

==See also==
* [[Darkplaces material system]]
* [[Texture]]

[[Category:Tutorials]]
{{finished}}