I'm searching for a way, design-wise, to separate a game level-world to "zones".
I'm just asking for your opinions so while I'm googling what I need you can post your thoughts.
Thanks.
Design Q: Dividing to Wold <-> Zone <-> Scene et
Design Q: Dividing to Wold <-> Zone <-> Scene et
Dev State: Abandoned (For now..)
Requirements Analysis Doc: ~87%
UML: ~0.5%
I'd say it's completely dependent on the world...
A world comprising of a series of interconnected caves would be easy to split up into sections really as there's a lot of occlusion going on so you wouldn't have to have everything loaded/rendered at once.
A large open world would be rather different and would need to be split up differently i guess.
A world comprising of a series of interconnected caves would be easy to split up into sections really as there's a lot of occlusion going on so you wouldn't have to have everything loaded/rendered at once.
A large open world would be rather different and would need to be split up differently i guess.
Thank you, for posting this thread.
I've been wrestling with this tricky problem since I started making the gameworld, wherein a player can transition from indoor to outdoor seamlessly.
The word seamless is the toughest part to implement.
Currently, I'm trying to bring polygon count down so I can make a larger world. Then use more textures (bumpmaps, etc) to offset polygon count.
I've been wrestling with this tricky problem since I started making the gameworld, wherein a player can transition from indoor to outdoor seamlessly.
The word seamless is the toughest part to implement.
Currently, I'm trying to bring polygon count down so I can make a larger world. Then use more textures (bumpmaps, etc) to offset polygon count.
Well its pretty simple and already implemented in some engines like C4. Just have the user define a set of bounding boxes to what they would like to be considered a room. Then just have them set a level for how much they would like to be rendered. e.g. ERL_ROOM, ERL_CONNECTED, ERL_DOUBLE_CONNECTED
or something like that. For ERL_ROOM you would just render all scene nodes that are inside the bounding box that the 'hero' is in (an arbituary number that could be used to represent the camera, or whatever, set by the user). For ERL_CONNECTED you would just step through and render all the rooms that are connected to the room that the 'hero' is in. For ERL_DOUBLE_CONNECTED you step through all connected rooms, and all the rooms connected to those connected rooms.
Now of course this would lead to some minimal variable management such as a list of the following:
* Room bounding boxes with an id
* Arbituary 'hero' position
* List of connection_indices for every bounding box
So basically it would be something like this for a level:
----- -----
| 1 |<->| 2 |
----- -----
^
|
V
-----
| 3 |
-----
Bounding box 1 has connection_indices of 2, 3
Bounding box 2 and 3 have connection_indices of 1
I hope this simple illustration makes sense to you. And also you should probably make the bounding boxes available for debugging by allowing the user to be able to set a flag to draw them if they please.
or something like that. For ERL_ROOM you would just render all scene nodes that are inside the bounding box that the 'hero' is in (an arbituary number that could be used to represent the camera, or whatever, set by the user). For ERL_CONNECTED you would just step through and render all the rooms that are connected to the room that the 'hero' is in. For ERL_DOUBLE_CONNECTED you step through all connected rooms, and all the rooms connected to those connected rooms.
Now of course this would lead to some minimal variable management such as a list of the following:
* Room bounding boxes with an id
* Arbituary 'hero' position
* List of connection_indices for every bounding box
So basically it would be something like this for a level:
----- -----
| 1 |<->| 2 |
----- -----
^
|
V
-----
| 3 |
-----
Bounding box 1 has connection_indices of 2, 3
Bounding box 2 and 3 have connection_indices of 1
I hope this simple illustration makes sense to you. And also you should probably make the bounding boxes available for debugging by allowing the user to be able to set a flag to draw them if they please.
TheQuestion = 2B || !2B
Interesting, that's a good design.
Also, someone demonstrated how Half-Life implemented indoor-outdoor scenes. There was this kid who knew the cheat code and he was able to pass through walls and see the entire city. I was able to see the magic trick, which was pretty much not really spectacular, nor jaw-dropping.
Also, someone demonstrated how Half-Life implemented indoor-outdoor scenes. There was this kid who knew the cheat code and he was able to pass through walls and see the entire city. I was able to see the magic trick, which was pretty much not really spectacular, nor jaw-dropping.
I'm working on an impostor node at the moment,
Since Irrlicht doesn't have a nice way to flush the texture or mesh caches, it should be a viable solution to a large world. Here's some screen shots of progress over the weekend. In the last picture the red and grey squares are quake maps.
Using this method you could probably get away with not using zones at all, just throw everything into the impostor node and let it handle LOD of your distant outdoor meshes.
Since Irrlicht doesn't have a nice way to flush the texture or mesh caches, it should be a viable solution to a large world. Here's some screen shots of progress over the weekend. In the last picture the red and grey squares are quake maps.
Using this method you could probably get away with not using zones at all, just throw everything into the impostor node and let it handle LOD of your distant outdoor meshes.
Here's what I have in mind:
Now each zone will have a list of SceneManagers, AI Bots, other nodes that needs processing each iteration etc..
This way you can have a very detailed LOD, for example you can set on a strong PC to process a specific zone group while in a slow computer only process a zone, this way you can also control the loading of a level, having checkpoints to load a new zone/zone group etc..
Now there will be a E_PROCESS_PASS kind of thing so you like process AI first then SceneManager->drawAll to process graphics then e.g, physics->Calc_Physic etc..
I still have a lot to think about, implementation-wise, but that's the design I have in mind.
What do you think of it?
Now each zone will have a list of SceneManagers, AI Bots, other nodes that needs processing each iteration etc..
This way you can have a very detailed LOD, for example you can set on a strong PC to process a specific zone group while in a slow computer only process a zone, this way you can also control the loading of a level, having checkpoints to load a new zone/zone group etc..
Now there will be a E_PROCESS_PASS kind of thing so you like process AI first then SceneManager->drawAll to process graphics then e.g, physics->Calc_Physic etc..
I still have a lot to think about, implementation-wise, but that's the design I have in mind.
What do you think of it?
Dev State: Abandoned (For now..)
Requirements Analysis Doc: ~87%
UML: ~0.5%
WOW thats awesome, It reminds me of the Total War engine. How are the imposters created, are you using RTT?bitplane wrote:I'm working on an impostor node at the moment,
Since Irrlicht doesn't have a nice way to flush the texture or mesh caches, it should be a viable solution to a large world. Here's some screen shots of progress over the weekend. In the last picture the red and grey squares are quake maps.
Using this method you could probably get away with not using zones at all, just throw everything into the impostor node and let it handle LOD of your distant outdoor meshes.
ShadowMapping for Irrlicht!: Get it here
Need help? Come on the IRC!: #irrlicht on irc://irc.freenode.net
Need help? Come on the IRC!: #irrlicht on irc://irc.freenode.net
-
FuzzYspo0N
- Posts: 914
- Joined: Fri Aug 03, 2007 12:43 pm
- Location: South Africa
- Contact:
With seamless outdoor scene swapping i had a technique idea once im sure its been tried, but i found in irrlicht ti worked well... what you do is have zones and then a last "transition zone".
|======|
| map |
| |==[ TRANSITION zone ]== | outdoor
|======|
My idea was you lock them in the transition zone, and while they are trying to find a way out you are loading the outdoor stuff slowly dropping all the rest of the map stuff , and then unlock the outdoor when its loaded.
this might only apply to certain types of games of course and is very limiting. it worked well in my test though i got good results
|======|
| map |
| |==[ TRANSITION zone ]== | outdoor
|======|
My idea was you lock them in the transition zone, and while they are trying to find a way out you are loading the outdoor stuff slowly dropping all the rest of the map stuff , and then unlock the outdoor when its loaded.
this might only apply to certain types of games of course and is very limiting. it worked well in my test though i got good results
Indeed that is very cool bitplaneBlindSide wrote:WOW thats awesomebitplane wrote:I'm working on an impostor node at the moment,
Since Irrlicht doesn't have a nice way to flush the texture or mesh caches, it should be a viable solution to a large world. Here's some screen shots of progress over the weekend. In the last picture the red and grey squares are quake maps.
Using this method you could probably get away with not using zones at all, just throw everything into the impostor node and let it handle LOD of your distant outdoor meshes.
