DISCLAIMER: The "Modding InfoCenter" threads are NOT tutorials: they are intended to help average-experienced object creators performing specific tasks, or to give users a deeper in-sight on specific modding-related subjects. So, don't expect to find step-by-step explanations, to be performed "blindly". Please DO NOT REPOST the following info, or part of them, on other sites.
All the "Modding InfoCenter" threads are created and mantained by Numenor and JWoods. Everyone is welcome to post his own questions or additional information about the specific thread subject.

CREDITS: Most of the known information about the CRES structure has been provided by Raquelcesar. Since she is (hopefully temporarily) away from the modding scene, we can't ensure full support about this subject, but we'll do our best, as usual


SUMMARY
This article will try and explain the function and the structure of the Resource Node (CRES). The following info apply to objects, though the CRES works in a similar way also with Sims, Lots and many other package types.

This InfoCenter article is also provided in PDF format. To view it, we strongly suggest to download the Foxisoft PFD Viewer: it's free and small, less than 1Mb!

PART 1 - THE "CRES HIERARCHY"

Just like many other Scenegraph files, the CRES is composed by a bunch of blocks: you can see them with SimPE, in Plugin view:

But the CRES has a peculiarity: the blocks aren't read by the game in sequence; on the contrary, they form a tree structure, that is called "CRES Hierarchy". SimPE provides a useful tab that shows the Hierarchy:

The first block of the hierarchy is always a "cResourceNode" block (with number 0x00).
If we examine this block in "Content" view, we'll see (among some unknown values) the Child Nodes list: it tells us the number of the "following" block(s) in the hierarchy. In the picture below, there is only 1 "following" block, the 0x02 one (in the cResourceNode blocks, the block number is the one underlined in red)

From now on, every block will contain info about the "following" blocks in the hierarchy: in our sample CRES, the block 0x02 has 5 entries in the "Child Nodes" list; this means that 5 "branches" of the tree start from block 0x02, and these "branches" are blocks 0x03, 0x04, 0x05, 0x06 and 0x07

As you may guess, each of these "branches", in turn, may have one or more Child Nodes, thus creating a complex tree structure, clearly depicted in the "CRES Hierarchy" tab (as seen above).

FAQ: Why the CRES has this "tree" structure? Because every attribute or modification applied to a "branch" will automatically apply to all the following nodes, too; if an object is composed by numerous parts, the game doesn't need to calculate, for instance, the absolute position of each part: once the position, e.g., of an armoir is known, the game can calculate the relative position of the doors, compared to the main armoir body. All the animations will run much smoother, and the adjustments will be easier.

PART 2 - TRANSLATIONS AND ROTATIONS
We have talked about "modifications" applied to a branch that automatically are extended to all the Child Nodes. These "modifications" are mainly (but not only) translations and rotations.

Translations represent movements of the object (or part of it) in the 3D space; we can specify a translation by editing the X, Y and Z values in the "cTransformNode" tab of each block.

The unit of measure for the translations is the "tile" (the ones that we can see in the game when we place an object in the lot).

HINT: Unlike all the 3D editing software, the game adopts a very peculiar axis system, because positive values for the X move the object toward the left side, and the Y/Z axis are swapped.

Rotations, on the other hand, are represented in the game by means of quarternions. The quarternion is the most complicated concept that anyone without a degree in maths or engineer may have the misfortune to deal with. *Luckily* Quaxi's beautiful mind was perfectly able to understand them and create a "conversion" utility: it's the box labelled "Rotation". Obviously, if you do have a degree in maths, then you can use the "Querternion" box, if you like
.

I will explain only the use of the "Rotation" box, if you don't mind
You need to specify the amplitude of the rotation itself (in degrees: 0°--360°) and the axis around which the rotation should be performed. For a rotation by 30° around the X axis, you have to write X=1, Y=0, Z=0, Rotation=30; if the rotation axis is halfway between the X and Y axis, write X=0.5, Y=0.5, Z=0; and so on...

HINT: Never use a value of zero for all the three axis (X/Y/Z): it doesn't exist a quarternion corresponding to such "impossible" combination, and SimPE will fill the Quarternion box with the error message "Not a Real Number"; always use at least a real number for one axis.

PART 3 - JOINTS
In the CRES hierarchy, usually some blocks are assigned to Joints. This is not the right place to explain what Joints are, but in few (and rough) words, the Joints are invisible points that are used to animate the mesh and/or create an "interaction point" between the mesh and the sims.
When the game needs to animate a single part of the object (e.g. the CD drawer of the PC), it simply applies a translation to a joint; as a consequence, the joint moves in the desired direction, along with all the vertices assigned to that joint.
Let's take, again, as an example, the CRES of the cheap PC:
In the line within the red border, we can read: the block number (0xA), the Joint associated with this block (Joint3) and the Joint name (cddrawer_trans); then, there are the approximated values for translation and rotation (in both notations: quarternion and carthesian). (If we left-click that line, we are presented the full content of the block).
But what part of the mesh is associated with Joint3? We can see this by examining the GMDC in "Advanced Mode":

FAQ: The GMDC already holds all the information about the Joints: shouldn't be enough? Why the CRES enumerates the Joints, too? The answer is that the GMDC has a different function than the CRES: the former holds information about the geometry (=the mesh) of the object, while the latter is the "place" where all the aspects of the object are joined together: the animations are performed moving the Joints referenced in the CRES, that in turn holds information about the Shape; and by means of the Shape and the rest of the scenegraphic chain, the joint movement is transformed into a mesh movement.

PART 4 - THE CRES AND THE SCENEGRAPHIC CHAIN
A specific InfoCenter article will explain the Scenegraphic chain in detail. For our purposes, we only need to know that the Scenegraphic chain is responsible of the exterior look of the object.
The chain starts with the CRES; into the CRES are referenced the Shapes, the Lights (if any) and the mirrors (if any). All these references can be seen in the "Reference" tab of the CRES:

HINT: Including a reference into the "Reference" tab isn't enough: the game won't read those references if they aren't associated to a specific block in the hierarchy. The Shapes (including the mirrors) are referenced into the "Practical" (cShapeRefNode) blocks, while the Lights are referenced into the cLighRefNode blocks

FINAL NOTE
The CRES is one of the most (if not the most) complex file within a package. The information provided so far are definitely not exhaustive and complete. We'll try and integrate them, with additional info provided by other modders, and regarding the question that will be asked by the users.





OTHER USEFUL RESOURCES

Modding InfoCenter Index - Comprehensive list of all the InfoCenter threads
Object Creation Workshop and Repair Center - If your object doesn't work, no matter what you try
Colour Options for "EP-ready" packages - About the texture linking tecniques
Sims 2 start to finish Object Creation Tutorial - Learn how to create your own object

Last edited by Numenor : 4th Aug 2006 at 10:58 PM. Reason: Fixed in-text images

A quick note about the CRES (Resource Node). This is, as Numenor has explained a very intricate file. If there folks out here that feel they have formatable information they should post there comments in the "InfoCenter" workspace thread.

http://en.wikipedia.org/wiki/Quaternion

Now I understand what you mean...

BTW, is rotation for the in-game axis or for the 3d-editor axis?

OK, found out myself, game.

Last edited by Fat D : 27th Aug 2005 at 09:57 PM.

Ages ago I found these three images. I can't find the original threads they belonged to but these or something similar would be a good addition to this thread or your upcoming scenegraphic chain article. I found them very useful in understanding the interrelationships of the file types.

I had to zip the pics because they were all too big to post as is and I didn't want to resize them.

I'm not sure this is the right place for this question, but I'm hoping!

How is the CRES related to the OBJD? Is there a direct connection? And if not, then how does the OBJD connect to the rest of the scenegraph?

I'm asking because at the moment I am working on an object which does not have a CRES in the file. It is clearly referencing one though, because its slots are using the joints. The object in question is based on an NPC, so it is probably referencing a body CRES somewhere. Alas, I don't know which. I want to be able to import it and change some translations around in a local copy, so that I don't override every sim in the game!

The scenegraph chain is connected to the non-scenegraph parts via the Text List 0x85, that holds the reference(s) to the CRES. Some (rare) non-buyable objects are particular, though, because they have no TL85 and no mesh at all; but they "Create New Object Instance" via their init/main BHAV (so that it *looks* like they have a mesh, but actually the mesh is contained in another object).
Normal buyable objects always have a Text List 0x85, in my experience.

A hint: if you know the filename of some scenegraph files, you can perform a scan of the game files using SimPE's "Finder" plugin: write in the search field the first part of the filenames you know, and if there is a CRES to go with them, the Finder will find it.

Ah, I never thought to look there. Turns out I really wasn't looking in any of the right places though - as it was an NPC, the cres was actually referenced in its 3D ID Referencing File. I really should have looked in there, it is kind of obvious now that I think about it, but that's the benefit of hindsight. Thanks for the answer!