Using XML? My own binary system? A paint by number scheme?

Will a root node structure or class and a vector of children survive through a file? all that is done by value right? So therefore I can put something in a vector, write it to a file, then retrieve the vector with no problems right?

The only thing I really know, is that I need to represent a tree structure in a binary file.

I can probably do it in the same way I do it in my C++ code, with a few minor modifications.

Instead of a vector of the children themselves, I need a struct Node, with an ID according to its type, Transformation is 0, geometry is 1, etc etc...

It also needs to hold a vector of children, again based on ID's...

Soooo, when I tell my program, after I load the file..

To create a root node of type 0, with a 1 as a child, it knows to create a DOF node, then create a new geometry node, and set the DOF node as the geometry nodes parent, then I can just add that to the tree.

Simple :d

no, you're going to have to write your own serialisation and deserialisation routines.
But that should be no problem, when writing iterate over the vector and write out the content, when reading read from the file and populate a new vector with what you read.

Creating an interface (abstract base class in C++) that defines the serialisation and deserialisation functions and having everything you need to serialise derive from that is the logical option.
That's in fact exactly what Java does for you ;)

So you'd have something like

Code:

---

class Serialisable {
  public:
    std::ostream& serialise(std::ostream& os) const = 0;
    std::istream& de_serialise(std::istream& is) const = 0;
}

---

Serialization what?

What is this serialization you speak of?

serialisation is the process of writing out objects to disk and reading them back in.

oh you mean simple binary I/O?

like fout << obj (with a bit more syntax)

yes, it's the process of streaming objects to whereever and recreating them afterwards.

When you get further along you might also want to create a system to ascertain that you have the correct version of the class definitions to recreate the version you're trying to read, but first get to read and write at all ;)

Sweet, so does my idea of doing this sound valid? Let me re-iterate:

Quote:

---

So, my idea is this, I can have ID's (integers) representing the various types of nodes we can have..

For instance

0 for Transformation
1 for Geometry
2 for Particles
3 etc etc...

I can have a structure that I write to the file, that contains basically, a tree.

First we have the root, in the root structure we can have a vector of children

Lets say the root is a 0, and it has a 1 as a child (in the vector..

The 1 is a geometry node, which also has a particle emitter attached to it, which is a 2 in the geometry's vector of children

So we have something that looks like this:

a 0 with a 1 for a child
a 1 with a 2 for a child

Does this sound like a good way to go about it? I figure with this much information I can create a hard coded tree structure out of the information given.

Step 1: get the root node from the file and all its children, recursively..
create the nodes according to the ID's

step 2: Link them together according to the information in the structure, again the ID's

Does this sound right?

---

I also thought I might need two sets of id's for the structs, perhaps one vector for the parent, or just a variable for the parent, and then a vector for the children...

You may want to add some more information, either in the header or at the individual records.
A table of content with offsets for each entry is one, makes quickly reading a specific entry faster.
Then per record type an entry showing the size in bytes of that entry type (if possible, but I'd strongly advise a fixed length format for each type, as it makes reading and writing a lot easier).
Then as part of each record you write write the index in the index of all its children.
So effectively you're getting a file header containing an index of all records and types.
Then you have for each record a record header containing the record type and index number as well as a list of all child records, and after that record header the record data.
You might want to throw in some checksums (per record maybe, or on a file level) as well to prevent tampering and detect corruption.

I see, a header file with like, an index to the file? Or another file as a table of contents..

Label each object with an ID?

Should this index be hard coded? Or should this be a file too?

The index idea sounds cool..

Then I could delete an object judging by its ID from the scene graph, wow..

Imagine..

Just being able to say to the scene graph... Don't draw torches! Don't draw lights! Don't do this, or that, blahblahlah

yup, that's the thing.
More important still, you no longer have to rewrite the entire file to add a child somewhere.
Just update the index and put the new child at the end of the file (or in some place where you previously removed something, leaving a hole that's large enough).

This is serious coding, that quite frankly, isn't rewarding unless you spend a good month on it, specially if you've never done it..

So for now I'm going to play with terrain and stuff :D