#149398 - Mr Snowflake - Sat Jan 19, 2008 4:33 pm
Hi guys
I was wondering for a good 3D file type for the levels/maps of a 3D game. I was looking in to bsp files from quake, but I read somewhere on this forum, these aren't really good suited for the DS. So now I'm in need of a file type/structure to load and display 3D levels from. The file type should also have a map editor, as I'm not planning on creating my own... :).
[edit]Title changed read later post.
_________________
http://www.mrsnowflake.be
Last edited by Mr Snowflake on Mon Jan 21, 2008 1:05 am; edited 2 times in total
#149402 - tepples - Sat Jan 19, 2008 7:42 pm
Bitmap.
Each pixel in the bitmap represents one cubic tile, as viewed from overhead. You determine which cells to draw and which cells not to draw by tracing rays from the player's point of view.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#149454 - Mr Snowflake - Sun Jan 20, 2008 11:47 am
Is that usable on the DS? And how usefull is it?
[edit]I was thinking more along the lines of a file format which is used by Metroid Prime: Hunters of some sorts.
_________________
http://www.mrsnowflake.be
#149460 - tepples - Sun Jan 20, 2008 2:22 pm
| Mr Snowflake wrote: |
| Is that usable on the DS? And how usefull is it? |
A 2D array is precisely the format that Wolfenstein 3D and Animal Crossing: Wild World use for maps. As for the models that represent the contents of cells, those might be stored in DS display list format.
My philosophy: If you have no idea how to do something, just get it working. Then you'll be able to see the limitations of a given method in order to ask for more directed help. In this case, once you get ray casting into a 2D array working, you'll be able to understand my description of what the Build engine of Duke Nukem 3D and other portal engines do.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#149462 - Mr Snowflake - Sun Jan 20, 2008 2:44 pm
I know wolfenstein uses it, but then you don't have heights, so no slopes or anything. But it's indeed a good thing to start.
_________________
http://www.mrsnowflake.be
#149464 - tepples - Sun Jan 20, 2008 2:54 pm
| Mr Snowflake wrote: |
| I know wolfenstein uses it, but then you don't have heights, so no slopes or anything. |
Once you do get the main rendering capability in, you can say that, for example, 137 is this sort of slope, 149 is that sort of slope, 151 is some sort of pillar within a cell, 152 is a stove, etc.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#149467 - kiwibonga - Sun Jan 20, 2008 3:28 pm
Metroid Prime Hunters uses something similar to BSP -- each room is actually a 3D model. What's particular about it is that when you open a door, it loads the next room and adds it to the scene. When the door behind you closes, it removes the previous room from memory. It can't ever have more than two rooms loaded in memory this way, it's basically a nice way to provide seamless gameplay by avoiding loading times and ensuring a low polygon count without resorting to complex culling algorithms (which tend to constrict your level design by making you create maze-like levels in small spaces). The only time you'll see loading in the GC metroids, for instance, is when you move from one major area to the other, where a lot of textures have to be reloaded. To push the number of polygons you can display, if you have a huge room, you can simply make all rooms directly adjascent to it small corridors, that way you have a guaranteed low poly count.
I think that system is probably the best for the DS, because it allows you to always know how many polygons you'll have in a given space, and push the hardware to the limits. You can have overhangs, floating platforms, caves, and slopes that don't look like they were cut right out of the ground with a cake knife.
What's severely limiting about it is usually that by the time you're done with your maps, you'll realize your enemies have to look like a bunch of glued pyramids and sticks... And the low resolution textures you apply to them will be pretty gross and jagged...
That's why I'm making a PC game right now... The DS was too depressing :P
_________________
http://www.kiwibonga.com
#149476 - sajiimori - Sun Jan 20, 2008 8:13 pm
Using plain old display lists is the easiest thing for 3D background visuals. Collision is another story...
Somebody should really produce a free, fast background collision library for DS! A lot of people seem to get stuck on it.
#149492 - Mr Snowflake - Mon Jan 21, 2008 1:04 am
Well, I discovered the question I asked was pretty bad :). I should have asked: Which 3D Partition Scheme is best to use on the DS for indoor maps? BSP, Octrees or Portals or maybe some other technique I don't know about.
You could probably use a Q2 bsp tree and delete/discard all data you won't use for the DS, but as I read bsp is probably a bit to dated for use on the DS which has a Z-buffer. But you have more knowledge on the workings of the DS, so I'd like your opinion on this.
_________________
http://www.mrsnowflake.be
#149494 - kusma - Mon Jan 21, 2008 1:29 am
I guess your answer depends heavily on your input-data... One thing to keep in mind, is that you don't want something that force you to render in small batches. You'd want to make some medium-sized batches that allow vertex-reuse and triangle-stripping, while not giving too much occluded data. For an in-door renderer, I think a portal/PVS renderer might be a good choice.
#149497 - sajiimori - Mon Jan 21, 2008 5:03 am
First, consider exporting the entire background as a single model and rendering it whole.
If you know for a fact that you can't draw it that way, consider manually breaking it into large sections and using hand-placed triggers to show/hide the sections. This may seem primitive, but it allows you to carefully budget the number of polys in the scene, which is critical on the DS.
Hardly any DS games use higher-tech solutions than that, but if you really want to get fancy for some reason, portals are probably the way to go.
#149519 - Mr Snowflake - Mon Jan 21, 2008 3:07 pm
| sajiimori wrote: |
| First, consider exporting the entire background as a single model and rendering it whole. |
I do not completely understand this. What do you mean by background? You mean 1 'room' as one model?
| sajiimori wrote: |
| If you know for a fact that you can't draw it that way, consider manually breaking it into large sections and using hand-placed triggers to show/hide the sections. This may seem primitive, but it allows you to carefully budget the number of polys in the scene, which is critical on the DS. |
This could be considered as some kind of basic portal engine? Without the expensive frustum culling.
| sajiimori wrote: |
| Hardly any DS games use higher-tech solutions than that, but if you really want to get fancy for some reason, portals are probably the way to go. |
How would a portal engine be doing, if you just render the portals which I see from my camera point and don't do any frustum culling. I loose a lot of possible vertices I could render, but I don't have the cpu speed penalty of the frustum culling.
It's probably best to test some stuff myself :).
_________________
http://www.mrsnowflake.be
#149524 - kiwibonga - Mon Jan 21, 2008 5:26 pm
Portals, as in you draw a snapshot of a "hidden" scene within a scene? I don't see how that can be less expensive than simply plugging Section 2 behind the door to Section 1 :s
_________________
http://www.kiwibonga.com
#149525 - Mr Snowflake - Mon Jan 21, 2008 6:30 pm
| kiwibonga wrote: |
| Portals, as in you draw a snapshot of a "hidden" scene within a scene? I don't see how that can be less expensive than simply plugging Section 2 behind the door to Section 1 :s |
It won't be less expensive cpu time wise, but I costs more vertices, which are limited on the DS.
_________________
http://www.mrsnowflake.be
#149527 - M3d10n - Mon Jan 21, 2008 7:10 pm
| kiwibonga wrote: |
| Portals, as in you draw a snapshot of a "hidden" scene within a scene? I don't see how that can be less expensive than simply plugging Section 2 behind the door to Section 1 :s |
I think he means portals as in rendering a room only if the door that leads to it is visible. I have yet to test it, but portals could be a fairly fast way to implement indoor levels on the DS. If your rooms only have a couple portals leading to other rooms, the frustum culling should be worth it.
It works like this: you have your level structured as "rooms". Then you have "portals" which connects two rooms together. Each room contains a list of portals connected to it.
Then you have a iterative render() function for each room, which does the following:
1) Render the room;
2) For each portal in the room:
3) Do a frustum test. If the portal is not visible, test the next portal.
4) If the portal is visible, clip the viewport and projection matrix to fit the portal bounding box and call render() on the room the portal leads to.
Hand placed portals are a good fit for the DS, and if they are simple planes, you can boxTest() them. The hardest part is adjusting the viewport/projection matrix to fit the portal, but this is the most important part: it limits the recursion and vastly reduces the amount of rendered polygons on each iteration, since only polygons visible through the portal will be rendered (which is crucial for the DS).
I don't get how portals can be considered "high tech" since they've been used way before 3D acceleration became commonplace. On system where you have heavy geometry restrictions, like the DS, they sound like good alternatives.
Just look at Dementium. The rooms are very detailed, and they are obviously using portals, since they prevent the game from rendering polygons which are behind the corners.
#149530 - sajiimori - Mon Jan 21, 2008 8:05 pm
Mr Snowflake,
By "background", I mean the whole map. As far as using hand-placed triggers that show/hide map sections, I wouldn't use the word "portal" there -- the approach is really different.
For instance, the maps on my last game were broken up into sections (by the artists), with doors between them. The scripters tagged the doors with the section IDs that are in front and behind them, and the code decided which models should be visible based on these tags.
M3d10n, I meant "high tech" in a very relative way -- the solutions I've used are exceedingly basic!
#149533 - Mr Snowflake - Mon Jan 21, 2008 8:23 pm
Ah, I see, you really meant triggers, I thought you meant something like a pvs :). My bad.
Rendering the whole map won't cut it, of the whole map should do in under 3000 vertices...
But your proposal is actually pretty good, maybe some kind of portal/trigger engine is the best sollution: use triggers if you have doors and of you just have rooms connecting without doors, use portals...
_________________
http://www.mrsnowflake.be
#149548 - DiscoStew - Mon Jan 21, 2008 10:11 pm
| sajiimori wrote: |
| For instance, the maps on my last game were broken up into sections (by the artists), with doors between them. The scripters tagged the doors with the section IDs that are in front and behind them, and the code decided which models should be visible based on these tags. |
Reminds me a lot of the 3D Zelda games, particularly in the dungeons.
_________________
DS - It's all about DiscoStew
#149572 - Mr Snowflake - Tue Jan 22, 2008 2:05 am
Ok, now we have established a way to efficiently draw a 3D world. How should collision be handled? Using a BSP tree or Octree from file or generate it when loading. Probably read it from file, but is there a real difference in preformance or memory usage between both?
_________________
http://www.mrsnowflake.be
#149573 - sajiimori - Tue Jan 22, 2008 2:57 am
If you do it right, BSP is the fastest and most compact thing around for collision. There's no need for tests against polygons. You don't even have to store vertices.
The Quake BSP code is good for reference. You can get a big speed boost by doing manual recursion instead of native C recursion, and fixed-point allows planes to be represented in 10 bytes rather than 20.