#128836 - LoTekK - Tue May 15, 2007 8:29 pm
Ok, I'm admittedly not a programmer, certainly not of the caliber to consider touching C. I'm an artist, who has a DS project somewhat mapped out, but I'm not going to be looking for a programmer until I've got something mocked up. In other words, I'm getting to work on not only mapping out the main gameplay mechanics, but also building the main art assets that will be in use.
My main question right now is, taking into account the 2000 tris at 60fps hardware limit, would I have to worry too much about visblockers/bounding boxes? I would assume they won't factor into the 2000 tri limit, but how much of a hit to resource allocation/management would something like that be?
Thanks in advance for your patience.
#128917 - silent_code - Wed May 16, 2007 7:12 pm
what exactly was your question?
the hardware can display scenes made of about 7k vertices using a limited amount of different primitve types (triangles, quats, strips etc, amount depends on what primitives are used). that is after clipping and all. so, it's the max amount of geometry you'll see in a frame. anything above that simply won't be displayed (at least that's what i have experienced).
there are some registers / memory locations that tell you how much geometry was pushed during the last update. search the forum for it (i'd tell you if i were at home and had internet and a computer that is not currently being serviced ;^D ).
as you might already know, you *can* have scenes that have much more geometry. just use some algorithm to determine what parts of the scene are visible at any given time.
hope that helps.
ps: sorry, i sort of am in a bad mood right now. you know, people asking about an n64 emulator for nds and stuff... ;^p
#128923 - gabebear - Wed May 16, 2007 7:38 pm
Testing using the 3D hardware on the DS doesn't eat into the poly/vertex limits.
BoxTesting takes 103 Cycles(contrast with 8 cycles to specify a vertex). Remember that if the box you are testing is completely inside the viewing volume the test will be wrong. There is already support for this in libnds with a good example.
Position Testing takes 9 cycles and gives you the location of a point after being transformed by the clip-matrix. This can be useful for lots of crud(the w-val is how far the point is from the camera). There is already support for this in libnds, but the only example that uses it is the picking example.
List of commands and the # of cycles they take:
http://nocash.emubase.de/gbatek.htm#ds3diomap
Testing using the DS 3D hardware:
http://nocash.emubase.de/gbatek.htm#ds3dtests
I think most people doing this stuff right now aren't using the 3D hardware to do it.
#128928 - LoTekK - Wed May 16, 2007 7:52 pm
Thanks for the pointers, and sorry, I wasn't too sure how clear my question was. :) I sort of have a rudimentary understanding of the actual visible polygons (backface culling, etc), but the main question was concerning invisible geometry used for, say, collision boxes.
Let's say I have a scene, and for the purpose of this example, we'll assume that I've currently maxed out the visible polygons/verts. Within this scene, I have, among other things, a tree and a missile. Each of these has invisible collision geometry (eg, bounding box). Now, being that the collision boxes are invisible, they presumably won't count towards the hardware visible vert/poly limit(?), but will I be able to use the invisible geometry for, say, collision checks, among other things?
Again, these are questions that I'm asking from a non-programmer point of view, primarily to get a better gauge on what sort of limits I need to work within while I am putting together my art assets, so I hope you'll bear with me. :)
edit:
Oops, didn't see gabebear's post. I didn't totally understand your post, but from what I did gather of it, you basically answered my question above, in that invisible geom is available for position checks and, presumably, collision checks?
Oh and, thanks for those links. They certainly look useful, and while they're almost completely above my head at this point, I'm sure it'll click eventually. :)
#128932 - silent_code - Wed May 16, 2007 8:15 pm
as far as i can tell you, they don't count. as i said before, only visible, post clipping primitives count. also, afaik, backfaces don't count, either.
i can't remember how the hw test was done, but normally you don't use graphics geometry for bb-cd. again, i may be wrong in the case of the nds and i don't have time to look it up right now. but i being named "box testing", i guess you don't use actual geometry, but just some maximum and minimum values relative to a point in space.
all you have to be aware of is, like gabebear wrote, the processing time (cycles) consumed by the operation. if you (or your future programmer) can do it faster in software, you should leave the hw test.
NOTE @all: another interesting questions is if the test is done in parallel with other (main loop) instructions running on the arm9. that would mean, if it was, you could issue a test and while the hw was testing, you could do some other game logic stuff. that would cut down the 103 cycles penalty for hw testing. i imagine the test is done by the 3d engine.
#128933 - LoTekK - Wed May 16, 2007 8:22 pm
Thanks for the help again, I think that pretty much cleared up the main concern I had (ie, whether I was going to have to take bounding boxes/collision boxes into account when putting together my art assets).
Your last point is an interesting one, and if you feel like continuing that line of thought, please feel free. I don't know nearly enough to actually contribute usefully, but it does look like an interesting discussion. :)
#128955 - gabebear - Thu May 17, 2007 2:04 am
The 3D engine tests run in parallel; you check the the GXSTATUS register to figure out when it's ready.
http://nocash.emubase.de/gbatek.htm#ds3dstatus
I'm not sure how feasible it would be to use the 3D engine for collision testing. I guess it should be possible, but it's not going to be faster than doing it yourself.
The boxtest should work well for figuring out what parts of a level need to be drawn, especially if you are messing with the camera much.
The position test is useful in all sorts of situations when you need to figure out what object is closer to the camera. Sure... you could do it yourself, but position testing does it all for you.
#128980 - LoTekK - Thu May 17, 2007 11:00 am
Thanks gabebear, that'll be useful info for future use. :)
I had another (possibly-annoying) question. From what I understand, culling of backfacing polies is handled by the programmer when writing up the engine, correct? Now, for animated meshes (as opposed to, say, static environment props), is backface culling normally done, or would that not be worth the effort in terms of processing cycles?
#128989 - tepples - Thu May 17, 2007 12:02 pm
As far as I can tell, the hardware is capable of culling back-facing polygons.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#128997 - silent_code - Thu May 17, 2007 12:58 pm
that is right. culled primitives don't "count" and won't be processed any further. although it still costs to set these up and do the culling, i don't think it'd be much faster than the hw when done in software.
thanks for the info gabebear! and you're right, one should use it mainly for visibility checking, althouhg cd could also be done with it. but as noone has done it yet (afaik), we really don't know.
#129091 - LoTekK - Fri May 18, 2007 7:35 pm
Thanks again for the helpful responses, and for being patient. :)
#129123 - gabebear - Sat May 19, 2007 4:07 am
The only time I know that the DS's 3D engine can't cull back-faces correctly is when you use poorly defined quads(a.k.a. non-planar quads; where all four points aren't on a single plane). Culled faces don't count in the total so you almost always want back-face culling turned on.
#129147 - tepples - Sat May 19, 2007 5:31 pm
| gabebear wrote: |
| Culled faces don't count in the total so you almost always want back-face culling turned on. |
Except in those cases where part of a mesh is supposed to be double-sided.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#129826 - LoTekK - Sun May 27, 2007 7:00 pm
Had another question. :]
Is occlusion handled automatically by hardware, or would that have to be coded by the programmer? For example, let's say I have a two-storey building, and want a player to be able to hide and show the second storey. When the second storey is visible, I'd like the occluded portions of the first storey (which will be most of it) to not eat into the 2048-polygon limit (ie, per-poly occlusion culling).
Thanks again.
#129829 - tepples - Sun May 27, 2007 8:11 pm
Completely occluded front-facing polygons still take up space in geometry RAM. You will want to handle occlusion culling in software, using techniques such as space partitioning or portals. You can also render the first floor and other far-away objects with lower-detail models.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#129835 - LoTekK - Sun May 27, 2007 9:11 pm
Tepples, once again, thank you. I'm definitely glad that while not supported natively in hardware, it's still possible to occlusion cull for my specific needs (at the rate I'm going, I doubt a lower lod for lower levels would be enough to keep the polycount down :p).
For natively rendering quads, (and I couldn't really determine with any certainty from reading through the tech specs), do the quads have to be planar, or can they be non-planar as long as they don't cross verts or form obtuse angles? If they can be non-planar, that'll ease back on a fair bit of geo memory.
#129838 - tepples - Mon May 28, 2007 12:30 am
Make all quads planar, or they will bite you in the butt once you view them edge-on. Luckily, any ellipsoid can be modeled fairly well with 24 planar quads.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#129846 - LoTekK - Mon May 28, 2007 5:16 am
For the most part, my quads will be planar. However, a good portion of the ground may be non-planar. If there's effectively no chance of seeing them edge-on, since this is going to be a strategy game with a 3/4 camera view and limited terrain elevation changes.
Would quads still be a bad way to go in this case, or would they be ok?