Relintai/godot-lportal
1
0
Fork 0
mirror of https://github.com/Relintai/godot-lportal.git synced 2024-11-23 05:17:20 +01:00
Code Issues Packages Projects Releases Wiki Activity

Update INSTRUCTIONS.md

Browse Source
This commit is contained in:
lawnjelly 2020-01-09 13:47:25 +00:00 committed by GitHub
parent e26f230c45
commit 46371dbe63
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 4 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
INSTRUCTIONS.md
View File

@ -16,9 +16,11 @@ https://www.youtube.com/watch?v=8xgb-ZcZV9s
* Easy to iterate levels (re-exporting full levels from e.g. blender after editing)
* Fast (good algorithms, no dynamic allocation and cache friendly)
As with most room portal systems, LPortal works better if rooms are convex. Most portal systems require you to specify the convex hull (bound) for each room. In LPortal this is optional. The convex hull is only required for calculating the 'start room' of a dynamic object when you either initially place it (dob_register), or teleport it (dob_teleport). As such, both of these functions have an alternative hint version where the user can specify the start room manually. This is possible in some simpler designs of games, and avoids the laborious need to model room bounds (convex hulls).
As with most room portal systems, LPortal works better if rooms are convex. Each room has a convex hull bound. This can either be auto generated from the room geometry by LPortal, or you can manually supply a bound shape.
If you are exclusively using the hint commands, and not creating bounds, there is strictly speaking no longer a requirement for the rooms to be convex, they can be concave shapes. This allows considerable flexibility in level design. HOWEVER, the portals should be placed such that no portal is in front of the portal plane of another portal in the room. I.e. the portals themselves should form some kind of convex structure.
The convex hull is only required for calculating the 'start room' of a dynamic object when you either initially place it (dob_register), or teleport it (dob_teleport). Both of these functions have an alternative hint version where the user can specify the start room manually, this can be more efficient and accurate in some cases, but usually the convex bounds will work fine.
If you are exclusively using the hint commands, and not creating bounds, there is strictly speaking no longer a requirement for the rooms to be convex, they can be concave shapes. This allows considerable flexibility in level design. HOWEVER, the portals should be placed such that no portal is in front of the portal plane of another portal in the room. I.e. the portals themselves should form some kind of convex structure. This is because for efficiency reasons, LPortal keeps track of the room that DOBs are within by monitoring them for crossing portal planes. If they cross a portal plane, by definition, they have entered the neighbouring room.
## Overview
The first thing you may notice is that LPortal doesn't make much use of special features within the editor, and simply relies on careful naming of spatials (or Empties within Blender). There is one new node type, 'LRoomManager', which behaves pretty much as any spatial however it has some added functions and runs an entire visibility system under the hood.