This project is read-only.

Suggestions / Requests

Oct 3, 2007 at 4:46 PM
Use this thread to add suggestions on things the engine could use most
Oct 3, 2007 at 6:28 PM
Loading in a large terrain (1024x1024) makes me realize a LOD setup for the terrain will be necessary. Also, terrain texture wrapping will need to be adjustable depending on terrain size, otherwise you get either too much tiling, or too much stretch.
Oct 18, 2007 at 7:06 AM
Edited Oct 18, 2007 at 8:01 PM
You guys should all look into a couple of these video and programs to get ideas on things still required from an XNA engine.

Terrain editor, with full gui (which will wait until XNA 2.0).
3D sphere rolls around on a 3d model (ball physics....easy, physics against large 3d models....difficult)
Physics capabilities
Physics, and also very important.....shadow mapping
Shader effects, like motion blur, postprocess bloom effects, etc....

These things of course will come over time, but they really should happen in a full-fledged engine.
Oct 18, 2007 at 3:09 PM
Don't worry, I'll get to the physics! :)
Oct 19, 2007 at 7:15 AM
Would that include the oct-tree implementation required for efficient collision culling? :D
Oct 19, 2007 at 1:25 PM
I was thinking more along the lines of sweep and prune.
Oct 19, 2007 at 2:44 PM
Edited Oct 19, 2007 at 2:45 PM
I've never heard of that method, I'll have to check it out. I was thinking an oct-tree could cull large models as well for viewing.
Oct 19, 2007 at 6:58 PM
Edited Oct 19, 2007 at 6:58 PM
Well, we're talking about two different things here. The oct-tree, quad-tree, BSP-tree, portal, etc. algorithms are useful for spatial partitioning to make sure you only render what is potentially visible, and are essentially render algorithms. On the physics side of things, you're much more interested in potential collisions. That's where sweep and prune comes in handy. It uses AABBs to check for potentially intersecting pairs, then you do collision detection on those pairs.

I see two problems with using an oct-tree for physics (in our case):
  1. An oct-tree is only one spatial partition algorithm. The way I see it, there will be many such components (quad-tree, oct-tree, BSP-tree/portal, etc.) that clients could instantiate and use as their scene manager, each useful in different types of environments.
  2. With an oct-tree, you can query for all pairs of objects which are in the same space partition. Sweep and prune, on the other hand, gives you pairs whose AABBs overlap. You pay a little extra cost in the setup, but you save by rejecting more non-colliding pairs.

You could potentially merge the two by doing one sweep and prune per oct-tree partition, but then you're again assuming what kind of spatial partitioning the client is using. I think the safest bet is to let the physics system have its own partitioning system. The scene manager will feed actor and environment data to the physics simulator, and then the physics simulator can do whatever it needs to in order to provide position/orientation updates to the scene manager without relying on any underlying scene manager functionality. In probably 90% of cases, the "physics geometry" will be different from the "rendered geometry" anyway, given that you want to simplify the collision geometry as much as possible.
Nov 2, 2007 at 10:43 PM
It'd be great to see something like this for the terrain component, as an option at the very least.
Nov 3, 2007 at 12:18 AM
None of the links or screenshots work :(
Nov 3, 2007 at 12:23 AM
I have no problem viewing them, they link to youtube can you access that? Try to copy the link directly into a new browser window
Nov 3, 2007 at 12:33 AM
This last one is simply a link to a XNA Creator's club thread.
Nov 3, 2007 at 1:21 AM
Huh, the screenshots aren't loading anymore, I'm guessing it has to do with the server that this guy posted his stuff on.

Basically it was 4 semi-realistic looking trees, but according to him they were randomly generated. I know there is also a random geometry generator sample on XNA. I just think it would be a nice option to have randomly generated trees. Or possibly the option for semi-randomly generated. For instance, you wouldn't want to randomly generate trees in areas where water volumes will be. With an editor you could define areas that were able to have trees randomly generated.
Nov 3, 2007 at 2:23 AM
Ok, I guess they're back now....

Not sure what is going on with those images.