XNA Game Development Forums
2012/05/21 20:35:28 *
Welcome, Guest. Please login or register.

Login with username, password and session length
 
   Home   Help Search Calendar Login Register  
Pages: [1]
  Print  
Author Topic: Tutorial 10 - any requests?  (Read 4187 times)
mikeschuld
Administrator
Sr. Member
*****
Offline Offline

Posts: 389


View Profile WWW
« on: 2008/11/30 19:13:14 »

Now that the GUI tutorial is just about winding to a close, I figured we should get the discussion on number 10 going. What does everyone want to see?

GUI
Particles
Spatial Partitioning
Physics
Pathfinding
Animation
Effects

That's the starter list for now. Don't take too long to respond or i'll pick for myself (leaning towards physics or effects at the moment)
Logged
Nemo Krad
Global Moderator
Hero Member
*****
Offline Offline

Posts: 512


I have seen the fnords


View Profile WWW
« Reply #1 on: 2008/12/04 05:08:58 »

I have no preference, they all sound good to me Smiley
Logged
Chr0n1x
Global Moderator
Sr. Member
*****
Offline Offline

Posts: 307


View Profile WWW
« Reply #2 on: 2008/12/06 07:01:36 »

    Lets see, i'll give less priority to those which already have a few tutorials out there, so that leaves Physics, Spatial Partitioning, Pathfinding and Animation.
    Hmm, with effects, how are you defining that? Extra shaders, like some supplements to the Post Processing or some extra model rendering shaders? Or something else?

    Anyway, I would prefer to see a smaller tutorial that won't take as long so we can get the ball rolling again, so maybe Pathfinding, or Animation (that depends how in depth you go).

    Physics is rather extensive, and that could take a long time, so maybe for later. Particles has been done to death, just look on Ziggyware and you'll find something within the last month most likely, so I don't think you should waste your time on that at the moment.

    So I guess in order of preference:

  • Pathfinding
  • Animation
  • Physics
  • Spatial Partitioning
  • Effects
  • Particles
Logged

mikeschuld
Administrator
Sr. Member
*****
Offline Offline

Posts: 389


View Profile WWW
« Reply #3 on: 2008/12/06 13:33:51 »

For the effects idea, I was going with both some more postprocessors and then also throwing in things like bump/parallax mapping and ambient diffuse specular maps for the models as well.

Animation would probably include skeletal and skinning in a shader I assume?
Logged
dzambi
Newbie
*
Offline Offline

Posts: 3


View Profile
« Reply #4 on: 2008/12/10 18:16:32 »

Hi, i'm new here, and i have worked through all your tutorials.
I must congratulate you, and thank you for the work you have done.

I would like to say that IMHO the next step should be Animation, since it is a necessity in every game.
Then some simple physics(collision and gravity), after that particles to make things exiting, and only then
all other stuff.

So my vote for tut 10 is Animation.
Logged
Chr0n1x
Global Moderator
Sr. Member
*****
Offline Offline

Posts: 307


View Profile WWW
« Reply #5 on: 2008/12/11 02:50:01 »

For the effects idea, I was going with both some more postprocessors and then also throwing in things like bump/parallax mapping and ambient diffuse specular maps for the models as well.

Animation would probably include skeletal and skinning in a shader I assume?

Yeah that would be the starting point at the very least.

I guess move Effects and Spatial Partitioning up a bit. Those are smaller and you can get a couple of tutorials out of that, in a shorter time. Technically we already have a Creators Club sample which is very good for Animation and Skinning, so I personally wouldn't consider it a priority to give maximum benefit.

Anyway remember, shorter is better at the moment, best to get some smaller tutorials done, regain readership, and in the meanwhile develop one of the bigger ones. Can't have another large gap of inactivity like we just had now. Wink
Logged

mikeschuld
Administrator
Sr. Member
*****
Offline Offline

Posts: 389


View Profile WWW
« Reply #6 on: 2008/12/11 10:43:40 »

Yeah, I've been thinking about that as well. Another thing that would probably help is to make some game tutorials "How to write Tetris in the HMEngine" and the like. Those would be pretty easy to pump out quickly as long as the engine is to a usable point.
Logged
dzambi
Newbie
*
Offline Offline

Posts: 3


View Profile
« Reply #7 on: 2008/12/13 15:08:39 »

Oh, i agree that the creators club skinning and animation example is good, i have incorporated it in HMEngine, but many people didn't, so i was just thinking that it would be the logical next step.

What i would like to see is probably Spatial Partitioning and some Physics.

Do you have any idea about when will Tut 9 be available?

Oh, and Mike, could you please read PM i have sent to you.

THX, great work.
Logged
h4rdc0m
Jr. Member
**
Offline Offline

Posts: 63


View Profile WWW
« Reply #8 on: 2009/02/23 06:45:22 »

I'd love to see the tutorial going about Adaptive binary trees.
Below is a shameless copy&paste from gamedev.net where Yann L. esplains the basic concept.
This method seems like the way to go for highly dynamic environments as tree traversal is minimized.

Plus it seems like a really good challenge to implement, because of all the areas it touches upon.


Original thread on gamedev.net

Quote from: Yann L. @ gamedev.net
What it is, and how to build them

The basic concept is similar to both octtrees and BSPs. The geometry is exclusively stored in the leaves, the inner tree nodes are just helper nodes used in hierarchical culling. The difference between Octtrees/BPSs and adaptive binary trees (ABT) is that each node of the former ones does always describe a totally distinct region in space, whereas an ABT node can describe overlapping clusters. An ABT leaf contains the geometry, where each face is unique to a leaf (ie. a face can never be attributed to more than a single leaf).

To build one, start with the root node: create an axis aligned bounding box around your whole scene. Start a recursive subdivision function on it: At each recursive step, the bounding box gets subdivided into two parts, where both children will again be AABBs (unlike BSP trees). The division continues until either the number of faces in a node goes under a threshold, or the depth gets too large. The last created node will then be declared as leaf and contains the renderable geometry.

All this is pretty straightforward, with one exception: how does the node gets divided into two children. This is where it becomes tricky. The division plane is always perpendicular to one of the three major axes. So a node is either split along his X, Y or Z axis, creating two new nodes (both axis aligned). The position of the division plane, as well as the axis, is mathematically a minimization of the following criterions (and their respective functions):

a) good localization of space. The largest axis of the resulting child AABB must be minimized (this will favor division along the largest axis of the parent AABB) ( f1(pos) = max(split_x_axis, split_y_axis, split_z_axis) )

b) the volume of both child nodes should be more or less equal ( f2(pos) = abs(volume_child_1 - volume_child_2) )

c) the number of faces on both sides should be more or less equal ( f3(pos) = abs(face_count_1 - face_count_2) )

d) The number of split faces should be kept at a minimum ( f4(pos) = total_number_of_split_faces )

To find an optimal subdivision axis and position, you need to minimize all the functions above. Note that function c) and d) exhibit both discreet behaviour, so they can have lots of local minima (depending on the topology of the geometry). Each function above is weighted by an importance factor, so the final equation to minimize is:

f(pos) = f1(pos)*w1 + f2(pos)*w2 + f3(pos)*w3 + f4(pos)*w4

The weight distribution depend on your engine: where are the bottlenecks, how should the tree be balanced to make use of the optimized paths, how is your scene structured, how is your scenegraph organized (if any), etc.

One can use several ways to minimize the equation. We use a neural net. A different approach could use successive approximation, or simply sampling a set of positions and taking the one with the lowest f(pos).

At this point, you have the position and orientation of your division plane. Now, if you divided all geometry contained in the parent node at that plane, you'll notice that even though you minimized equation (d), you'll still have a lot of split faces. That's not good, so let's introduce a new feature of ABTs: you can overgrow them. The idea is that an ABT node does not need to represent a distinct region of space, but an approximative one.

Consider one of the two child nodes. Atttribute to this node all faces, that have the largest part of their area in the node's bounding box. You have lots of small faces sticking out of one of the six sides of the box: the one created by the division plane. Those faces would normally need to be subdivided. Now make the box a little bit larger on that axis. Quickly, the number of subdivided faces will drop, as more and more faces will be contained in the AABB. Do the same thing with the other node. Note, that both AABBs will now slightly overlap in the middle. The more you overlap them, the less efficient will the hierarchy of your tree be, so the growth factor should be made a maximal percentage of the boxes volume. I use between 5% to 10%, which eliminates almost 90% of the critical faces. Some really big ones will still need to be subdivided, but in a reasonably tesselated environemnt, those faces will be the minority.

Now it's time to optimize the volume. Because of the property of an AABB to encompass the whole volume of an object along it's primary axes, the AABB of the parent node often has a much larger volume than the combined AABBs of both children nodes. Mathematically expressed:

AABB1 + AABB2 <= AABB1 UNION AABB2

In octtrees, that's a necessary evil, and can result in lots of empty (or almost empty) nodes. But we can do better: for both child nodes, recompute the optimal AABB for the geometry they contain.

Continue the recursive process on both children, by supplying the newly formed AABBs as parameter to the recursive function. Do that until the process has terminated, and all leaves have been created.

At this point, due to all the overgrowing and optimization, your original node hierarchy will be largely out of sync with the nodes themselves. So you need to rebuild it from the bottom to the top. For each leaf, walk up the tree, and recreate the bounding boxes for each node by unifying the child AABBs to the parent AABB. If everything went well, you'll end up with the same root AABB that you've started with. Your tree is now complete.

Rendering it
Very simple and extremely fast. Start at the root node. For each of the two child nodes, test their bounding boxes (those you recomputed in the last step of the tree creation) against the frustum. If they intersect, continue recursion along the branch. If you hit a leaf, render it.

Note that since a face has a unique leaf, you can directly store a vertex array/buffer in each leaf. So no array repopulation, no checking for doubles and already rendered faces, etc. Just a simple render vertex array/buffer call per leaf. You can't get faster than that (ignoring shader state changes of course, but they are very easy to integrate).

Making it dynamic
An ABT can be used on fully dynamic scenes. When an object moves, just move it's AABB along, and quickly reunify the AABBs of the nodes between the leaf and the root node. That's it. The problem is, that with time, when an object moves far away, the tree will slowly degenerate. It will still work, but it's culling efficiency will decrease. The sloution is to rebuild the degenarted parts of the tree on the fly, depending on degeneracy factors. But I won't go into details here, as it would double the lenght of this already very long post If there is enough interest, I could go into more detail here in another post.

/ Yann
Logged
jimmy87
Newbie
*
Offline Offline

Posts: 1


View Profile
« Reply #9 on: 2009/03/02 11:47:11 »

I'd like to see a tutorial centered around the implementation of an event system. Been looking around for a good XNA based tutorial but cant find anything decent. Also I've been reading 'Game Coding Complete' lately and it just seems that every game/engine should have one, however the one implemented in the book is way over my head.

If anyone knows of a decent tutorial already out there on the development of an event system then please could you post up a link

Cheers
Logged
Nemo Krad
Global Moderator
Hero Member
*****
Offline Offline

Posts: 512


I have seen the fnords


View Profile WWW
« Reply #10 on: 2009/03/03 02:00:53 »

Basic stuff:
http://xna-uk.net/blogs/randomchaos/archive/2008/04/29/generic-xna-wiring-your-own-events.aspx
Logged
Pages: [1]
  Print  
 
Jump to:  

Related Topics
Subject Started by Replies Views Last post
Tutorial 14 Hazy Mind 3D Engine serus 3 3901 Last post 2008/12/19 10:32:01
by mikeschuld
Next Tutorial Hazy Mind XNA Engine mikeschuld 12 4871 Last post 2006/11/12 15:40:51
by mikeschuld
My Requests! Hazy Mind XNA Engine Requests ericc59 0 1863 Last post 2006/11/10 19:31:10
by ericc59
Having issues with tutorial 3 Hazy Mind XNA Engine siferion 4 2377 Last post 2006/11/26 14:04:03
by mikeschuld
My Requests Hazy Mind XNA Engine Requests Jonotron 0 1682 Last post 2007/01/04 22:07:46
by Jonotron
My requests Hazy Mind XNA Engine Requests Droxx 0 1654 Last post 2007/02/09 23:03:24
by Droxx
Tutorial 3 Hazy Mind XNA Engine hansonc 4 2482 Last post 2007/03/27 09:23:23
by hansonc
Tutorial 2 Hazy Mind XNA Engine Classicwarrior 5 2687 Last post 2008/05/17 23:01:31
by Classicwarrior
Tutorial 9 - any requests? Hazy Mind XNA Engine « 1 2 » mikeschuld 22 8092 Last post 2008/05/28 01:34:00
by Nemo Krad
Powered by MySQL Powered by PHP Powered by SMF 1.1.12 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!
Page created in 0.168 seconds with 19 queries.