Brainstorming: Segment-Portals definition

chamile · **Joined:** Thu Sep 09, 2010 5:47 am **Posts:** 17

This topic is about collecting ideas and requirements for the portalengine of the game. The goal is to generate a xml structure which contains several definitions of segments and containing portals.
The base of the definitions is a segment. For this we define entities inside. The xml file should not contain geometrical data such as polygons, meshes or vertices. An exception must be made for portals, these must contain geometrical data.
So first we need to determine which entities exist:

Entity types:
- room (part of a section)
- door (allow/deny access to a portal)
- portal (a transition point to another segment)

Next we have basic data for each entity:
- position in the segment - 3D coordinate
- direction of the entity - 3D vector

And we need special data for each entity:
...todo... (first determine all types of entities)

current state:

Code:

(element) segment-list (segment+)

(element) segment (portal+, entity+)
- (attr) name (required) string

(element) entity (model, door) - contains any object
- (attr) class (required) string - class/group of entity
- (attr) name (required) string - a name to identify it
- (attr) pos (required) 3DPoint - position point relative to segment 
- (attr) dir (required) 3DVector - alignment/direction as vector
- (attr) state (optional) bool - object is initial on or off (on if missing)

(element) model - data of a model file conected with an entity
- (attr) file (required) string - name of file to be loaded
- (attr) scale (optional) double - scaling of model (1 if missing)
- (attr) pos (optional) 3DPoint - position of model (0,0,0 if missing)
- (attr) dir (optional) 3DVector - direction of model (1,1,1 if missing)

(element) door - door data if entity class is "door"
- (attr) portal (required) string - name of the portal that is connected with this door
- (attr) target (required) string - name of the segment and door in this segment this door is connected to (example: "seg0:door1")
 
(element) portal (shape) - defintion of a portal
- (attr) class (required) string - class/group of portal
- (attr) name (required) string - a name to identify it
- (attr) target (required) string - name of the segment and portal in this segment this portal is linked to (example: "seg0:portal1")

(element) shape - defintion of portal geometry
- (text) - list of vertices (simply all edge points in a row like "1,1,0 -1,1,0 -2,-2,0 1,-1,0" must be in the same plane)  

entity classes

Code:

- empty - default room entity
- solid - a single object
- door - a door
- group - ?

feel free to add or modify

Alesto · **Joined:** Mon Jan 12, 2009 11:07 am **Posts:** 104

Alright I would begin. I'll try to approach the functionalities of the current state of our portal engine.

An example of a proposed Geo File:

Code:

<?xml version="1.0" encoding="utf-8"?>
<map version="0">
  <!-- A few declarations to be mentioned here ... -->

  <!-- Templates to be mentioned here ... -->

  <segment-list start="seg0">
    <!-- All segments are listed here -->
    <segment name="seg0">
      <!-- Definition of a segment: -->

      <!-- Predefined portals to other segments listed here -->
      <portal name="optional_name" pos="x:y:z" orient_angles="r:p:y" state="on">
        <!-- Alternatively orient_matrix="..." to orient_angles.
             The name is optional. State is by default "on" -->

        <!-- Definition of this portal: -->
        <shape>
          <!-- Vertices entered in format "x1:y1:z1 x2:y2:z2 x3:y3:z3 ..." -->
          <!-- IMPORTANT: all vertices should be on the same plane! -->
          1:0:0 1:1:0 1:1:1 1:0:1
        </shape>

        <bind-direct seg="seg1" pos="x:y:z" orient_angles="r:p:y" />
        <!-- Alternatively orient_matrix="..." to orient_angles.
             This tag is optional, if missing, the portal will remain unbound and can be bound later.
             A given name for the portal is mandatory in this case. -->
        <!-- alternative tag is <bind-endian to="other_segment::endian_name">, binding a portal to a predifined endian -->
      </portal>
      <!-- ... more portals ... -->

      <!-- Some portals may be unbound or may be bound by <bind-endian> allowing the game to change their binding state -->
      <portal-endian name="endian1" pos="x:y:z" orient_angles="r:p:y" />
      <!-- Portal endian accepted by <bind-endian> tags above. The name is required -->
      <!-- ... more portal endians ... -->

      <!-- Entities listed here: -->
      <entity class="solid" name="optional_name" pos="x:y:z" orient_angles="r:p:y" state="on">
        <use-model file="model.WMB" scale="1.0" offset_pos="x:y:z" offset_orient_angles="r:p:y" />
        <!-- or models in other formats like .bsp(quake3 bsp model) .bod(X3 Reunion model) .scm(Simerge compiled model)
             scale, offset_pos, offset_orient_angles and offset_orient_matrix are optional -->
      </entity>
      <entity class="door" name="optional_name" pos="x:y:z" orient_angles="r:p:y" state="on">
        <!-- door specific parameters -->
        <use-model file="doorwing.WMB" />
        <use-portal portal="a_portal_with_endian_name" />
        <!-- Portals are optional here. When given, a given portal will be switched on or off, depending on the door state.
             Recomended to use, because it can improve rendering performance. -->
        <use-dummy name="other_segment::door_dummy_entity" />
        <!-- Dummies are needed to make the door visible at the
             other segment even if the portal state is "off".
             Otherwise the door won't be shown at other segment -->
      </entity>
      <entity class="group" name="optional_name" pos="x:y:z" orient_angles="r:p:y" state="on">
        <!-- This entity contains a segment in itself. -->
        <!-- Definition of a segment follows here! ... -->
      </entity>
      <!-- ... more entities here ... -->

    </segment>
    <!-- ... more segments here ... -->

  </segment-list>
</map>

I don't regard portals as entities, because in the engine a portal object isn't derived from TSceneObject as Entities do. Some entities can contain sub entities (same case as in Ogre the scene nodes). In this case they become segments by themselves. These kind of entities aren't that uncommon. For example a human entity which is carrying weapons(sub entities). Even if this sounds a little unintuitive, but by definition a segment is a simple container for entities and portals.

I didn't offer much documentation. So don't be afraid to ask, what all this means above.

EDIT: I was lying that portal endians are required for doors and docking. Both are working well without them. Endians are not a mandatory feature in common.

Deus Ars · **Joined:** Wed Sep 08, 2010 2:06 am **Posts:** 11

I have a couple general questions:

1) Isn't there already existing open, standard formats that have these features and well developed tools associated with them. Like those maybe used by dedicated 3D engines like OGRE, Crystal Space, IRRLicht, Panda3D, etc.? And perhaps Simerge will use one of these for it's graphics engine anyway at some point in the future?

2) Could it be more flexible and appropriate to the typical environments of Simerge to use Antiportals instead of portals for culling? What if a scene is densely packed with futuristic skyscrapers or trees? Or if you wanted to make enclosed environments out of destructible walls? Wouldn't the most fitting way to optimize these kinds of scenes be to make these objects within it explicit occluders?

Alesto · **Joined:** Mon Jan 12, 2009 11:07 am **Posts:** 104

to 1: Not that I know, there would be a format.

to 2: Antiportals have a complete different functionality. I think they won't be supported. Very possible we will go into hardware occlusion culling instead of antiportals. This technique is used everywhere (eg. in Crysis). It is faster and simple.

For portals. They aren't only geometry cullers, they are required for scene organization, too. They connect two independent segments with each other where any of them has his own coordinate origin and orientation. Then a portal translates one coordinate system into another one. This way for example the interior of a ship is moving automatically with the ship itself and this way the engine can integrate the interior of the ship very quickly into the interior of a station when docked.

chamile · **Joined:** Thu Sep 09, 2010 5:47 am **Posts:** 17

ok, I would suggest following structure:

Code:

<segment ...>
   <portals>
      <portal ... >
      <portal ... >
      <portal ... >
   </portals>   
   <entities>
      <entitiy ... >
      <entitiy ... >
      <entitiy ... >
   </entities>
</segment>

All portals and entities are listed simply without directly put them in a hierarchy. So we need to give every item an identifier (which can be a local one for the parent segment) to identify it. I think this is easier than have an entity of an entity of an entity of a segment. We also could leave out the portals and entities container-tag, this can both be read in a simple way by tinyxml but will reduce filesize when the xml is "pretty printed".

another question is if we wanna have multiple segments in one file (I assume YES), then I would add a root element which contains the segment list

Alesto · **Joined:** Mon Jan 12, 2009 11:07 am **Posts:** 104

Alesto wrote:

another question is if we wanna have multiple segments in one file (I assume YES), then I would add a root element which contains the segment list

Yes, there should be multiple segments packed inside. To define the root segment ("root" is possibly wrong name. Segment bindings are represented by a network instead of a tree) I used the attribute "start" in the tag <segment-list>

Alesto wrote:

All portals and entities are listed simply without directly put them in a hierarchy. So we need to give every item an identifier (which can be a local one for the parent segment) to identify it. I think this is easier than have an entity of an entity of an entity of a segment.

A confusing nesting could occure by entities of type "group" or a few other not mentioned types (derived by TCombinedObject). You mean to do it as following?

Code:

<segment-list ...>

  <segment name="seg0">
    <portals>
      <portal ... >      
      <portal ... >      
      <portal ... >      
      <portal ... >      
    </portals>
    <entities>
      <entity ... >
      <entity ... >
      <entity ... >
      <entity ... > 
    </entities>
  </segment>

  <segment name="seg1">
    <portals>
      <portal ... >      
      <portal ... >      
      <portal ... >      
      <portal ... >      
    </portals>
    <entities>
      <entity ... >
      <entity ... >
      <entity ... >
      <entity ... >      
      <entity class="group" name="optional_name" pos="x:y:z" orient_angles="r:p:y" state="on">
        <embed-segment target="seg0" />
      </entity>
    </entities>
  </segment>

</segment-list>

chamile wrote:

We also could leave out the portals and entities container-tag, this can both be read in a simple way by tinyxml but will reduce filesize when the xml is "pretty printed".

I didn't use these tags in my first example above.

chamile · **Joined:** Thu Sep 09, 2010 5:47 am **Posts:** 17

Ok, I see we need do clarify a very basic question before: Do we create a xml structure out of our own requirements or do we reuse the example you made above?

Alesto · **Joined:** Mon Jan 12, 2009 11:07 am **Posts:** 104

chamile wrote:

Ok, I see we need do clarify a very basic question before: Do we create a xml structure out of our own requirements or do we reuse the example you made above?

We create an xml out of our own. I present an example which could cover most functionalities in our existing portal engine. You could decide how to implement it best as you're the one who writes the parser

chamile · **Joined:** Thu Sep 09, 2010 5:47 am **Posts:** 17

Then we are synchronized again

The fact about leaving the portals and entities tags was not related to your example it was related to mine. You could also write everything behind one tag:

<portal ... >
<portal ... >
<portal ... >
<entity ... >
<entity ... >
<entity ... >
<portal ... >
<portal ... >
<entity ... >
...

This creates no more effort in parsing. Advantage: smaller files! Disadvantage: possibly not good readable. But this is cosmetic and can also be changed with very low effort.

Another question: "embed-segment" is for what?

Alesto · **Joined:** Mon Jan 12, 2009 11:07 am **Posts:** 104

embed-segment attaches a segment content into a local space of an entity (derived from TCombinedObject). Like in Ogre a scenenode can have subnodes the same case is represented here. A typical example would be a car with attached passengers.

Simerge spacegame

Brainstorming: Segment-Portals definition

Who is online