Map system poll

Indoor map technology is crucial to any game engine - at least if it claims to be multi-purpose.

Therefore the decision for a supported map architecture is an important one. The list of supportable features is long and there are several things to consider.



Map support can be divided into two areas:

  • providing means of creating a map and
  • rendering the map information in the engine itself
    [/list:u]
    Design considerations must cover both areas.

    The poll contains those options which I currently can imagine. These may neither be all possible options nor is a combination of several options unthinkable. Anyways, here is a short description of the options plus the PRO's and CON's as I see them.

    A) Create an own map system
    This means:
    • come up with a list of supported features independently of what already exists
    • define an own map format
    • create map editors, compilers and all other tools which may be necessary during the artwork/design phase of the map
    • implement the classes necessary to render the map in the runtime engine
      [/list:u]

      PRO:
      • Independence
      • Easy design, it's only a single list of features
        [/list:u]
        CON:
        • Amount of work to be done
        • Will we be able to write a map editor which is as good as those already available? In a reasonable amount of time?
          [/list:u]

          B) Choose one existing map system
          In this case we:
          • decide to support a single existing technology
          • write loaders to load map data in this format
          • implement the necessary classes to render this map format
            [/list:u]

            PRO:
            • Less work to be done
            • Also only a single list of features
            • Map editors available
            • No converter necessary
              [/list:u]
              CON:
              • Limited to the feature list of the chosen format
              • If you need a different map format, you'll create a second map system
                [/list:u]


                C) Create own rendering format, provide converters
                This includes:
                • come up with a list of supported features independently of what already exists
                • define an own map format
                • create converters for each editor which shall be supported
                  [/list:u]

                  PRO:
                  • In the renderer, it is a single list of features
                  • Offers use of already existing map editors
                    [/list:u]
                    CON:
                    • It may not be able to create missing features (portals in unorganized data, brushes etc)
                    • Converters may be complex and non-trivial
                      [/list:u]

                      D) Create a pluggable system
                      This option will incorporate:
                      • identify a skeleton for a map rendering system
                      • identify customizable parts in the rendering process like visibility checking/collision detection
                      • define an own map format which contains information about the plugins to use
                      • write simple converters for existing map data, no data enhancement just conversion
                      • implement the necessary skeleton and plugin classes
                        [/list:u]

                        PRO:
                        • Most flexible
                        • Can constantly introduce new features
                        • Does not rely on a single feature list
                          [/list:u]

                          CON:
                          • Complex task
                          • Difficult to check
                          • Will not always create optimal map data
                            [/list:u]

                            I've had a look at quite a few open source engines now, and all 4 options have been used.
                            CrystalSpace e.g. uses option d. They have for example a visibility culling plugin, that can be "standard" or "dynavis". Others like irrlicht follow option b. Q3 obviously is option a.

                            Which direction do we choose? No matter what we decide, note that it will be a fair amount of work which probably should be shared between developers.

I went for the creation of our own rending format. This is because we can integrate it nicely into the .jme format. Also, writing tools for artists to use is a trivial task IMO because I use MaxScript.



It all depends if jME "sponsers" the use of 3dsmax to use as its art source. Much like the unreal engine.



Thats what I would like to see anyways. Also convertors will be supplied via MaxScript too.



And I will be more than happy to create those artists tools and compilers/convertors for max. :slight_smile:



DP

The plug-in philosophy of Crystal Space seems to work fairly well. They also support import from QuArK, which is an excellent map editor. Creating a map editor like that is a huge amount of work, so ability to import maps from existing map editors is a must (this could also be done by writing an exporter in the map editor to our map format). This rules out option A.



I’m planning to generate indoor maps more or less procedurally, so creating maps programmatically during run time is an important feature for me.

This is not always easy when using existing BSP based map formats.



It seems that modularizing the map code into separate systems with interfaces and default implementations and possibility for custom implementations would both help to keep the design clear, as well as allowing more freedom in how the map system is used in different applications.



So, I think option D is the way to go. A challenge is coming up with a good division of the system into separate subsystems, but we can review how existing plug-in based engines like crystal space do it.



Option C seems similar to option D, except for the lack of a plug-in structure. If it’s still extensible though overriding existing classes or such, that could be ok too, but why not modularize the map system properly as described in option D from the start?

+1 for the plugin system.

All games have a different map system, depending of what the game need. The rendering part is often the same, but you may need to had some extra data that is specific to your game. So using an abstract map system the user could define his own map system.

For lazy users, we could provide some map-system templates (as the game templates in the com.jme.app package).



Chman

"DarkProphet" wrote:
It all depends if jME "sponsers" the use of 3dsmax to use as its art source. Much like the unreal engine.

DP

I think Unreal is tied more to Maya, as they deliver an Unreal export plugin with Maya Personal Learning edition on the UT2004 Special Edition DVD that comes with 60 hours of content creation/modding videos

sorry, yeah…Much like Unreal engine is tied to Maya :slight_smile:

+1 for own format



I think that we should expand the .jme format to handle maps as well as models. The format can already do terrain and purely mesh levels. Adding portals and bsps would mean that the programer can use the same code fall every type of level and leave the design to the artiest.

.jme does not contain terrain heightmaps.

It was added in Revision 1.28.


   private TerrainBlock processTerrainBlock(TerrainBlock terrainBlock, HashMap attributes) {
        processAreaClod(terrainBlock,attributes);
        terrainBlock.setSize(((Integer)attributes.get("tbsize")).intValue());
        terrainBlock.setTotalSize(((Integer)attributes.get("totsize")).intValue());
        terrainBlock.setStepScale((Vector3f)attributes.get("step"));
        terrainBlock.setUseClod(((Boolean)attributes.get("isclod")).booleanValue());
        terrainBlock.setOffset((Vector2f) attributes.get("offset"));
        terrainBlock.setOffsetAmount(((Integer)attributes.get("offamnt")).intValue());
        terrainBlock.setHeightMap((int[]) attributes.get("hmap"));
        return terrainBlock;
    }

Right, as TerrainBlock is just another TriMesh, I meant it doesn’t build TerrainPages (Quadtrees). Since we are referring to scene partitioning BSP, Portal, mentioning that .jme does not handle Quadtree partitioning is important.

Yes it can. You can convert the terrine pages into Nodes and TerrainBlocks. The sorting would be done in the converter to speed it up. The methods in TerrainPages are irrelevant because the program should be written for all types of sorting. (Using standard collisions). The converter would be similar for portals exempt that you would need to tell the format to use the portals nodes instead of the regular ones for terrine.

This is very close to my hobby-horse that JME should be (and I use the phrase loosely) middleware providing the grunt to shift pixels quickly and efficiently in whatever method suits.



Portals, Octrees, etc. are simply methods of culling those damned polygons - if jME were to implement portals directly it’d inevitably become an indoor based game engine; my opinion anyway.



Much better to have a solution where we can import various formats and convert them to scenegraphs; more flexible and greater longevity as a product. We only need portals now as CPUs and GPUs can’t cope - only a few years ago nobody would’ve dreamed we’d be writing 3D real time FPS games in java - I remember when the painters algorithm was state of the art and had to be hand coded in assembler!



Sorry - started to ramble (too much wine)…

Yes it can.


You're right, I haven't looked at the reader in awhile. Missed that it reads pages as well as blocks.

so…a bit confused…I read that adding indoor handling was planned as having an extra option: you could do large terrain games, or an indoor one…



It’s true that many engines out there are limited to a field: for example, GStudio is not limited, but much better suited for an FPS.



While others are specially good for large terrains rol games, and also worse for very quick fps…



I think it’d be good that it’d be able to do both…(if possible)



Some friends coders (two groups, two different ones, both make a living apart with game jobs) allways tell me an optimized, internal format i sthe way to go, that is making converters towards the format, if the direct link is not possible(actually, they think of coding the direct plugin more for making an specific game).

If we end up using the .jme format you can do both. You can use the format to add a terrain and an indoor system on the terrene form inside the format.

well, then, that sounds perfect ! :slight_smile:

Hello everybody,



Well perhaps i have missed something, but i think that A and C are quite the same, C has just more feature (the converter for your own map system)…



It seems to me that option C is the best approach : because the more converter you have the more tools you have (it can be very progressive), but it doesn’t stop people from making map editor tool with native jme format if they want. Furthermore, it is the option used with the model .jme format and it works pretty well (modelling with wings export to obj, convert in jme works like a breeze for me).



Also i think it’s important for jme to be very open to every type of game (it’s an actual feature), this can be achieved with a jme map system (perhaps i’m wrong but all existing map format are indoor/outdoor/fps/rts/mmorpg specific oriented).



bye,



Adenthar.

"mgscox" wrote:
This is very close to my hobby-horse that JME should be (and I use the phrase loosely) middleware providing the grunt to shift pixels quickly and efficiently in whatever method suits.

Portals, Octrees, etc. are simply methods of culling those damned polygons - if jME were to implement portals directly it'd inevitably become an indoor based game engine; my opinion anyway.

Much better to have a solution where we can import various formats and convert them to scenegraphs; more flexible and greater longevity as a product. We only need portals now as CPUs and GPUs can't cope - only a few years ago nobody would've dreamed we'd be writing 3D real time FPS games in java - I remember when the painters algorithm was state of the art and had to be hand coded in assembler!
Maybe I completely misunderstand your posting.
If jME is about shifting pixels only, everybody who wants to write an indoor game would have to solve the same problems again and again on his/her own. Portals, PVS's, BSP's are there to help improve speed - which still is necessary for todays hardware. I tried a medium sized q3 map whithout optimizations and ended up with 2 fps. Without a system which handles (convex) regions and can quicky decide how to cull away lots of polygons, indoor jme based games would be limited to either absolutely high end systems or simple maps. We have things like LOD handlers for outdoor maps, why not provide something for indoor?
Additionally, I cannot see how things like PVS or portals can be converted directly to a scenegraph - it's like if you're saying that view frustum culling should be converted to the scenegraph. PVS and Portals break tree rules since they horizontally connect tree nodes for visibility checks. Therefore, if we want to make use of these techniques, we should provide a standardized method to handle them.
BTW: Renanse, is your multipass rendering going to have impact on this?

I doubt it would. culling occurs before drawing.

Hmm, in my current implementation portal culling occurs during the draw method of the convex regions. I guess that’l have to change then somehow.