This is an introduction to the concept of Spatials, the elements of the 3D scene graph. The scene graph is a data structure that manages all objects in your 3D world. For example, the scene graph keeps track of the 3D models that you load and position. When you extend a Java class from com.jme3.app.SimpleApplication, you automatically inherit the scene graph and its rootNode.
The rootNode is the central element of the scene graph. Even if the scene graph is empty, it always contains at least the rootNode. We attach Spatials to the rootNode. Attached Spatials are always in a parent-child relationship. Every time you attach a Spatial to something, it is implicitly detached from its previous parent. A Spatial can have only one parent. A Spatial can have several children.
If you think you need to understand the scene graph concept better, please read Scenegraph for dummies first.
A Spatial is an abstract data structure that stores user data and transformations (= translation, rotation, scale) of elements of the 3D scene graph. Spatials can be saved and loaded using the Asset Manager.
A Geometry represents a visible 3D object in the scene graph.
A Node is an invisible “handle for a group of Spatials in the scene graph.
Use Geometries to represent an object’s look: Every Geometry contains a polygon mesh and a material, specifying its shape, color, texture, and opacity/transparency.
You attach Geometries to Nodes.
Use Nodes to structure and group Geometries and other Nodes. Every Node is attached to one parent node, and each node can have zero or more children (Nodes or Geometries) attached to itself.
When you transform (move, rotate, etc) a parent node, all its children are transformed (moved, rotated, etc).
rootNode, guiNode, audioNode, a custom grouping node such as vehicleNode or shipNode with passengers attached, etc.
You never create a Spatial with Spatial s = new Spatial();! A Spatial is an abstract concept, like a mammal (there is no actual creature called “mammal walking around here). You create either a com.jme3.scene.Node or com.jme3.scene.Geometry instance. Some methods, however, require a Spatial type as argument: This is because they are able to accept both Nodes and Geometries as arguments. In this case, you simply cast a Node or Geometry to Spatial.
Shapes: The simplest type of Meshes are jME’s default Shapes such as cubes and spheres. You can use several Shapes to build complex Geometries. Shapes are built-in and can be created without using the AssetManager.
3D Models: 3D models and scenes are also made up of meshes, but are more complex than Shapes. You create Models and Scenes in external 3D Mesh Editors and export them as Ogre XML or Wavefront OBJ. Use the Asset Manager to load models into a your jME3 game.
Custom Meshes: Advanced users can create Custom Meshes programmatically.
Cloned spatials share the same mesh, while each cloned spatial can have its own local transformation (translation, rotation, and scale) in the scene. This means you only use clone() on spatials whose meshes never change. The most common use case for cloning is when you use several Spatials that are based on the same Shapes (e.g. trees, crates).
If the model is not animated (it has no AnimControl), jME loads a clone. All clones share one mesh object in order to use less memory.
Usually there is no need to manually use any of the clone() methods on models. Using the Asset Manager's loadModel() method will automatically do the right thing for your models.
“Box worlds are not made up of statically cloned Box() shapes, this would still be too slow for large worlds. To learn how to make real fast box worlds, search the web for voxelization techniques.
You can include custom user data –that is, custom Java objects and methods– in Nodes and Geometries. This is very useful for maintaining information about a game element, such as health, budget, ammunition, inventory, equipment, etc for players, or landmark locations for terrains, and much more.
You want to add custom accessor methods to a spatial? Do not extend Node or Geometry, use Custom Controls instead. You want to add custom fields to a spatial? Do not extend Node or Geometry, use the built-in setUserData() method instead. Where ever the Spatial is accessible, you can easily access the object’s class fields (user data) and accessors (control methods) this way.
This first example adds an integer field named health to the Spatial playerNode, and initializes it to 100.
Elsewhere in your code, you can access this data wherever you have access to the Spatial playerNode.
You can add as many data objects (of String, Boolean, Integer, Float, Array types) to a Spatial as you want. Just make sure to label them with unique case-sensitive strings (health, Inventory, equipment, etc).
The saved data can even be a custom Java object if you make the custom Java class implement the Savable interface!
When you save a Spatial as a .j3o file, the custom data is saved, too, and all Savables are restored the next time you load the .j3o!
Often after you load a scene or model, you need to access a part of it as an individual Geometry in the scene graph. Maybe you want to swap a character’s weapon, or you want to play a door-opening animation. First you need to know the unique name of the sub-mesh.
Open the model in a 3D mesh editor, or in the jMonkeyEngine SDK’s Scene Composer.
Find out the existing names of sub-meshes in the model.
Assign unique names to sub-meshes in the model if neccessary.
In the following example, the Node house is the loaded model. The sub-meshes in the Node are called its children. The String, here door 12, is the name of the mesh that you are searching.
There are two types of culling: Face culling, and view frustrum culling.
Face culling means not drawing certain polygons of a mesh. Face culling behaviour is a property of the material.
Usage: The “inside of a mesh (the so called backface) is typically never visible to the player, and as an optimization, the Back mode skips calculating all backfaces by default. Activating the Off or Front modes can be useful when you are debugging custom meshes and try to identify accidental inside-out faces.
FaceCullMode.Back (default) – Only the frontsides of a mesh are drawn. Backface culling is the default behaviour.
FaceCullMode.Front – Only the backsides of a mesh are drawn. A mesh with frontface culling will most likely be invisible. Used for debugging “inside-out custom meshes.
FaceCullMode.FrontAndBack – Use this to make a mesh temporarily invisible.
FaceCullMode.Off – Every side of the mesh is drawn. Looks normal, but slows down large scenes.
View frustum culling refers to not drawing (and not even calculating) certain whole models in the scene. At any given moment, half of the scene is behind the player and out of sight anyway. View frustum culling is an optimization to not calculate scene elements that are not visible – elements that are “outside the view frustrum.
CullHint.Dynamic – Default, faster because it doesn’t waste time with objects that are out of view.
CullHint.Never – Calculate and draw everything always (even if it does not end up on the user’s screen because it’s out of sight). Slower, but can be used while debugging custom meshes.
CullHint.Always – The whole spatial is culled and is not visible. A fast way to hide a Spatial temporarily. Culling a Spatial is faster then detaching it, but it uses more memory.
CullHint.Inherit – Inherit culling behaviour from parent node.
Optimization – The GeometryBatchFactory class batches several Geometries into meshes with each their own texture.