As there are a lot of opinions regarding what the term "scene graph" means, it might be better if you describe what you want to do, what aspect of programming you're curious about.

With regard to the wikipedia definition: be an aware consumer - many of the articles comprise the equivalent of advertisements and use the term "scene graph" to describe their products, rather than to indicate that their product implements a "scene graph." If you look at the "scene graph" products listed, you'll find there really isn't a lot of commonality among them - either in structure or function.

Is the scene graph the world?

First: using the term THE scene graph may not be quite correct. As mentioned, it depends on what aspect of programming you're asking about. A scene graph can be used as a hierarchy in the sense that it can be used to maintain parent-child relationships. However, if, by "world," you mean meshes, textures, etc.: no, it's not (or shouldn't be) the world.

L. Spiro's discussion provides some clarification on what a "scene graph" can be used for. That article represents a scene graph as:

A scene graph is a simple hierarchy of nodes that allow propagating properties from parent nodes down to children nodes. It is nothing more.

As mentioned above, rather than using a term that has various meanings, can you describe what data or process you want to discuss? Mesh hierarchies? Frustum culling? Render sorting?

EDIT: Apologies if I'm making an incorrect assumption about why you're asking the question. IF you're new to game programming, don't get caught up in "A lot of programs seem to have a scene graph. I'll put one in my program."

Reading it again makes me think this has nothing to do with game programming? Its more like a physics term called "space"? Where a node is an object on a space? Is my logic right?

Well, scene graph isn't *limited* to game programming, but almost every single non-trivial game has a scene graph of sorts. That said, do do all kinds of other programs, such as 3D modellers, CAD/CAM software, etc.

Basically if the project has stuff in it, and that stuff has a position, it's got a scene graph. Arguably you would even call the data structure that holds UI information a scene graph, in that a window can contain a toolbar, which in turn contains buttons, etc.

The scene graph is simply the data structure that this information is stored in. How the information is stored and how nodes within the graph are related is entirely dependent on the game itself.

So, in most basic terms, a scene graph is the data structure used to hold stuff that has position in a game or applications "world". Nothing more.

Reading it again makes me think this has nothing to do with game programming? Its more like a physics term called "space"? Where a node is an object on a space? Is my logic right?

I wouldn't say it has nothing to do with game programming. It's a concept whose implementation in various ways is used in game programming, and that may be it's most common usage. A scene graph is often used to determine how an object is transformed** with relationship to its parent, as opposed to a quadtree or octree, which is often used to keep track of where objects are, after they have been transformed.

The analogy with a "space" is pretty close. A scene graph could represent the solar system, with planets being children of the sun, satellites being children of the planets, etc. Each child would be influenced by its parent in translation and rotation, which each parent "passes" on to each of its children. Note, however, that the scene graph does not keep track of data, rules or methods for transformations, just relationships among objects.

**EDIT: or, rather, what influences an object. I.e., it's parent. More in the direction of "something has changed in the scene. Tell each object to check it's own transformation, and pass any changes to its children, who pass changes on.."

EDIT2:

So if its not a stage or world then what it is like?

As a contrived example, consider a cruise ship in the Caribbean. All the passengers and machinery move about with the ship. For this illustration, consider the ship, passengers, crew and machinery to be children of the root node - the Caribbean sea. Assume your graphics application views the ship from outside, and you can look "inside" the ship with x-ray eyes, sort of a Sim-ship. As the ship translates and rotates on the surface of the sea, all the children (passengers, crew, machinery) must translate and rotate with it. Further note that each passenger/crew member can wander about inside the ship, making their own translations and rotations. However, those child translations and rotations will always be with respect to the current position and rotation of the ship.

To render a view of just a portion of the ship, two primary steps are taken. First, a scene graph can be used to "tell" the ship that it's changed position. The ship updates its position and rotation, and then passes that information on to all its children. A passenger may be walking along a corridor, oblivious of the ship's change in orientation, but viewed from the "scene," the sea, the corridor itself is translating and rotating. The passenger translates along the corridor, but the passenger's translation with respect to the water is a combination of the ship's movement and the passenger's movement within the ship. Following the ship's update, and all its children updating their orientations with respect to the ship, each object now has a different position and direction with respect to the sea.

As mentioned above, you desire to render only a portion of the ship. If you use the scene graph to render the scene, you'll end up drawing a lot of objects that don't appear in the current view. So, separate from the scene graph, you can maintain a quadtree or octree (or similar structure) which stores updated information for where objects are currently. You can then search through the quadtree, looking only at the areas of the ship which will appear in your view, and add objects to a render queue.

So the scene graph, as your book mentions, has a root node - the sea itself. One of its children is the cruise ship - a child node of the root node. The node may have information relating to the object - it's a ship, it's a cruise ship, and perhaps it's #3 in the list of ships you're maintaining. Logic or code apart from the scene graph is called to update the ship's course, its position and heading. That orientation data is passed on to the ship node's child nodes. One of those nodes is of type "person" - perhaps person #456 in the "people" array. Logic and code is executed to determine if person #456 should update it's location and orientation with respect to the ship. Then the world position and orientation of that person is determined. Another node may be of type "engine." The engine rotates at some RPM, and passes its current rotation on to a child node of type "propeller shaft." Etc.

The above situation is contrived, obviously, but hopefully gives you an idea how a scene graph can be used to determine what objects require data from other parent objects for updating. The engine will translate and rotate with the ship, but will also rotate locally itself. The attached propeller shaft rotates and translates with the ship, but must have the current rotation information from the engine. A node doesn't have to "know" whether it's parent is the ship, or an engine, or a propeller shaft. It just needs to know that it's parent is now at so-and-so position, with such-and-such heading.

It's a tool (not a requirement) that can be used to ensure that objects are all updated, and updated with the data they need to do that.