GroIMP wiki

a part of grogra.de

User Tools

Site Tools

Trace:
You are here: GroIMP documentation » User tutorials » RGG coding » RGG Code structure introduction
02_user_tutorials:13_rgg:02_rgg-code-structure

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
02_user_tutorials:13_rgg:02_rgg-code-structure [2025/12/10 16:01] – gaetan02_user_tutorials:13_rgg:02_rgg-code-structure [2025/12/12 13:21] (current) – [Queries] groimp
Line 41: Line 41:
 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);}). 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 [[groimp-platform:turtle_commands|turtle commands]] or the base 3d Objects. +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 [[15_cheatsheet:turtle_commands|turtle commands]] or the base 3d Objects. 
  
 <code java> <code java>
Line 108: Line 108:
 ==== Queries ==== ==== Queries ====
  
-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 [[tutorials:common_graph_queries|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  [[:groimp-platform:xl-builtin-methods|Analytical methods]] to analyze this collections.+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 [[01_user_documentation:07_rgg_xl:02_xl:03_query|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  [[:15_cheatsheet:operators|Analytical methods]] 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.  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. 
Line 137: Line 137:
  
 Since java 1.6 did not include lamda expression, an own implementation was added to rgg.  Since java 1.6 did not include lamda expression, an own implementation was added to rgg. 
-The syntax an the explanation can be found [[groimp-platform:xl-lambda|here]] +The syntax an the explanation can be found [[01_user_documentation:07_rgg_xl:02_xl:09_java_addition:xl_lambda|here]] 
  
  
Line 267: Line 267:
 ] ]
 </code> </code>
- 
  
02_user_tutorials/13_rgg/02_rgg-code-structure.1765378909.txt.gz · Last modified: 2025/12/10 16:01 by gaetan