hpl1:documentation:content.creation.document.chap3
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
hpl1:documentation:content.creation.document.chap3 [2020/02/09 13:31] muffin [3.4 References] |
hpl1:documentation:content.creation.document.chap3 [2020/02/09 13:48] (current) muffin [3.14 Particle Systems] |
||
|---|---|---|---|
| Line 9: | Line 9: | ||
| 3. For each portal that can be seen, the engine checks what room the portal connects to and then it places this room in a render list (if the room is all ready in the list, it is skipped). | 3. For each portal that can be seen, the engine checks what room the portal connects to and then it places this room in a render list (if the room is all ready in the list, it is skipped). | ||
| - | 4. In the connected room the engine checks what portals the portal that lead to this room can see, then checks if they are in the field of view of the camera. If a portal is claimed visible then it is looped from point 3. This continues until no portals are left to check.\\ | + | 4. In the connected room the engine checks what portals the portal that lead to this room can see, then checks if they are in the field of view of the camera. If a portal is claimed visible then it is looped from point 3. This continues until no portals are left to check. |
| ==== 3.1 Rooms ==== | ==== 3.1 Rooms ==== | ||
| Line 26: | Line 27: | ||
| [[https://wiki.frictionalgames.com/_detail/hpl1/documentation/bounding_example.jpg?id=hpl1:documentation:content.creation.document.chap3|{{https://wiki.frictionalgames.com/_media/hpl1/documentation/bounding_example.jpg?nolink&}}]] | [[https://wiki.frictionalgames.com/_detail/hpl1/documentation/bounding_example.jpg?id=hpl1:documentation:content.creation.document.chap3|{{https://wiki.frictionalgames.com/_media/hpl1/documentation/bounding_example.jpg?nolink&}}]] | ||
| - | \\ | ||
| ==== 3.2 Portals ==== | ==== 3.2 Portals ==== | ||
| Line 42: | Line 42: | ||
| The following optional texts are numbers of portals which can be seen from this portal. I.e.: “_portal4_room3_2_34” connects to “_room3” and in room 3 the portals 2 and 34 can be seen. “Can be seen” means that if you where to peak through the portal there is someway that these portals could be visible.\\ | The following optional texts are numbers of portals which can be seen from this portal. I.e.: “_portal4_room3_2_34” connects to “_room3” and in room 3 the portals 2 and 34 can be seen. “Can be seen” means that if you where to peak through the portal there is someway that these portals could be visible.\\ | ||
| - | [[https://wiki.frictionalgames.com/_detail/hpl1/documentation/portal03.jpg?id=hpl1:documentation:content.creation.document.chap3|{{https://wiki.frictionalgames.com/_media/hpl1/documentation/portal03.jpg?nolink&}}]]\\ | + | [[https://wiki.frictionalgames.com/_detail/hpl1/documentation/portal03.jpg?id=hpl1:documentation:content.creation.document.chap3|{{https://wiki.frictionalgames.com/_media/hpl1/documentation/portal03.jpg?nolink&}}]] |
| In the image above the circumstances are as follows: | In the image above the circumstances are as follows: | ||
| - | * | + | * Room 2 - Portal 1 can see portal 2. |
| - | + | * Room 3 - Portal 1 can see portal 1 and 3. | |
| - | Room 2 - Portal 1 can see portal 2. | + | * Room 4 - Portal 1 can see portal 2. |
| - | + | * The portals in room 1 can see no other portals. | |
| - | * | + | |
| - | + | ||
| - | Room 3 - Portal 1 can see portal 1 and 3. | + | |
| - | + | ||
| - | * | + | |
| - | + | ||
| - | Room 4 - Portal 1 can see portal 2. | + | |
| - | + | ||
| - | * | + | |
| - | + | ||
| - | The portals in room 1 can see no other portals. | + | |
| The names for the portals will be the following: | The names for the portals will be the following: | ||
| - | * | + | * **Room 2 - Portal 1:** “_portal1_room1_2” |
| - | + | * **Room 3 - Portal 1:** “_portal1_room1_1_3” | |
| - | **Room 2 - Portal 1:** “_portal1_room1_2” | + | * **Room 4 - Portal 1:** “_portal1_room1_2” |
| - | * | + | |
| - | + | ||
| - | **Room 3 - Portal 1:** “_portal1_room1_1_3” | + | |
| - | * | + | |
| - | + | ||
| - | **Room 4 - Portal 1:** “_portal1_room1_2” | + | |
| The portals in room 1 will have the following names: | The portals in room 1 will have the following names: | ||
| - | * | + | * **Portal 1:** _portal1_room2 |
| - | + | * **Portal 2:** _portal2_room3 | |
| - | **Portal 1:** _portal1_room2 | + | * **Portal 3:** _portal3_room4 |
| - | * | + | |
| - | + | ||
| - | **Portal 2:** _portal2_room3 | + | |
| - | * | + | |
| - | + | ||
| - | **Portal 3:** _portal3_room4 | + | |
| Note that the sketch of the portal connections does not have a good design since the bounding boxes of the rooms overlap! This should be avoided if possible (and in the currently version overlapping bounding boxes will probably lead to bugs.) | Note that the sketch of the portal connections does not have a good design since the bounding boxes of the rooms overlap! This should be avoided if possible (and in the currently version overlapping bounding boxes will probably lead to bugs.) | ||
| Line 94: | Line 71: | ||
| As seen in the image above the player is inside the bounding box of the purple room as well so it doesn’t have to have to see the portal. The dark yellow rectangle is where the portal in the purple would be placed. | As seen in the image above the player is inside the bounding box of the purple room as well so it doesn’t have to have to see the portal. The dark yellow rectangle is where the portal in the purple would be placed. | ||
| - | Note that that the three images above all show bounding boxes and **not** room geometry! Another thing to note is that overlapping bounding boxes should be avoided when possible since it can result in a lot of unnecessary rooms being rendered. When creating maps remember to press 2 in the map viewer to debug and optimize portals and rooms. \\ | + | Note that that the three images above all show bounding boxes and **not** room geometry! Another thing to note is that overlapping bounding boxes should be avoided when possible since it can result in a lot of unnecessary rooms being rendered. When creating maps remember to press 2 in the map viewer to debug and optimize portals and rooms. |
| ==== 3.3 Lights ==== | ==== 3.3 Lights ==== | ||
| Line 118: | Line 95: | ||
| If the light casts shadows or not is also set by the scale. Scale Z 0 means no shadows are cast and 1 means the light casts shadows. | If the light casts shadows or not is also set by the scale. Scale Z 0 means no shadows are cast and 1 means the light casts shadows. | ||
| - | Falloff is set in the light entity file ([[https://wiki.frictionalgames.com/hpl1/documentation/content.creation.document.chap6#light|light]]). | + | Falloff is set in the light entity file ([[:hpl1:documentation:content.creation.document.chap6#light|light]]). |
| === 3.3.3 Spot Lights === | === 3.3.3 Spot Lights === | ||
| Line 131: | Line 108: | ||
| |**ProjectionFrameTime** |The time in seconds each frame is shown if it is an animation. | | |**ProjectionFrameTime** |The time in seconds each frame is shown if it is an animation. | | ||
| - | Color and Field of View are set as normal. Attenuation is set using scale X. The rest of the attributes are set in the light entity file, [[https://wiki.frictionalgames.com/hpl1/documentation/content.creation.document.chap6#light|light]]. | + | Color and Field of View are set as normal. Attenuation is set using scale X. The rest of the attributes are set in the light entity file, [[:hpl1:documentation:content.creation.document.chap6#light|light]]. |
| **MAYA TIP:** In the light’s locator scale to 55.5 and then set all the scale directions when setting attenuation. Now the arrow of the locator will show the length that light reaches. | **MAYA TIP:** In the light’s locator scale to 55.5 and then set all the scale directions when setting attenuation. Now the arrow of the locator will show the length that light reaches. | ||
| Line 165: | Line 142: | ||
| **dynamic_my_light_file_mylight** \\ This is a dynamic light that loads data from “my_light_file.lnt” and is named “mylight”. | **dynamic_my_light_file_mylight** \\ This is a dynamic light that loads data from “my_light_file.lnt” and is named “mylight”. | ||
| - | **my_light_file_mylight** \\ This is a static light that loads data from “my_light_file.lnt” and is named “mylight”. \\ | + | **my_light_file_mylight** \\ This is a static light that loads data from “my_light_file.lnt” and is named “mylight”. |
| ==== 3.4 References ==== | ==== 3.4 References ==== | ||
| Line 206: | Line 183: | ||
| //As an example//, a _ref_my_woodbox01_box01 reference added in the 3D editor does **not** point to a model file named my_woodbox01.dae/.mb/.3ds etc, it points to a .ent file named my_woodbox01.ent and this file contains the properties, special functions AND also contains information on what model file to use for the reference! | //As an example//, a _ref_my_woodbox01_box01 reference added in the 3D editor does **not** point to a model file named my_woodbox01.dae/.mb/.3ds etc, it points to a .ent file named my_woodbox01.ent and this file contains the properties, special functions AND also contains information on what model file to use for the reference! | ||
| - | More on this in [[:wiki.frictionalgames.com:hpl1:documentation:content.creation.document.chap6#entity_files|entity files]]. | + | More on this in [[:hpl1:documentation:content.creation.document.chap6#entity_files|entity files]]. |
| - | + | ||
| - | \\ | + | |
| ==== 3.5 Name parameters ==== | ==== 3.5 Name parameters ==== | ||
| Line 233: | Line 208: | ||
| |**soundblock** |Sound will be lower through this collider, example: _collider_box_collider1_soundblock. | | |**soundblock** |Sound will be lower through this collider, example: _collider_box_collider1_soundblock. | | ||
| + | |||
| + | \\ | ||
| ==== 3.6 Animations ==== | ==== 3.6 Animations ==== | ||
| Never use animations directly in maps, instead reference to static object or to entities with animations. | Never use animations directly in maps, instead reference to static object or to entities with animations. | ||
| - | |||
| - | ==== ==== | ||
| ==== 3.7 Colliders ==== | ==== 3.7 Colliders ==== | ||
| Line 244: | Line 219: | ||
| Colliders are added in exactly the same way as described in [[:hpl1:documentation:content.creation.document.chap2#colliders|chapter 2.4]]. There are some differences though. One is that all geometry will be turned in to collideable meshes unless the “nocollide” parameter is specified, so if you want to simplify, for example, a statue mesh, the statue mesh must have the “nocollide” argument. | Colliders are added in exactly the same way as described in [[:hpl1:documentation:content.creation.document.chap2#colliders|chapter 2.4]]. There are some differences though. One is that all geometry will be turned in to collideable meshes unless the “nocollide” parameter is specified, so if you want to simplify, for example, a statue mesh, the statue mesh must have the “nocollide” argument. | ||
| - | Another difference is that colliders in a scene (static, imported models) are not linked with any entity like ones in a model file (referenced models) and therefore do not have any physics material linked to them. This means that if you want the collider to have a physics material other than “Default” you **must** assign a material (a material with texture and stuff) to it. This material should then have the physics material you want to use. For example if you want to make a simplified collider for a statue (or maybe several colliders) you should assign the same material as the statue to the collider(s). | + | Another difference is that colliders in a scene (static, imported models) are not linked with any entity like ones in a model file (referenced models) and therefore do not have any physics material linked to them. This means that if you want the collider to have a physics material other than “Default” you **must** assign a material (a material with texture and stuff) to it. This material should then have the physics material you want to use. For example if you want to make a simplified collider for a statue (or maybe several colliders) you should assign the same material as the statue to the collider(s). |
| - | When creating maps there is an **additional collider called “_charcollider”** that can be used. This collider will collide only with the player character, which can be useful if you want to block the players path but not have objects bounce of something invisible. | + | When creating maps there is an **additional collider called “_charcollider”** that can be used. This collider will collide only with the player character, which can be useful if you want to block the players path but not have objects bounce of something invisible. |
| ==== 3.8 Sound Entities ==== | ==== 3.8 Sound Entities ==== | ||
| Line 253: | Line 228: | ||
| **_sound_[entity file]_[name]** | **_sound_[entity file]_[name]** | ||
| - | |||
| |**entity file** |An “snt”-file containing data for the sound. More about this in the [[:hpl1:documentation:content_creation_document#hplhelper|HPLHelper chapter]]. Note that this name may have “_” in it! And DO NOT specify the extension (.snt). | | |**entity file** |An “snt”-file containing data for the sound. More about this in the [[:hpl1:documentation:content_creation_document#hplhelper|HPLHelper chapter]]. Note that this name may have “_” in it! And DO NOT specify the extension (.snt). | | ||
| |**name** |This is what the sound entity will be called in game. | | |**name** |This is what the sound entity will be called in game. | | ||
| - | Examples:\\ | + | Examples: \\ **_sound_test_drops_mysound1** |
| - | **_sound_test_drops_mysound1** | + | |
| This will create a sound entity named “mysound1” that uses the file “test_drops.snt”. | This will create a sound entity named “mysound1” that uses the file “test_drops.snt”. | ||
| - | |||
| - | \\ | ||
| ==== 3.9 Sound blockers ==== | ==== 3.9 Sound blockers ==== | ||
| Line 277: | Line 248: | ||
| **_start_[name]** | **_start_[name]** | ||
| - | |||
| |**name** |The in game name of the start position. May contain “_”. | | |**name** |The in game name of the start position. May contain “_”. | | ||
| Line 291: | Line 261: | ||
| **_area_[type (optional)]_[name]** | **_area_[type (optional)]_[name]** | ||
| - | |||
| |**type** |This is game specific information, should be “script” mostly though. See [[:hpl1:documentation:script_reference|script reference]] for scripts that uses specific types. | | |**type** |This is game specific information, should be “script” mostly though. See [[:hpl1:documentation:script_reference|script reference]] for scripts that uses specific types. | | ||
| |**name** |This is the area the start will have when you try to access it. | | |**name** |This is the area the start will have when you try to access it. | | ||
| Line 297: | Line 266: | ||
| **Types** | **Types** | ||
| - | * script - The regular area type for most scripts. | + | * script - The regular area type for most scripts. |
| * damage - Specfic area to be used with certain scripts dealing with damage to player, entites and objects. Properties set by script. | * damage - Specfic area to be used with certain scripts dealing with damage to player, entites and objects. Properties set by script. | ||
| * liquid - Specific area for setting up liquids(water and so on). Properties set by script. | * liquid - Specific area for setting up liquids(water and so on). Properties set by script. | ||
| Line 318: | Line 287: | ||
| If the area does not have a type then it is only considered an engine area and will not have any game specific propose. | If the area does not have a type then it is only considered an engine area and will not have any game specific propose. | ||
| - | |||
| - | \\ | ||
| ==== 3.12 Billboards ==== | ==== 3.12 Billboards ==== | ||
| Line 326: | Line 293: | ||
| **_bb_[entity file]_[name]** | **_bb_[entity file]_[name]** | ||
| - | |||
| |**entity file** |Entity file containing data about the billboard, may contain “_”. | | |**entity file** |Entity file containing data about the billboard, may contain “_”. | | ||
| |**name** |The name that will be used in game. | | |**name** |The name that will be used in game. | | ||
| Line 386: | Line 352: | ||
| |**EndColor** |“R G B A” Color at end. //Vector4// | | |**EndColor** |“R G B A” Color at end. //Vector4// | | ||
| - | ==== 3.14 Particle Systems ==== | + | ==== 3.14 Particle systems ==== |
| Particle systems are used for effect such as fire, smoke, etc. The syntax for placing a particle system is: | Particle systems are used for effect such as fire, smoke, etc. The syntax for placing a particle system is: | ||
| Line 415: | Line 381: | ||
| * The number of lights is not the biggest problem. The biggest problem is **overlapping** lights. Overlapping means that the bounding boxes from 2 lights intersect. Try to have at most 3 overlapping lights and mostly 2 lights overlapping. If the lights don’t cast shadows it is okay if more lights overlap. | * The number of lights is not the biggest problem. The biggest problem is **overlapping** lights. Overlapping means that the bounding boxes from 2 lights intersect. Try to have at most 3 overlapping lights and mostly 2 lights overlapping. If the lights don’t cast shadows it is okay if more lights overlap. | ||
| * Highpoly meshes should have collisions turned off and use colliders to simulate the shape. | * Highpoly meshes should have collisions turned off and use colliders to simulate the shape. | ||
| - | |||
| - | ==== ==== | ||
| ==== 3.17 Issues ==== | ==== 3.17 Issues ==== | ||
| Line 424: | Line 388: | ||
| * An edge may only have **one** or **two** faces! If this is not followed shadows will be messed up. | * An edge may only have **one** or **two** faces! If this is not followed shadows will be messed up. | ||
| - | \\ | + | \\ |
hpl1/documentation/content.creation.document.chap3.1581255101.txt.gz · Last modified: 2020/02/09 13:31 by muffin
