Editing Rooms and Portals

Example SceneTree

Putting all the ideas together, here is an example scene tree:

• RoomGroup to denote an outside area.
• MeshInstances inside the Rooms are either STATIC or DYNAMIC.
• Spatial (I decided to call it ‘Freeform’, but you could use any name) under which to place STATIC and DYNAMIC objects that will be autoplaced in rooms (Freeform is inside the roomlist, but not inside a room.)
• OUTSIDE the roomlist.
• ROAMING so they can be in any room.
• roomlist.

  Creating room systems in Blender (or other modeling tools)

  Although you can create your room system entirely within the editor, you can also build rooms and portals within your modeling tool. There is one small snag - modeling tools such as Blender have no knowledge of Room, RoomGroup and Portal nodes. In order to work around this we use a series of naming conventions. The first time Godot encounters these specially named nodes, it will convert them into Rooms, RoomGroups and Portals.

  Postfix convention

• -room becomes a Room.
• -roomgroup becomes a RoomGroup.
• -portal becomes a Portal.
• -bound becomes a manual bound. -room Empty will thus be placed in the Room during conversion in Godot. For example:
• kitchen-room - create a Room called “kitchen”.
• outside-roomgroup - create a RoomGroup called “outside”.
• kitchen-portal - create a Portal leading to the “kitchen” Room.

  Portals

  Portals are different from Rooms. In Portals, we need to specify the geometry of the Portal in our modelling tool, in addition to just the name. To do this your “portal-to-be” should be created as a Mesh. Portal node, the snapping to the portal plane is enforced, and the vertices are specified (and editable) as 2D coordinates in the inspector, rather than 3D points. -portal which will attempt to autolink the Portal in Godot, or you can use the name of the Room you wish to link the Portal to as a prefix.

  Wildcard

  kitchen-portal. However, there is one problem. Blender and Godot do not deal well when you have multiple objects with the same name. What happens when we want more than one Portal to lead to the kitchen? wildcard character, *. When Godot reads the wildcard, it will ignore anything placed after it in the name. This means we can use the following portal names:
• kitchen*1-portal - creates a Portal leading to the “kitchen”.
• kitchen*2-portal - also creates a Portal leading to the “kitchen”.
• kitchen*anything_you_want_here-portal - also works. Wildcards work on all of the nodes which use these naming conventions.

  Manual bounds

  Manual bounds are a way of explicitly setting the convex hull for a room, and are used if they are present as children of a room in the scene tree. Aside from the postfix, the naming is unimportant. They should be meshes (i.e. MeshInstance in Godot). Bear in mind they will be converted to convex hulls during the conversion process, so they don’t have to be perfect. Tip IGNORE Portal Mode and won’t be shown. You can alternatively use Generate Points within the editor to convert these to a set of points stored in the room, and delete the original -bound MeshInstance.

  Portal point editing

  Portals are defined by a combination of the transform of the portal node, and by a set of points which form the corners. The default portal has 4 corners as shown in the inspector: You can edit these points in the gizmo or inspector to make a better match to the opening in your game level. It’s generally better to keep the number of points as low as possible for the efficiency of the system. For example, it’s better to risk rendering a little too much than to spend the time culling objects at 20 different edges.

  Room point editing

  Generate Points button in the editor toolbar when a room is selected. This will transfer the auto bound from the geometry (or manual -bound mesh) into the inspector. Once there are points in the inspector, they will be used and override any other method. So if you wish to revert your manual editing, delete all the room’s points. quite get the right result you want. It is usually a good idea to use a lot of Simplification in the inspector for the Room before generating the points. Be aware though that by default, the Simplification value will be inherited from the RoomManager.

  RoomManager

  Show Debug

  false on exported projects.

  Debug Sprawl

  Portal Margin is for.

  Merge Meshes

  STATIC meshes within a room (also known as static batching). This can increase performance in many cases. The culling accuracy is reduced, but as a room is a fairly logical unit for culling, this trade off usually works in your favor.

  Plane Simplification

  0 (no simplification) and 1 (maximum simplification). You can also override this value in individual rooms.

  Portals

  Portal Active

  Portals can be turned on and off at runtime. This is especially useful if you have doors that can open and close.

  Two Way

  Portals can either be two-way or one-way. The default two-way portals are quicker to set up in most circumstances, but one-way portals can be useful in some cases. For example, you can use one-way portals to create windows that can be seen out of, but not seen into. This can help performance when viewing buildings from outdoors.

  Particle Systems

  STATIC particle systems, the AABB on conversion may have zero size. This means the particle system may be unexpectedly culled early. To prevent this, either set the particle system portal mode to DYNAMIC, or alternatively, add an Extra Cull Margin to the particle system in the Geometry Inspector.

  Multimeshes

  Note that multimeshes will be culled as a group, rather than individually. You should therefore attempt to keep them localised to the same area wherever possible.