Is it possible to 'hide' part of the map ?

[Ced666]

Hello !
Yet another question regarding what is feasible with Irrlicht . For a real time strategy game (comparison with Warcraft III is good), the camera is placed a certain position above the terrain (in general relatively high) and is looking down at the map (in general it cannot rotate). For this kind of game, I need to implement what is called a 'fog of war', that is, everything that is too far from your units is hidden (it is just black and you don't see what is there).
Is it possible to do such things with Irrlicht ? And thus having sharp (maybe not from total black to total light but something that increases very quickly) transitions between visible and non visible zones.

Thanks for your answers.

[Guest]

yes its possible

[Bear_130278]

GFXstyLER, from all yuor posts i must say - you are really resemble to your avatar )

[Guest]

yeah except im not fat and hairy well he asked if its possible and i told him its possible - so my answer is ~valid although i dont know how to do it, but i may have some ideas or suggestions.

see you later!

[Ced666]

Yes, you were right: my question was if it is possible to do it and not how to do it . But I could have added if this was easily feasible (I mean without diffing into the code of the engine)

[Guest]

i think it should be possible if you use tiles in your strategy game (doesnt have to be 2d, just divide your 3d into a grid) and then look if a tile can be seen or not. if yes, turn on the lighting so it gets lit by a light - if you cant see it, turn off the lighting and set its color and ambient value to black so its dark. for tiles where you have already been (but are out of view-range) you can set the color/ambient value to grey so they are not dark and not bright.

for the enemies objects (people, buildings) you could check on which tile they are (like "if (tile where unit XY stands on is dark){make unit XY dark}") but i dont know if this would not be slow when you have many enemy objects in-game since you would have to check this every X seconds.

but maybe someone here got a better solution, there must be something less complicated (think gfxstyler, thiiiiink .. )

[JP]

Isn't there some fog you can use in the engine? I don't know anything about it but i'd have thought that could maybe be used somehow... Or you could have some kind of mesh which you could move about and was only transparent where your units are...

Something like that maybe...

[Guest]

yeah irrlicht has fog but it only reacts to the camera i think - so when you move the camera, the fog moves too. thats not usable for fog-of-war.

but maybe you can calculate the distance from any object of yours to the closest object of the enemy and use that for camera fog.

so the short version: adjust the camera fog dynamically to the position of your object nearest to the enemies object. although i think this is a _very_ bad & complicated solution.

byebye

[Guest]

Thanks for your answer !

No, I think the best solution would the one proposed by GFXstyLER because as it is a turn based game, I only have to refresh visible objects when a unit has moved on another tile. Thus, this won't be very time consuming.

For the units and objects, there should be no problems for doing that. But for the terrain, it means that you can divide your terrain into cells ? (They are not necessary related to the heightmap points). It sounds tricky...

For my first point, I was thinking of an alternate solution (which is not very nice but will work): when I generate my mission in my MissionEditor (or whatever name you like ), I can generate a big terrain texture by reassembling all the tiles together to make a single file and save it. It is a little bit stupid but it should work. I would really prefer to have another solution but I think I will need to develop this kind of things myself (and specially if I want smooth transitions between tiles of grass and sand for example).

[Guest]

well irrlicht spintz has a TiledTerrainSceneNode which does this automatically i think, but for irrlicht you would have to implement it yourself.

another way would be to make the tiles yourself (like pre-made terrain shapes) and put them together so that they make a nice terrain (like 2d but for 3d, example would be zoo tycoon terrain editing or something like that), but that would require an editor to put them all together. the advantage is that pathfinding/fog of war would be easier and you could also give each tile a n own texture instead of strech one big texture, results in a lot more detailed terrain. another "advantage" is that you can "manipulate" your terrain in realtime (since you have pre-made shapes you can just swap them out, for example when you want to lower the terrain just swap out the higher terrain tile with a lower one)

but i think that this solution would be slow since irrlicht is slow at drawing many nodes (but you can fix this, there is a fix somewhere here at the forum).

would be cool to hear some suggestions from users with experience of terrain and culling stuff.

see you!

ps: nice discussion you got here, its interesting!

[Pazystamo]

you could use black billboards(if camera rotates then you have to use square made of 2 triangles) with dynamicaly changeble alpha transparency.For speed use 2x2 texture. Set this billboard on top of everything in scene. then if your player is behind it just change alpha.

[Ced666]

well irrlicht spintz has a TiledTerrainSceneNode which does this automatically i think, but for irrlicht you would have to implement it yourself.

In fact I think it doesn't work like that. I already looked at that but I think this is only something that allow you to cut a very large terrain into smaller parts, but not really playing with tiles for terrain rendering.

If you want an example that is similar to what I want to do, you can look at this link: http://www.blizzard.com/war3/screenshot ... arge.shtml

This is the WorldEditor from Warcraft3. You can clearly see that they uses tiles for the terrain.

And yes, I will make my own editor (stilln I need one for editing levels and things like that so, it won't be a lot of work more to do for the terrain editing).

I think what I will do is then create a new TerrainSceneNode that will allow me to do what I want... Hum, quite a lot of work but this will be interesting. I hope that this won't reduce too much the performances. But, still, I could combine it with the fog of war to reduce processing time (something like telling the TerrainSceneNodes which tiles won't be displayed).

ps: nice discussion you got here, its interesting!

Yep, I found too

Next, related to the 'fog of war': I had another idea. Maybe use a mask with black and white colors (and gray) to give to the TerrainSceneNode. This will be used by the node to make smooth transitions between visible and non-visible terrain and this will be usefull to know which tiles need to be visible.

[Ced666]

Hi !

I looked a little bit more in details for how to realize this TiledTerrain and it looks a little bit more complicated than expected: this class should at least inherit from ISceneNode (to be handled by the SceneManager). And, the SceneNode only supports up to MATERIAL_MAX_TEXTURES different textures. And this value is defined to 2. Sooo, I don't think it's a good idea to change this value up to something like 255 (or something as large as that).
Another solution is to divide my terrain scene node into small scene nodes (which are children of the 'empty' terrain scene node). These scene nodes are the size of a tile, but then it's a little bit tricky to manage that with the 'terrain mesh'... Humpff, looks rather difficult to do.

Does anybody have a better idea ?

the advantage is that pathfinding/fog of war would be easier

Hum, in fact not that much because I will use two different grids for the map and for the 'game logic'. The map will require square cells for the terrain tiles. And for the game logic, I would like to have hexagonal cells (fits much better with the rules of my game). But it's not really a problem because the terrain is static (it won't change during the game) and thus all the obstacles are also static. It means that, at the begining at the game, I can generate a kind of 'picture' to see which cells are occupied by static obstacles and keep this grid during the all level.
For the fog of war, it will be generated by making a mask with the visible cells and sending this mask to the terrain renderer.

[namik]

The idea of individual objects for each tile makes a lot of sense. You should create a new scene node with the array of all tiles and render them manually. Individual scene nodes at that scale would be too intensive, plus look at the advantages.

This will allow you to have the hexagonal tiles you want and rotate, raise and lower them on demand through one node.

Tiles could have their obstacles already attached.

A simple 4 bit value can define a tile as visible, previously visible, unexplorered and nonexistant. Only update tiles within a certain radius when a mobile object changes tile.

You'd likely want to implement A+ (isometric only?) or similar path finding directly into the scene node.

[Ced666]

Hi, thanks for your suggestions.

But I'm looking that in a more objet-oriented manner: ok, I agree with you on the point that this should be a unique node (like the TerrainScenenNode) for the complete terrain. BUT (and this is the big problem), it should then inherits from CSceneNode and in that case, the maximum number of textures per node is 2 which is highly problematic. In best case, I would like to be unlimited (only by hardware ), because your map could be made of a lot of different tiles.

Then, another option would have been to have one Node for the terrain in general but that has a list of children nodes, each of them for a particular node. In that case, that's a little bit tricky also because then I will need to split the complete terrain mesh into fractions (one for each sub-node). And I won't even imagine the degradations in performance. A better approach is to keep a single terrain mesh in the node and just play with children 'texture' but then, I will need to look a little bit better in the code to see if this is feasible (sounds tricky but perhaps feasible).

This will allow you to have the hexagonal tiles you want and rotate, raise and lower them on demand through one node.

No, I don't want to use hexagonal tiles for the terrain rendering because it is too difficult to manage: firstly for the 'artistic' point of vue, this is much more difficult to design hexagonal tiles than rectangular or square ones. Second, you increase the number of transitions between the tiles and thus more resources used (and also it is more difficult to manage).

Tiles could have their obstacles already attached.

I don't think this is good idea: the "CTiledTerrainSceneNode" (let's call it like that) is responsible for rendering the terrain, and the terrain only. I thing this is a bad programming practice to mix everything in that class. Obstacles should still be used like standard Meshes (or AnimatedMeshes).

Code: Select all

You'd likely want to implement A+ (isometric only?) or similar path finding directly into the scene node. 

The same, PathFinding must be done elsewhere but certainly not in the terrain rendering class.

Also, for the visibility of the cells, I would prefer a system like using a mask that will be used by the CTiledTerrainSceneNode to make parts of the map visible (this will also allow a smooth transition between visible and non-visible parts of the map).