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:42] muffin |
hpl1:documentation:content.creation.document.chap3 [2020/02/09 13:48] (current) muffin [3.14 Particle Systems] |
||
|---|---|---|---|
| Line 27: | 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&}}]] | ||
| - | <code> | ||
| - | \\ | ||
| ==== 3.2 Portals ==== | ==== 3.2 Portals ==== | ||
| - | </code> | ||
| A Portal is a rectangle that defines the connection between two rooms. A portal must be a one-sided rectangle and cover the hole between two rooms completely. It is not a problem if the portal is bigger than the hole, but it should fit a good as possible. This means that a hole between two rooms can be a round, triangular or any arbitrary form. A rectangle must still be used even if the hole is not rectangular and the hole must be covered 100% even if the fit does not get perfect.\\ | A Portal is a rectangle that defines the connection between two rooms. A portal must be a one-sided rectangle and cover the hole between two rooms completely. It is not a problem if the portal is bigger than the hole, but it should fit a good as possible. This means that a hole between two rooms can be a round, triangular or any arbitrary form. A rectangle must still be used even if the hole is not rectangular and the hole must be covered 100% even if the fit does not get perfect.\\ | ||
| Line 151: | Line 148: | ||
| References are used to add external objects to the map. | References are used to add external objects to the map. | ||
| - | When referencing to an object you **must** use a special reference file and it is **very important** that the file only contains **one** object. If not the referencing will fail. This special reference file will be called **reference object** (and nothing else) for the duration of this chapter. | + | When referencing to an object you **must** use a special reference file and it is **very important** that the file only contains **one** object. If not the referencing will fail. This special reference file will be called **reference object** (and nothing else) for the duration of this chapter. |
| Another extremely important thing is that the reference object looks exactly the same in size and placement as the file you want to reference to. It may not contain any rotation, scale or translation and if the model needs to have an offset the it is very important that the pivot is at (0,0,0) in the reference object. When you reference to a file the engine will place the referenced file with its origo at the reference object’s pivot. This is one reason why you should always try to center your object in the model file. | Another extremely important thing is that the reference object looks exactly the same in size and placement as the file you want to reference to. It may not contain any rotation, scale or translation and if the model needs to have an offset the it is very important that the pivot is at (0,0,0) in the reference object. When you reference to a file the engine will place the referenced file with its origo at the reference object’s pivot. This is one reason why you should always try to center your object in the model file. | ||
| - | __**Maya references**__ \\ In the options for “create reference” lock and group must be unchecked. When creating further copies of the reference remember to have set to instancing in “duplicate” options. Also turn off namespaces and be sure to name the node in the reference object correctly and with a unique name! | + | __**Maya references**__ \\ |
| + | In the options for “create reference” lock and group must be unchecked. When creating further copies of the reference remember to have set to instancing in “duplicate” options. Also turn off namespaces and be sure to name the node in the reference object correctly and with a unique name! | ||
| - | __**Max Xref**__ \\ Simply create an xref to the reference object. | + | __**Max Xref**__ \\ |
| + | Simply create an xref to the reference object. | ||
| + | |||
| + | __**Naming**__ \\ | ||
| + | NOTE: When naming the several grouped objects, it is the group that must be named! You can also create references by just importing normal geometry and naming it correctly (note that the imported geometry only should be one object or several objects in group). The syntax is the following:\\ | ||
| + | **_ref_[file]_[name]** | ||
| - | __**Naming**__ \\ NOTE: When naming the several grouped objects, it is the group that must be named! You can also create references by just importing normal geometry and naming it correctly (note that the imported geometry only should be one object or several objects in group). The syntax is the following: \\ **_ref_[file]_[name]** | ||
| |**file** |The entity file to load. This may contain “_” and must not contain any extension (i.e. “.ent”). | | |**file** |The entity file to load. This may contain “_” and must not contain any extension (i.e. “.ent”). | | ||
| |**name** |The name of the object in the game world. | | |**name** |The name of the object in the game world. | | ||
| - | Example: \\ **_ref_wooden_box01_Box01** \\ This will create an entity for the file “wooden_box01.ent” and it will have the name “Box01”. | + | Example:\\ |
| + | **_ref_wooden_box01_Box01** \\ | ||
| + | This will create an entity for the file “wooden_box01.ent” and it will have the name “Box01”. | ||
| Below are descriptions of the different reference types. (Read this as if there is only one type of object you can reference to and that is the **entity**.) | Below are descriptions of the different reference types. (Read this as if there is only one type of object you can reference to and that is the **entity**.) | ||
| Line 171: | Line 175: | ||
| === 3.4.1 Static models === | === 3.4.1 Static models === | ||
| - | **Do not read this! This is only for the programmer’s reference. Ignore as if it didn’t exist!** \\ //The name of the reference has the prefix “static_”. This should only be used for animated static geometry on the map such as fans, machinery, etc. For non animated static geometry normal geometry should be used. The animation for these models must not change during run time and they must be placed in such a way that they never touch more rooms during animation then they do in bind pose. The referenced Maya .mb file must have the same name as the model file (.msh, .dae, etc) that you want added to the map.// | + | **Do not read this! This is only for the programmer’s reference. Ignore as if it didn’t exist!** \\ |
| + | //The name of the reference has the prefix “static_”. This should only be used for animated static geometry on the map such as fans, machinery, etc. For non animated static geometry normal geometry should be used. The animation for these models must not change during run time and they must be placed in such a way that they never touch more rooms during animation then they do in bind pose. The referenced Maya .mb file must have the same name as the model file (.msh, .dae, etc) that you want added to the map.// | ||
| === 3.4.2 Entities === | === 3.4.2 Entities === | ||
| The name of the reference doesn’t need any prefix. Any name will do. These are things like monsters, item, etc. It is what ever the game wants them to be. These references (the referenced .mb file name) do not refer to model files but rather an entity file. The entity has the extension “.ent” and is a simple text XML file. This xml file can contain info that is mostly game specific. | The name of the reference doesn’t need any prefix. Any name will do. These are things like monsters, item, etc. It is what ever the game wants them to be. These references (the referenced .mb file name) do not refer to model files but rather an entity file. The entity has the extension “.ent” and is a simple text XML file. This xml file can contain info that is mostly game specific. | ||
| - | //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 [[:hpl1:documentation:content.creation.document.chap6#entity_files|entity files]]. | More on this in [[:hpl1:documentation:content.creation.document.chap6#entity_files|entity files]]. | ||
| - | <code> | ||
| - | \\ | ||
| ==== 3.5 Name parameters ==== | ==== 3.5 Name parameters ==== | ||
| - | </code> | ||
| - | Because some options are unavailable (or unexportable) in 3D editors, some settings have to be set by adding certain text to the names of objects. A parameter is written with a “_” in front of it and **can not** be the first text in the name. For example: | + | Because some options are unavailable (or unexportable) in 3D editors, some settings have to be set by adding certain text to the names of objects. A parameter is written with a “_” in front of it and **can not** be the first text in the name. For example: |
| - | “Ball04_noshadow_nocollide” \\ “Ball04_noshadow_” \\ are both legal. \\ \\ “_nocollide_Ball04” is **not legal!** But you can write ““nocollide_Ball04” by **exluding the _**. \\ The following is a list of the parameters all objects types can have. | + | “Ball04_noshadow_nocollide”\\ |
| + | “Ball04_noshadow_”\\ | ||
| + | are both legal.\\ | ||
| + | \\ | ||
| + | “_nocollide_Ball04” is **not legal!** But you can write ““nocollide_Ball04” by **exluding the _**.\\ | ||
| + | The following is a list of the parameters all objects types can have. | ||
| Geometry / References: | Geometry / References: | ||
| Line 202: | 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 ==== | ||
| Line 344: | 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: | ||
| **_ps_[particle system name]_[name]** | **_ps_[particle system name]_[name]** | ||
| + | |||
| |**particle system name** |Entity file containing data about the billboard, may contain “_”. | | |**particle system name** |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. | | ||
| Particle systems are created with the Particle Editor, which is [[:hpl1:documentation:particle_editor_document|documented here]] and a tutorial is [[:hpl1:tutorials:tutorial_4_-_particles|available here]]. | Particle systems are created with the Particle Editor, which is [[:hpl1:documentation:particle_editor_document|documented here]] and a tutorial is [[:hpl1:tutorials:tutorial_4_-_particles|available here]]. | ||
| + | |||
| + | \\ | ||
| ==== 3.15 Workflow ==== | ==== 3.15 Workflow ==== | ||
hpl1/documentation/content.creation.document.chap3.1581255728.txt.gz · Last modified: 2020/02/09 13:42 by muffin
