FIFE forums

Please login or register.

Login with username, password and session length
Advanced search  

News:

FIFE 0.4.0 has been released on 15th of January, 2017!

Author Topic: To layer or not to layer, and height maps ( Model review )  (Read 4143 times)

Sleek

  • Developer
  • Jr. Member
  • *
  • Posts: 57
    • View Profile
To layer or not to layer, and height maps ( Model review )
« on: January 20, 2008, 07:39:56 pm »

There were some discussions on the IRC on how to solve the current z-order problems. There are several aspects to this and here I try to elaborate a bit on my thoughts on it.

==When to use layers==

Layers are mainly used for

1) Positioning instances ( x,y - by cells )
2) Grouping instances into one rendering iteration ( z - by layer )

For a normal RPG games like fallout and island_demo, I believe we can divide the layers category into the following list :

 - fog of war ( top )
 - sky
 - roof
 - instances/walls/blockers
- items layer !
 - ground tiles ( bottom )

Note that each category doesn't represent one layer, but can be divided into several layers. As suggested by jasoka, the quays in the island_demo map should be moved into a separate layer. While I resisted the suggestion for a while, I guess it's a valid idea after all. The quay will always be under everything else, but above terrain tiles, so both could be grouped into 'ground' layers category.

Recently an instance grouping tag was introduced into the map format. This allows us to set a property to a group of instances at once, emulating a layer. However, instance grouping will use the existing layer's cellgrid for x,y positioning. Thus, the subtle factor to look at when choosing between a layer and an instance group is whether a new positioning system is required.

Earlier I suggested a z-offset solution. My argument was: I would imagine if we walk over the quays, the PC should get lifted a bit upward. The method I would do this is by  PC.setZ( Quay.getZOffset( ) ). If we were to move the quays into the 'ground' layer instead of using offsets, this information would be 'flattened' and we couldn't do the above anymore. I guess this argument is invalid, since we can still do something like PC.setZ( QuayLayer.getHeight( PC.getX(), PC.getY() ) )  ( Yes, I am talking about a to-be-implemented height map here  ;D).

==Heightmaps and stairs==

To extend to the idea, imagine stairs leading from a lower elevation to a higher one. The higher elevation would represent the 2nd floor of a multi-storeyed building. Now the stairs would exist in the object layer, with the height increasing as we approach the top of the stairs. Once the PC reaches the top area of the stairs, we load the 2nd elevation and switch to that elevation.


==Terrain tile transition, fog of war, etc==

Because there is a possibility that we want to render each layer differently, I suggest that we inherit a class for each layer that we want to use, e.g. TileLayer, FOWlayer. Another method would be to set a layer's custom rendering function at initialization.
« Last Edit: January 20, 2008, 10:09:12 pm by Sleek »
Logged

MuteX

  • Developer
  • Newbie
  • *
  • Posts: 12
    • View Profile
Re: To layer or not to layer, and height maps
« Reply #1 on: January 20, 2008, 08:53:45 pm »

Quote
Earlier I suggested a z-offset solution. My argument was: I would imagine if we walk over the quays, the PC should get lifted a bit upward. The method I would do this is by  PC.setZ( Quay.getZOffset( ) ). If we were to move the quays into the 'ground' layer instead of using offsets, this information would be 'flattened' and we couldn't do the above anymore. I guess this argument is invalid, since we can still do something like PC.setZ( QuayLayer.getHeight( PC.getX(), PC.getY() ) )  ( Yes, I am talking about a to-be-implemented height map here

That was the main reason why instance groups have been implemented. They make editing and maybe scripting (when igroups can have names and can be controlled from script-side) easier because it'd be possible to move a whole group up/down (elevators which are built of many instances e.g.), but that was not the main purpose. ;) Like Sleek says, they were coded to mainly avoid that 'overlapping bug' which occured in the earlier island_demo. Unfortunately our ordering code does not cover that. Consider this example:

We're on island map with all those quays. The quays are grouped together and at Z=0.0. The PC walks on them and is at Z=0.3 (in case quays are 0.3 some-what high). As long as the PC is standing at the center of the quay, everything's just fine and the PC gets rendered after the quay -- ordering takes place here. But if the PC moves and is about to leave the cell -- let's say to the lower right -- he will get overdrawn by the next quay. The reason is simple: The current 'view' does not check if an instance in cell A might be higher than an instance in cell B and would therefore get draw precedence.

So at this point of time, layering MUST be done in such cases to make everything look right. If we keep that layout, Sleek's absolutely right with his 'layer categories'.

According to the stairs:
I came up with this when discussing with phoku if z values are needed at all. This is a good example for z ordering, but! The current map layout gives us elevations for this case. When walking up/downstairs, we prolly want to switch elevations, not layers.

And last, but not least: What do you mean by inheriting layer classes? At map/script/C++ side? I think I need some more input to be able to comment that. ;)
Logged

MuteX

  • Developer
  • Newbie
  • *
  • Posts: 12
    • View Profile
Re: To layer or not to layer, and height maps
« Reply #2 on: January 20, 2008, 08:56:10 pm »

Ah, and before I forget: Using a real 3D approach, we won't have any z ordering problems at all. ;) Just to kick in my 2 cents, hehe. This is because 3D frameworks have depth buffers and take care of that.
Logged

Joshdan

  • Developer
  • Newbie
  • *
  • Posts: 46
    • View Profile
Re: To layer or not to layer, and height maps
« Reply #3 on: January 20, 2008, 09:32:21 pm »

Going to 3d doesn't really eliminate any issues, unless we actually use 3d models (at which point we are talking about an entirely different project).  All of the sprites still need to be given Z values in order to determine which one will show in front of the next.  At that point the difference between sorting or using a Z-buffer is a matter of simplicity and performance, not of functionality.

Note that even with a Z-buffer, effects involving translucence (e.g. glow effects, tinted windows) generally require correct draw order.
Logged

MuteX

  • Developer
  • Newbie
  • *
  • Posts: 12
    • View Profile
Re: To layer or not to layer, and height maps
« Reply #4 on: January 20, 2008, 10:07:32 pm »

Well I meant something like "3d models". Sprites are mostly just two triangles, i.e. a quad, with a texture on them. A 3D framework like OpenGL takes care of depth calculations which wouldn't need to be handled by FIFE.
I already talked with Sleek about that. Devs can check out the IRC logs, just search for "3d approach". Like it's currently done it's working fine, that means by putting special instances in their proper categories and layers like it's done in island demo atm.

And Joshdan: We're already using Z values for instances. They default to 0.0, but you can use them. There's just only a sorting taking place with instances in the same gridcell which can result in overlapping graphics.
Logged

jasoka

  • Developer
  • Jr. Member
  • *
  • Posts: 51
    • View Profile
Re: To layer or not to layer, and height maps ( Model review )
« Reply #5 on: January 21, 2008, 09:34:44 am »

Many things in this thread, I try to address those one by one.

Instance groups:
It could be beneficial to think grouping concept a bit further. I'm a little worried how current definitions expand e.g. in case when we add grouping behavior to editor and want to save those groups. On the other hand, seems that the intention of instancegroup is to add same attribute values to many instances, thus perhaps tag could be renamed e.g. to "commonattribute"

Heightmaps and multilevels in general:
Sounds like an useful feature. On the other hand, even flat surfaces would be hugely useful for plenty of games. Perhaps we could think this feature further after "1.0" release?

Separate classes for different layer types:
Basis for this proposal was different renderers for different layers. Atm the intention has been that renderers themselves would be "pluggable" for layers. That way you would define renderers only (e.g. for grid, coordinates, instances, fow...) and hook those into different layers. Layers themselves are display agnostic, i.e. they don't know how they are rendered, instead view knows this. That should allow us to create many types of visualizations for model data (e.g. 3d/2d)

Pure 3d rendering:
The basis on switching to pure 3d rendering has been that it would avoid z ordering problems. Atm I'm not sure how this would work in case we wouldn't be also using real 3d models (which should prolly be left post 1.0). In case we would be using pure 3d with "flat models", I guess we wouldn't manage to get pixel perfect graphics e.g. for tiles(?). One target for isometric 2d has been to be able to use really exact and detailed graphics. It sounds that we would lose this feature with pure 3d.



Logged

jwt

  • Developer
  • Newbie
  • *
  • Posts: 26
    • View Profile
Re: To layer or not to layer, and height maps ( Model review )
« Reply #6 on: January 23, 2008, 01:03:40 pm »

It seems at this point that careful use of Layers is enough to resolve most z-ordering issues. I agree with jasoka that, while interesting, stuff like 3d visualizations and heightmaps are probably best left to a "post 1.0" release.

The rendering system all works pretty well at the moment. I think our resources can be better spent on other tasks, many of which are much less mature than the renderer.
Logged