Unvanquished - User contributions [en-gb]

User:Calinou

2014-04-08T10:18:30Z

Calinou: In case the wiki's license is changed, I accept a license change to GFDL, CC0, CC BY and CC BY-SA (any version).

I started playing in November 2013. I almost never played Tremulous.

I am French, I contributed to the French translation of Unvanquished and many other games and projects.

''In case the wiki's license is changed, I accept a license change to GFDL, CC0, CC BY and CC BY-SA (any version).''

Formats/Model

2014-03-30T13:52:43Z

Calinou: IQM is the preferred format currently.

[[Category:Modeling]]
If you are a model artist and would like to help, please consider [[Main_Page#Contributing|contributing]]!

==Selecting what software to use==

While members of the team use Zbrush, 3ds Max, Maya, and other software, Blender is preferred as it is used by most of the team and is freely available, making it accessible to anyone. Using software other than Blender can create problems in collaborating on work. Please be aware that in transferring data between software some information may be lost, such as animation data. At a minimum, transferring model and UV (unwrap) data is almost guaranteed with the Wavefront .obj format.

===Software-specific help===

* [[Blender]]

==Modeling progress==

Please see the [[Modeling progress|full article]].

==Workflow overview==

The process from start to finish typically goes like this:

# '''Modeling''' — A 3D model is created in any of a number of applications; you do not need to worry about what software you use for this stage as long as it can export in a format such as Wavefront .obj. At this stage, it may be either high or low-poly.
# '''Texturing''' — The model is unwrapped and textured. If a high-poly model is available, its normals are baked onto the low-poly model.
# '''Rigging''' — The model is rigged. From this point forward, if the unwrap (and texture) is to be changed, this must be done in the same program that animation is being done in.
# '''Animation''' — The model is animated. If you are using Blender, simply animate the model with its different animations in different keyframe ranges. The order is unimportant. For example, the death animation might occupy frames 0-60 and the pain animation occupy frames 61-120. See [[Exporting_Models#Animation_names|the list of animation names]] for more information as to what animations must be made for each model. Also, when using Blender, have the model face in the +Y direction. The newer MD5 exporter has an option to reorient the model to face in the +X direction.
# '''Exporting''' — The engine obviously cannot read .blend files, so the model must be exported to another format that it understands. IQM is currently the preferred format. The process for doing this is described in detail on the [[Exporting Models]] page. This is a multi-step process involving configuration editing and [[Packaging game data|packaging]].

Tutorials/Mapping guide

2013-11-29T11:04:59Z

Calinou: It's .Unvanquished

{{WIP|author=Veyrdite}}

{{Note
|header=Greetings new people!
|content=
This page is written to make it easier for anyone to get involved in mapping. If you don't understand something -- don't PANIC -- this guide is still rough around the edges and may have some complicated bits. Skip over them for now, and tell us about them if you can't fix them yourself!
}}

Mapping or 'level-making' for Unvanquished is fun to learn but difficult to master.

Creating maps is highly open ended: you can approach it with any level of skill yet still get great results. Just like every other art you will encounter freedom, expression and most of all frustration. Be prepared and expect it: you will encounter many 'failures' when you start simply because you will compare your ''small'' work with the finished monuments made by experienced mappers. Mapping is not unlike drawing: when you want to doodle, or if you are new to the art, you will find it difficult to get to a finished work you are satisfied with.

Read on and you will find a rewarding guide into mapping for Unvanquished in less than an hour! Making common caveats and solutions are also covered.

= Getting the Tools =
Start this before reading on, so you can be downloading your mapping tool in the background whilst enjoying the poetry that follows.

The rest of this guide will expect you to be using Ingar's NetRadiant to make maps -- currently the recommended and most supported solution. Download it from http://ingar.satgnu.net/gtkradiant/ (or find it on the AUR if you are an Arch Linux user).

You will also need the Unvanquished gamepack for the editor, also hosted by Ingar. Get it from http://ingar.satgnu.net/gtkradiant/files/gamepacks/UnvanquishedPack.zip

Apart from the game itself, that's all you need. Instructions for setup are later in the guide.

== Other tools you can use ==
Feel free to delve into the alternatives, but we recommend you don't until you have first tried Netradiant.
{| class="wikitable progress"
|-
! rowspan="2" | Program
! colspan="3" | Supported OSes
! rowspan="2" | Last stable release
! rowspan="2" | Notes
|-
! Mac OS X
! Windows
! Linux
|-
! [http://dev.alientrap.org/projects/show/netradiant NetRadiant] ([http://ingar.satgnu.net/gtkradiant/ Ingar's builds])
| class="done" | 10.5 & 10.6 (Intel Only)
| class="done" | Yes
| class="done" | Yes
| Current (2012)
| Highly recommended brush-based editor. X11 is required for Mac users (10.7 users can get this from the [http://xquartz.macosforge.org/landing/ XQuartz project]).
|-
! [http://icculus.org/gtkradiant/ GtkRadiant]
| class="none" | No
| class="done" | Yes
| class="done" | Yes
| Abandoned (2012)
| Predecessor of NetRadiant. Brush based.
|-
! [http://darkradiant.sourceforge.net/ DarkRadiant]
| class="none" | No
| class="done" | Yes (32 and 64-bit)
| class="wip" | ?
| Current
| Designed for a Doom 3 mod. Linux packages are not yet available (but have been promised by the developer).
|-
! [http://www.redsaurus.net/00/node/4 MacRadiant]
| class="done" | Yes (Intel & PPC)
| class="none" | No
| class="none" | No
| Unknown (v1.4 and v1.5)
| Problems have been reported with Snow Leopard and Leopard, though there are workarounds. See the download page for more information.
|-
! [http://quark.sourceforge.net/ QuArK]
| class="none" | No
| class="done" | Yes
| class="none" | No
| Current (2013)
|
|-
! [[#Gmax|Gmax]]
| class="none" | No
| class="done" | Yes
| class="none" | No
| Abandoned (2005)
| Freeware version of polygon-based modelling tool 3DsMax. Used by many games but never updated: small bugs exist. May require a registration bypass to work (easily found) as the registration web-form has disappeared.
|-
! [[#Blender|Blender]]
| class="done" | Yes
| class="done" | Yes
| class="done" | Yes
| Current
| Extremely popular and open-source polygon based modelling tool.
|-
|}

= The Mapper's Guide to Success and Happiness =
This booster-venom encrusted guide is built from the experience of many past mappers. If you are just starting: read this now, but most of all '''if you ever have problems or frustrations whilst map making: come back and and have a quick read of this section'''. You will thank us for it :)

== Make life easier for yourself ==
* Making maps is fun. If you feel entrenched in a metaphorical hole, you need to think of some other way of solving your problem.
* Don't be [https://en.wikipedia.org/wiki/Obsessive-compulsive_disorder OCD]. Make maps messily -- there is no performance penalty for players and you will work much faster, getting '''much more emotional reward'''.
* Don't make ANY part of your work symmetrical. It takes twice the work and fiddling to make an uninteresting result.

== Map making involves a variety of experiences ==
* Take different ideas to a variety of lengths. Not every idea you start playing out in the editor will become part of a finished map.
* Tear other people's maps apart in an editor to see what they did.

== Be modular, not linear ==
[[File:Mapmaking_approaches.png|thumb|upright=2|The three elements of map-making approach. Mix wisely]]
Many people become frustrated when trying to create a map from one end to the other. This puts a focus on small detail (micro) rather than the map itself as a whole (macro). Even taking time to texture elements is an uneventful sink if you have only created a few small rooms.

Instead you should take another route, such as one of these:
# Not aim to create a map. Instead make modules like rooms, which later on you can sandwich together to make something more impressive. This technique is used by many successful mappers.
# Make your map starting at the roughest level (layout & size of rooms) and progress down into the various levels of detail, doing most of the map at a time for each. Again, this technique is used by many successful mappers.

= Important Unvanquished Map Concepts =
This information is really a summary, but enough for you to get an understanding of how things are structured for later in the guide.

A lot of the concepts here are inherited from [https://en.wikipedia.org/wiki/Quake_(video_game) Quake], a game made in the 90's by ID Software. Unvanquished is part of a chain of games with a heritage traceable back to Quake.

== How maps are made ==
In an editor like NetRadiant you make maps out of 'brushes'. Brushes are 3D shapes such as boxes, cylinders and planes. Shaders (textures/pictures) are then placed on the surfaces of these shapes. Have a look at what Niveus looks like in NetRadiant:

[[File:Niveus_brushesSelected.jpeg]]

Here two brushes have been selected, and you can see that they are 3D shapes. One is an ordinary box and beneath it is a box with sloped sides. Every single part of the map's geometry is designed out of shapes like this. We will explore this a little later.

Unvanquished follows the indoor engine philosophy: it expects your map to be a massive airtight container. If you have a gap anywhere in your map to the outside world, it's considered a leak and won't compile (more on this later). Have a look at Niveus in-game when viewed from outside the airtight play space:

[[File:Niveus_OutsideTheMap.jpeg]]

This looks nothing like the collection of 3D brushes used to make the map! During compilation only the sides of brushes visible when playing the map are kept; everything else is never seen anwyay and hence considered a waste of computer resources. We can see inside through the walls because the 'faces' or 'sides' of everything are only visible in one direction.

If you have never done any 3D modelling or map making before this will be very new to you. Video games are only interested in the surfaces of everything -- not what's inside them -- because that's all the player will ever see. The barrels in the above image are just as hollow as everything else. NetRadiant allows you to make maps using tangible 3D objects simply because it's easier for us to understand and manipulate, not because that's how the game works.

{{Note
|header=More on how video games treat tangible 3D things
|content=
To computationally work out how things look on your screen, a large amount of horrendously fun calculations involving 4x4 transformation matrices and other long words are used.

If you want a better way of visualising how games treat 3D objects: visualise every surface as being made of flat triangles. A square is made of two triangles for example, and so is every single other surface & shape in almost every video game. Curves are made of many small triangles -- if you get close, you can sometimes see this, or at least to the level of rectangles.

To save time {{verify}} triangles are only drawn in one direction. That's why we can see through the walls in the map above. You will almost never encounter this in Unvanquished, because the compiler forbids situations where you would be able to see the rear of triangles.

Now that you have read this, go grab a cup of your preferred beverage and enjoy the aura of superiority surrounding you for the next 2d6 minutes.
}}

You can also see how things like the sky are faked using this method: outside the window are some walls that pretend to be sky. This is how the spot outside the window looks in NetRadiant:

[[File:Niveus outside closed.jpeg]]

Looks a little odd, doesn't it? First of all, it's encased in a box. I'll take the top off.

[[File:Niveus outside open.jpeg]]

Now we can see in. Unfortunately "Shader Not Found" is spewn everywhere because I have imported the map rather than working with the original files, but the example still holds. This area is what you see outside of the window near the human start point. The big "Shader not Found" walls would have a "skybox" shader applied so they look like the sky when in-game. We will do this much later in the guide.

Once you have made you map, and corrected any leaks, you compile it.

== Compilation ==
The '.map' you make in NetRadiant needs to be compiled into a '.bsp' for the game to be able to use it. Compilation takes a while to pass over your map several times for various processes.

Compilation calculates the effects of lights in your maps. Lighting determines the various levels of 'darkening' and 'lightening' applied to every part of every visible surface of your map. You can't see the effects of lighting in NetRadiant itself, so you will have to start with simple lighting and build it's complexity up with trial and error.

Compilation spends a great deal of time optimising brush visibility. In basic terms, the game does not want to spend time 'drawing' rooms of the map you can't see anyway. This wiki page will not take you through the process of 'hinting' which assists this process (makes it faster to pre-process?) but you can find many applicable tutorials on the web for doing it in Radiant-like editors for Quake-like games.

Unvanquished uses daemonmap (Unvanquished specific version of Q3Map2) to compile maps. You don't need to know details like this, but the basic understanding of what compilation does will help you identify, understand and fix problems with your maps.

== Shaders ==
Different games define the word 'shader' in different ways. The definition here applies to all Quake derivatives.

A shader defines how a surface looks. In its most minimal form it's just a texture (image) applied to a brush to give it an appearance. Shaders can be setup to do many interesting things, such as make a flat surface pretend to be 3D (via normal or bump maps), pretend to be an infinitely distant sky (a skybox) or always be bright like a lightbulb.

This guide will tackle shaders last because they are less tangible to make than 3D models. We will borrow the shaders other maps use until then.

== Map and Resource Packaging ==
When making your map you need to know how the game and NetRadiant expects the files to be organised. Using your own organisation system will confuse the game engine, which thinks its system is perfect zen. The current system described here will ''hopefully'' be replaced in the future, [http://unvanquished.net/news/109-first-engine-upgrade-merge hinted at on the blog].

If you navigate to your game's installation directory you will find a collection of ".pk3" files in a folder called 'main'. These files are zip files -- if you can't open them, copy one and rename it from pk3 to zip. Have a look at what's inside map-niveus-gpp.pk3:

map-niveus-gpp.pk3
├── env
│   └── niveus
│   ├── snowy_bk.jpg
│   ├── snowy_dn.jpg
│   ├── snowy_ft.jpg
│   ├── snowy_lf.jpg
│   ├── snowy_rt.jpg
│   └── snowy_up.jpg
├── levelshots
│   └── niveus.jpg
├── maps
│   └── niveus.bsp
├── models
│   └── mapobjects
│   └── niveus
│   ├── computer.blend.jpg
│   ├── computer.jpg
│   ├── computer.md3
│   ├── fern_leaf.tga
│   ├── fern.md3
│   ├── palm_leaf.tga
│   ├── palm.md3
│   ├── wallthing.jpg
│   └── wallthing.md3
├── niveus.txt
├── scripts
│   ├── niveus.arena
│   ├── niveus.particle
│   └── niveus.shader
├── sound
│   └── niveus
│   └── steam.wav
└── textures
└── niveus
└── (a long list of texture files)

You can see that the compiled map file (.bsp) is in a 'maps' folder, the textures are in a 'textures' folder, etc.

The exact purpose of all of these files and folders will be described later. You will not use many of them to start with: only a map file is necessary to get a map working in-game.

When you play Unvanquished, the game 'extracts' all of the necessary pk3s into the one spot. This means that all of the texture folders mix contents, all of the map folders mix contents, etc. In the end the game expects to be able to find all maps in 'maps', all textures in 'textures', etc. This means one pk3 can '''overwrite''' the contents of another pk3 if files share names -- which is why the contents of for example 'textures' is put in a subfolder with the map's name.

Making a pk3 is a final step to release your map. When working on it, the folders that would be in the .pk3 (textures, maps, etc) can instead be kept in a folder with '.pk3dir' at the end.

Alternatively you can make folders such as 'textures' and 'maps' directly in the Unvanquished install directory or your user's Unvanquished directory, however this would store your map along with other junk, making managing it messier and creating a .pk3 of it more fiddly. More on this in the next section.

== Game Storage Locations ==
Unvanquished creates its virtual collection of resources (textures, maps, etc) using this order of locations{{verify}}:
# Unvanquished installation directory
# User's Unvanquished directory
# Contents of relevant pk3s

For example, if a 'textures' folder was found in the install directory with a 'nakedDretch.jpeg" inside it, that file and folder would be loaded just as if they were in a .pk3. Ditto for the user's Unv directory. By the end of the process, all 'texture' folders from these two locations and relevant pk3s will be merged. If two files with the same name exist, the one loaded ''later'' in the order shown above will replace the previous one.

Unvanquished has two separate game data directories, where resources and .pk3s can be loaded from, so that one user's changes don't affect any other users. If ''Bob the Ugly Dragoon'' installs new maps and takes lots of screenshots, none of this will affect ''Geraldine the Human'' even if they share the same computer, as it will be stored separately for each user. No changes to the contents of the Unvanquished installation directory are normally ever made outside of official updates.

{| class="wikitable"
|-
! Platform
! Variant
! Default Installation Directory
! Default User Directory
|-
! rowspan="2" | Windows
| 32 bit
| C:\Program Files\Unvanquished
| rowspan="2" | ???
|-
| 64 bit
| C:\Program Files\Unvanquished (x86)
|-
! Mac
| ???
| ???
| ???
|-
! rowspan=4 | Linux
| Arch, from AUR
| /var/lib/unvanquished
| rowspan=5 | ~/.Unvanquished
|-
| Compiled from source
| ???
|-
| Debian/Ubuntu/Mint
| ???
|-
|}

{{Note
|header=*nix users: Can't find .Unvanquished in your home directory?
|content=
If you are looking in a file browser but can't see it, pressing Ctrl+H usually reveals hidden [https://en.wikipedia.org/wiki/Dotfile dotfiles] like this one.
}}

= Setting up NetRadiant =
Only need to do this once.
* Gamepack
* Game install DIR

= Your First Dive into Mapping =

== NetRadiant Interface Overview ==
Lots of piccies!

== Small Demonstration ==
* Showing use of key shortcuts
* Lots of piccies

== Project setup and Compilation ==
* Setup of pk3dir

== From Editor to Game ==
=== Compiling & Fixing Leaks ===
=== Testing in-game ===
* devmap
* bots

== From Game to World ==
=== Packaging ===
=== Gameplay considerations ===
=== Social Consids ===

User talk:Calinou

2013-11-29T10:08:13Z

Calinou: fix

''Sign your posts using <nowiki>~~~~</nowiki>''

User talk:Calinou

2013-11-29T10:07:41Z

Calinou: Created page with "''Sign your posts using ~~~~''"

''Sign your posts using [[User:Calinou|Calinou]] - [[User_talk:Calinou|talk]] '''×''' [[Special:Contributions/Calinou|contribs]] '''»''' 04:07, 29 November 2013 (CST)''

User:Calinou

2013-11-29T10:06:23Z

Calinou: Created page with "I started playing in November 2013. I almost never played Tremulous. I am French, I contributed to the French translation of Unvanquished and many other games and projects."

I started playing in November 2013. I almost never played Tremulous.

I am French, I contributed to the French translation of Unvanquished and many other games and projects.

Template:SupportedModelFormats

2013-11-29T10:05:04Z

Calinou: IQM support is planned according to news.

The Daemon engine currently only supports the following:
{| class="wikitable"
|-
! rowspan="2" | Format
! colspan="2" | Introduced in
! rowspan="2" | Supported techniques
! rowspan="2" | Exporter availability
|-
! Title
! Year
|-
| MD3
| Quake 3
| 1999
| Per-frame vertex animation
|
* Milkshape 3d
* Blender 2.4 or newer
|-
| [http://udn.epicgames.com/Two/BinaryFormatSpecifications.html PSK]
| Unreal Tournament 2003 (Unreal Engine 2)1
| 2002
| Bones with vertex weights
|
* Maya2
* 3ds Max2
* SoftImage
|-
| MDC
| Wolfenstein: Enemy Territory
| 2003
| Unsure
| Unsure
|-
| MD5
| Doom 3
| 2004
| Bones with vertex weights
|
* Maya
* 3ds Max
* Blender 2.4 or newer
|-
|}
# Actually, America's Army 1.0 was the first title to be released using this format, as it used Unreal Engine 2 as well; it was released in June of that year, and Unreal Tournament 2003 in October.
# With the [http://udn.epicgames.com/Two/ActorX.html ActorX plugin].
# With a plugin provided by [http://udn.epicgames.com/Two/ActorX.html#XSI%20Exporter%20Plugins SoftImage].

However, we recommend that you use the MD5 format at this time.

Support for the IQM format [http://unvanquished.net/news/110-iqm has been planned], also see [[Feature_Proposals/IQM_Format_Support|this]].

Note that mappers may use other formats for static models, such as the ASE ('''A'''SCII '''S'''cene '''E'''xport, not to be confused with Adobe's .ase format) and Wavefront Obj formats. A complete listing is available on the [[Mapping#Models|mapping]] page.