Tutorial: Render Properties Last edited 3 months ago2024-08-29 13:39:51 UTC

You are viewing an older revision of this wiki page. The current revision may be more detailed and up-to-date. Click here to see the current revision of this page.
Download example map

Introduction

Almost all visual entities (brush and point) in a map will have a set of basic rendering properties: This page describes all these properties and their values.

But before we get into these properties, we will cover the types of visual entities, as the above rendering properties applies differently according to their type: For quick reference, this page will mark the visual types that apply to different properties with the following scheme: [Brush/Model/Sprite]

Visual entity types

Brush models (brush entities)

Brush entities in game uses brush models. Brush models are generated during the compiling process of a map from the brushwork of each brush entity, and all stored in the single resulting BSP file. Examples of brush entities that has visible brushwork include func_door, func_wall, and func_tracktrain, but excludes func_ entities that act like triggers such as func_friction, func_traincontrols, and most notably func_ladder.

The game engine supports multiple brush entities sharing the same brush model in the map they're in, and the ZHLT compilers support this by using the zhlt_usemodel keyvalue. This is notable because decals will be shared across all entities using the same brush model.

Studio models

Studio models are the usual models, used by NPCs, player models, weapons, ammo, items, props etc. In most code bases, the entities use hardcoded models (e.g. monster_barney uses models/barney.mdl and item_battery uses models/w_battery.mdl). See Reference: Entities and their models for a full list of these hardcoded values.
Some entities like cycler, monster_generic, and monster_furniture lets you specify your own models. Other code bases like SoHL, Sven Co-Op and Featureful lets you override models of normal entities.

Sprites

Sprites are 2D textures that float inside the level (versus brush-based textures) for effects like smoke and glow effects, as well as laser and lightning beams. Most sprites are authored to always face the camera and have its colour tinted with the FX Color property. Example entities include env_sprite and env_beam.

Sprites can be in normal, additive, indexalpha or alphatest mode. In particular, indexalpha mode works similar to decals in that the tint colour is encoded in the last palette index. Keep this in mind when applying Render Color property, which multiplies the base colour. More on these in env_sprite's page.
This section assumes normal use cases as a shortcut. The engine actually renders according to the type of resource referenced by the model keyvalue that's either defined in the entity properties or hardcoded for the entity. You can do shenanigans such as using a .spr sprite as a func_train's model, so the rendering properties apply to that func_train as if it is an env_sprite instead.

Render properties

Render FX (renderfx)

Render FX is probably the simplest property - it sets any special effects that the entity is rendered with, such as fading in and out, flickering etc. You may need to tweak the other properties before the effect looks good though.

In almost all cases, some form of opacity modulation is applied, and requires the entities to be in non-normal Render Mode. Some effects involve physical distortion of the entity's model shape and such effects only apply to models.

Available values are: The following values are undocumented (not available in most FGDs) but available in all GoldSource games/mods:

Render Mode (rendermode)

Render Mode is a pretty fundamental part of the rendering properties - it sets the way in which the entity is rendered. The options are:
Formulas for nerds
Here's the formula used for shading entities according to the various render modes (source):
Render formula
Mode Formula
Normal src
Color c*a + dest*(1-a)
Texture src*a + dest*(1-a)
Glow src*a + dest (No Z buffer checks)
Solid src*srca + dest*(1-srca)
Additive src*a + dest
Legend
Item Description
src entity being rendered
dest background
a FX Amount / alpha
c FX Color
srca alpha in source

FX Amount (renderamt)

This property usually controls the translucency of the effect, and can have a value ranging from 0 (totally invisible) to 255 (fully opaque).

It depends on the Render Mode: brush entities with Solid mode will be fully opaque for any amount greater than 0; likewise for sprites in Color mode. In Normal mode it has no effect for all entity types.

FX Color (rendercolor)

FX Color is an RGB value, each ranging from 0 to 255 (e.g. 255 0 0 is pure red). Its meaning depends on the Render Mode and the entity type.

On brush entities, it is used with the Color Render Mode to render the entire brush entity as a solid colour as set in FX Color. All other details – textures, lightmaps, decals – are removed.
In all other Render Modes, the FX Color can be used to encode the speed that scrolling textures (textures whose name starts with SCROLL) on brush entities will scroll in. func_conveyor does this programmatically based on its speed keyvalue, but you can use FX Color to set such value to any brush entity. See func_conveyor's page for the formula.

On sprites, in all Render Modes except Color, this sets the colour to tint the sprite.
Note that some entities like env_beam, while using the rendercolor key, labels it differently in SmartEdit mode.
The value 0 0 0 disables this property for sprites, so use a "very close to but not actually black" colour instead.

Property relationship by entity type

To help demystify which FX works with which mode works with which entity type, this section tabulates the availability of modes and effects separated by entity model type.

Brush model (brush entity)

Render Mode Render Amount Render Color Bullet decal Lightmap Alpha Transparency
Normal (0) Scroll speed Solid Black, opaque
Color (1) Opacity Colour None N/A
Texture (2) Opacity Scroll speed Glass Transparent
Glow (3) Opacity Scroll speed Glass Transparent
Solid (4) Fully opaque if >0 Scroll speed None Transparent
Additive (5) Opacity Scroll speed Glass Transparent
Notes:
  • In color mode, the entity will be of a pure colour as set in FX Color on screen with opacity as in FX amount. All other features – decals, lightmaps, textures – are removed.
  • Bullet decals are determined based on render mode at time of impact and remains unchanged as the mode changes.
  • Solid mode will have no decal whatsoever; even existing decals will be removed if the mode is changed to solid.
  • Render Color encodes scroll speed for faces with scroll* textures. See func_conveyor page for more info. Otherwise it has no other effect in non-color mode.
  • In modes that don't apply lightmaps, VHLT supports zhlt_embedlightmap property which bakes the lightmaps onto the individual face's textures. See Tutorial: The Complete Guide to Lighting, Section 3.8 for more info.
Render FX Normal Color Texture Glow Solid Additive
Normal (0) N/A N/A N/A N/A N/A N/A
Pulse effects (1-4)
Fade effects (5-6)
Solid effects (7-8)
Strobe effects (9-11)
Flicker effects (12-13)
Constant Glow (14)
Distort & Hologram (15-16)
Bulge Sideways (18)
Glow shell (19)

Studio model

Render Mode Render Amount Render Color
Normal (0)
Color (1) Opacity
Texture (2) Opacity
Glow (3) Opacity
Solid (4) Opacity
Additive (5) Opacity
For all intents and purposes, modes Color through Solid (1-4) renders identically on models.
Render FX Normal Color Texture Glow Solid Additive Remarks
Normal (0) N/A N/A N/A N/A N/A N/A
Pulse effects (1-4)
Fade effects (5-6)
Solid effects (7-8)
Strobe effects (9-11)
Flicker effects (12-13)
Constant Glow (14)
Distort & Hologram (15-16) ✔* ✔* ✔* ✔* ✔* [Note 1]
Bulge Sideways (18) [Note 2]
Glow shell (19) ✔* ✔* ✔* ✔* ✔* [Note 3]
Notes:
  1. Modes other than normal has additional opacity distortions.
  2. Loops (frozen entities are stuck in wide mode).
  3. FX Amount also controls offset of glow aura from model, clashing with non-normal render modes.

Sprites

Render Mode Render Amount Render Color Black part of additive sprites
Normal (0) No effect Tint colour Opaque
Color (1) Fully opaque if >0 No effect Opaque
Texture (2) Opacity Tint colour Opaque
Glow (3) Opacity Tint colour Transparent
Solid (4) Opacity Tint colour Opaque
Additive (5) Opacity Tint colour Transparent
Considering most sprites are additive type, only Additive (or Glow) modes should be considered in typical use cases.

Colour tinting works by multiplying the sprite's base colour with the Render Color value. Suppose a pixel on the sprite has the colour ■magenta and the Render Color is ■yellow, then the resulting colour is:
// values converted to 0-1 range to
// simplify this example calculation
  R   G   B
  1.0 0.0 1.0  // base colour
x 1.0 1.0 0.0  // rendercolor
  ═══════════
  1.0 0.0 0.0  // output
which is ■red.

See also: env_sprite's page.
Render FX Normal Color Texture Glow Solid Additive Remarks
Normal (0) N/A N/A N/A N/A N/A N/A
Pulse effects (1-4)
Fade effects (5-6)
Solid effects (7-8)
Strobe effects (9-11)
Flicker effects (12-13)
Constant Glow (14) [Note 1]
Distort & Hologram (15-16)
Bulge Sideways (18)
Glow shell (19)
Notes:
  1. Cancels out glow mode's distance-based dissipation effect. No special effects otherwise.

env_render

Main page: env_render

The env_render entity allows you to change the rendering properties of entities in game. This gives you greater control over the visual properties of entities as the player progresses through the level, more than the basic toggling of func_wall_toggle which you can't do to something like a func_train.
It can be used to cleverly script brush entities, for example having a tank made of func_train move into position, then swapping it with a stationary func_wall and a functional func_tank turret on top, all by firing env_render entities targeting those entities with specific render property values.

Examples

Making a hologram and a real fence

You might have noticed that in some areas in Half-Life, there are fences that the player can shoot through. It's a simple idea, but it requires a little trick to set up.

You will notice that some entities, including the monster_generic ones that are in the example map as holograms, have a flag called Not Solid that allows you to let the player to walk through them. This has obvious uses, such as... well... for making a hologram. But it won't work for fences, because, firstly, func_wall entities don't have a Not Solid flag, and even if they did, the player would be able to move though as well as bullets. But there is a way round this problem.

It just so happens that func_illusionary was designed to be, um, illusionary, so it's basically a non-solid func_wall, and can be made to display masked textures in the same way as a normal func_wall. Then, to stop the player moving though, you can simply create a 'clip' brush - Select the texture called User posted image CLIP, and create a brush. This stops the player moving through, but not bullets... and not monsters. To stop the monsters, create another brush with User posted image AAATRIGGER texture, and bind it to a func_monsterclip entity. Place all three brushes over each other, and you have a 'real' fence!
Holographic.Holographic.

3 Comments

Commented 11 years ago2013-03-27 22:16:37 UTC Comment #100493
About the FX Color part - English is not the same as american
Commented 4 years ago2020-04-30 21:26:25 UTC Comment #102695
Render mode Color , or Pure Color in cs hex fgd , must be used with an "visible" texture. If an "invisible" texture is used like null, bevel, or even aaatrigger, the compiler will make it drawn invisible. aaatriger for example works in the oldest tool set and maybe in zoner tools 3.4 but definitely not in vhlt tools as it removes these entities visually.
Best to keep it a non special texture for it to work properly.
Commented 3 months ago2024-08-07 16:20:12 UTC Comment #106288
I feel like migrating the stuff I added to env_render page here, and redirect from that page, but I'm undecided on how much I should rewrite the original content of this page, and even who the original author to be credited is, because the entire page content will need to be reworked to properly label and address bmodel/studiomodel/sprite differences.

You must log in to post a comment. You can login or register a new account.