gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

DS development > 3D Level tools/formats

#40029 - ecurtz - Thu Apr 14, 2005 4:41 pm

Does anybody have an informed opinion on what we should start with as a format for 3D level building? Would it be easier to use a 2.5D Doom/Marathon kind of system or a "full" 3D format such a Quake2.

It seems like memory is going to be the biggest issue, at least until we get some sort of streaming off the GBA cart going. Something like the md2 stuff FeaRog and I have been playing with should work in some fashion for characters. I doubt we can afford the processor overhead for bones (prove me wrong guys.)

Anyway, I'm done with my first DS project, and I thought somebody here might have done a lot of modding or level building and have some insight before I just choose a 3D level format and start hacking.

#40045 - dovoto - Thu Apr 14, 2005 6:57 pm

Since we have hardware 3D may as well use it. Q2 would probably be a good format, although cant garuntee the DS can handle it...it has a pretty low poly limit it seems.

How many polys are put up in an everage Q2 level per frame?
_________________
www.drunkencoders.com

#40049 - Darkain - Thu Apr 14, 2005 7:21 pm

i would just like to note that Doom was on the SNES and GBA, and Quake 1 and 2 are both on the N64. I'm sure they should all run on the DS.
_________________
-=- Darkain Dragoon -=-
http://www.darkain.com
DarkStar for Nintendo DS

#40065 - tepples - Thu Apr 14, 2005 9:38 pm

But N64 games were allowed to slow down the frame rate to fit more polygons onto the screen. The framebufferless rendering of the Nintendo DS makes that a bit more difficult.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#40072 - dovoto - Thu Apr 14, 2005 10:30 pm

Are we certain its framebufferless?
_________________
www.drunkencoders.com

#40073 - sajiimori - Thu Apr 14, 2005 10:35 pm

There's no reason that using Quake 2 tools requires that the art is at the same level of detail as Quake 2 itself.

We're using Maya to model level graphics and collision, but it's a little awkward for collision because Maya's philosophy is "if it looks right, it's right", whereas BSP source data has some pretty strict requirements.

If I had it to do over, I'd more seriously consider using an existing level editor (Quake or otherwise) and write custom exporters for it.

#40091 - FeaRog - Fri Apr 15, 2005 1:31 am

I'm starting to work on Quake 1 BSPs. It'll be slow as I have a full time job (programming) and part time study to juggle as well. I see no reason why Quake 1 level of detail shouldn't be quite possible - whether it needs re-processing or not I'm not sure about yet..

#40093 - mike260 - Fri Apr 15, 2005 1:43 am

ecurtz wrote:
I doubt we can afford the processor overhead for bones (prove me wrong guys.)


Metroid's Samus model has RESTORE commands mid-display-list that appear to retrieve a matrix from somewhere on the stack and make it current. So you get 1-bone skinning in hardware. Not great, but probably quicker than software skinning.

#40116 - ecurtz - Fri Apr 15, 2005 7:00 am

I did a quick survey tonight, and I'm clearly going to need to get the Windows box set up. OS X unfortunately is seriously lacking in Quake tools (there seems to be a nightmarish fink/X11 build of Radiant and nothing else.) I might just start an exporter from scratch as well. I'm thinking it could be better to have the graphics and collision info separate, so that everything can be in pre-compiled display lists.

FeaRog - any reason for Quake 1 vs Quake 2 format? My thinking was they might have improved things a bit, but I suppose there is probably more extra junk we can't use as well. My sympathies on the job front, I got one of those too, they suck.

mike260 - pretty clever. Just thinking it must be hard to keep everything connected is you change the matrix for different areas of the model. I wonder what you'd need to do tool-wise to build animations like that. Do you have an approximate triangle count on the Metroid levels? They seem a bit smaller than my recollections of even Quake 1.

#40133 - FeaRog - Fri Apr 15, 2005 11:08 am

Mainly because Quake 1 was way more fun multiplayer (or thats what I think anyway!) and I'm aiming at a port. My job isn't that bad - I'm programming games after all ;) Just sucks up time for personal projects!

#40152 - mike260 - Fri Apr 15, 2005 2:05 pm

ecurtz wrote:
I might just start an exporter from scratch as well. I'm thinking it could be better to have the graphics and collision info separate, so that everything can be in pre-compiled display lists.


I reckon that's probably wise...so far, indications are that the DS can deal with around 4000 polys and 4000 verts before it starts dropping them. That means you *have* to use tristrips to get anywhere near peak performance, and trying to use a set of tristrips for collision would be horrible :(

If you do start an exporter, I've got a fairly solid display-list creation lib, PM me if you're interested. It's not 100% yet but it generates pretty decent data.

#40215 - FeaRog - Sat Apr 16, 2005 6:45 am

Mine is also solid, and nice and generic, unless you want to use triangle strips, as I haven't added support for them yet.

#40217 - ecurtz - Sat Apr 16, 2005 7:03 am

There are some nice looking tools for generating triangle strips, such as ACTC which seem like they could just be thrown in at any point. Is either of you using vert10s or vert_diffs at this point? I used vert10s for my md2 stuff, since that was coming out of essentially a vert8 structure. It seems like being clever about only using vert16s when absolutely necessary is going to be required once we start pushing up the triangle count.

I'm eager to see anybody's work on this stuff. Feel free to spam me with PMs or email.