The RGG programming language repents the core of almost all GroIMP models. This language extends java and implements the XL-language specification (https://manual.grogra.de/XL/index.html), to enable rule based graph manipulation.

This leads to a programming language based on two paradigms, the object orientation of java and the rule based structure of XL. In order to separate these two rgg is using different brackets to define code blocks. The java blocks are framed by curly brackets {…} and the xl blocks by square brackets […]. These blocks can be embedded into each other recursively and share declared variables.

Even so the function declaration follows the syntax of java, the body of the function can be of both code blocks. In difference to java rgg code allows to start directly with the declaration of functions without creating a class before. (Internally the rgg file is handled as one java class).

If a function is defined by public void and needs no parameters, it is automatically added to the RGG toolbar after compilation (the list of buttons above the 3d view). This functions are the main way to interact with a running RGG simulation.

Additionally there are several functions predefined that can be used to change the behavior of the simulation. At this point we will only talk about the initialization: protected void init (). this function is executed after the compilation or a model reset.

The java block allow java syntax up to java 1.6.( this is independent from the java version that is used to run GroIMP). Therefore it is possible to use features such as file reading and writing, mathematical calculations, abstraction/inheritance or library functions. If you are not experienced with java it might be useful for you to look into available online tutorials.(For example https://www.w3schools.com/java/default.asp)

Every new rgg file also imports by default a set of library functions that are used to interact with the graph or the GroIMP platform. This functions can be explored in the function explorer in the software. You can find it on the main menu under 'Help/Function Browser'.

Moreover rgg comes with some additions to the java syntax, or more accurate to the syntax of java 6.

A module in RGG is very similar to a class in java, it can extend other modules or implements java interfaces. It can also hold functions like 'getDiameter()' in the example below. One large difference is that a in a module the constructor is different. The parameters are unlink in a java class directly defined in the head of the module (see below 'float len') and the code executed on the initialization of a module is defined by just a second par of curly brackets (see below {setShader(GREEN);}).

Besides that the main difference is the use case. A module is always a GroIMP Node, meaning it can be added to the GroIMP simulation graph (ProjectGraph) similar to turtle commands or the base 3d Objects.

module A(float len) extends Sphere(0.1)
{
	{setShader(GREEN);}
 
	public float getDiameter(){
		return radius*2;
	}	
}

It is also possible to have modules that do not extend any other object and have no direct effect on the graph. These nodes can be useful for aggregations, multi scaling or just as place holders.

While in theory every part/organ/etc… of the simulated object (normally a plant) is suppose to be represented in the graph, it is not allays suitable to add all geometrical objects that represent an object individually. Therefore the concept of instantiations was included. Using the syntax below the module Branch is one object in the graph and is during the creation of the object interpreted as an extension of M. Yet for the visualization and the ray tracing it is represented by the four F objects with the different shaders.

module Branch(float len) extends M(len)==> 
     F(len/4).(setShader(GREEN))
     F(len/4).(setShader(BLUE))
     F(len/4).(setShader(GREEN))
     F(len/4).(setShader(BLUE));

On the right side of the ==> operator a syntax similar to the production part of a rule can be used.

It has to be noticed that even so instantiations create a smaller graph they tempt to slow down the visualization.

In GroIMP the project graph is considered to hold almost all information on the simulation. Therefore it can also be seen as a knowledge graph. To retrieve this knowledge rgg uses the XL query system. To use this queries in a java block they have to be framed by (*…*) as shown in the examples below. In that way they return a collection object, which then can be like other java objects. Moreover GroIMP comes with a set of predefined Analytical Operators to analyze this collections.

As shown in the example below in count((*M*)) this queries work with the concept of java objects. Therefore (*M*) is selecting all instances of Branch because Branch extends M. This also works with interfaces.

public void calc(){
	long countA = count((*RU(30) RH(90) A*));
	long countM = count((*M*));
	if(countM>0){
		println((float)countA/(float)countM);
	}
	println(sum((*Branch*).len));
}

in the last line of the example above: println(sum((*Branch*).len)); one way to access attributes (or functions) of modules is shown. The other way is shown below in: (*A*)[radius]+=0.1; . The first way is more in the style of java while the second way is better adapted to GroIMP. Therefore the second way is not only changing the attribute of the object but also notifies the change to the platform. Moreover it manages the access of the attributes differently, (for instance would (*A*).radius not be allowed because radius is not accessible in a java way.

public void growRadius(){
	(*A*)[radius]+=0.1;
}

Since java 1.6 did not include lamda expression, an own implementation was added to rgg. The syntax an the explanation can be found here

public void run ()[
	A(x) ==> F(x) [RU(30) RH(90) A(x*0.8)] [RU(-30) RH(90) A(x*0.8)];
]

public void getDiameter()[
    	a:A::>{println(a.getDiameter());}
]