Communication between objects

[Didier]

@zicklag

If we have some sort of node “Classes”

This article http://old.haxe.org/ref/oop could be a reference/starting point to start with this logic node “Classes” you evok, as well as Class Instance - Haxe - The Cross-platform Toolkit when we speak about objects as instance, when using a logic node “Classes” …

(just a remark : As already discussed here Armor3d capability questions - #10 by RobDangerous, we have to deal too to offer a garbage collector help, thus as a first step with a class destructor for the management of resources / automatic garbage collection of inacessible objects and thus avoid unpredictable stalls … in this article, we have the Constructor and Initializer, but no Destructor)

I think the target to have in mind too is that OOP in Armory will be designed for the development of very large software systems.

Same thing as how to make possible to detect problems in Armory early during the design phase, before implementation starts.

When ready, we could open a new post “OOP in Armory” or "How to design Very Large SW in Armory)

[Didier]

A proposal for the node that could create objects, that is instance of a Class, which name is Atoto

When selecting a class Toto into the Instantiation Node, the node changes, with the names of Methods of the selected Class, plus the Args for each Method appearing.

In the node tree Editor :

• the name of the node tree is the name of the Class
• a prefix assign to the name of the node tree tells that it is a Class definition, like for example with a prefix Class_

The following node is used to define the Method of the Class into the node tree of the Class Class_Toto

After instantiation, we could for example manage objects (that is instances) through a node comparable to an Array of Objects, or with a direct call considering that we have set the name for the Instance of the Class …

[zicklag]

Then the trick would just be compiling the NodeTree that defines the class to a literal .hx file with the class in it. That dropdown that has “Toto” selected would then browse other node trees and would read the tree to determine the attributes and methods of the class.

That could be relatively easy to implement.

[Didier]

@zicklag

Then the trick would just be compiling the NodeTree that defines the class to a literal .hx file with the class in it.

Is the Get Trait logic node code able to facilitate that ?

[zicklag]

I don’t think so. That just resolves the Trait by its name.

Compiling the node tree to a Haxe file would be done as a part of the build process or node trees. There is the make_logic.py file that takes NodeTrees and compiles them to Haxe traits. We would have to add the logic to read the special nodes that indicate that the node defines a class and write out the Haxe file to take those nodes into account. Similar to how the function node already work.

[Didier]

@zicklag Our actual brainstorming consists in trying to copy a usual POO approach on nodes and node trees.

If we reasoned differently by considering that a class instance is always a 3D object, for example an empty.

Then the methods are the traits added to the 3D object .
Inheritance takes place via the parenting of 3D objects.

The node Spwan Object is associated to the notion of Class constructor.
The node Remove Object is associated to the notion of Class destructor.

The scene could be associated to the notion of Package or maybe super-class/ virtual Class with already existing logic nodes to manage it.
. Thus we have a way to group Class into a coherent set, and to provide a namespace for these elements.

Also as the Objects in a scene can be organized into named and nested collections, thus we could find here the notion of sub-package.

Objects (that is here for us with the meaning of the instantiation of a Class) are typically a member of one collection in a scene, but they can be put too in multiple collections, and we could make the link here too with the notion virtual class.

Collection could become a kind of virtual class that has already le logic nodes to use it

[zicklag]

Thtat’s intriguing. It could be worth testing that out to see how it feels when using it.

[Didier]

We could test with this first proposal :

1. A Collection is a Container of Objects
2. A Scene is a Container of Collections
3. An Object is an Instance of a Class
4. A Class is an Empty 3d object
5. The Methods of a Class are defined by it’s Traits
6. The Heritage is established with the Parenting

[Didier]

Thus for Containers, we have already things available like create empty container, add, delete, access to

Then for heritage between Classes :
When you spawn, after you do a Set Parent on this new object with the object from which it inherits (thus the empty that represents the parent Class)
Then when calling a Trait , that is a method of the class of this object, if this Trait doesn’t exist on this object, you do a get parent , again a get trait and the Call Function … which becomes equivalent to call the method of a Class parent.

[Didier]

@Didier

We could test with this first proposal :

1. A Collection is a Container of Objects
2. A Scene is a Container of Collections
3. An Object is an Instance of a Class
4. A Class is an Empty 3d object
5. The Methods of a Class are defined by it’s Traits
6. The Heritage is established with the Parenting

That’s done for a first step in experimenting if this OOP with Armory “tient la route”.

This first step to test proposal is done by creating several Factory Class able to create instanciation of different Classes, taking the exemple of the Neural Network.

Here an exemple of result when printing the Neurones of each Layer, that is here the Container Collections of the scene.

![image|423x441]

Thus this first step shows that in this first OOP rules proposal :
1 + 2 is OK we have logic nodes to add a new collection in the active scene. Then Objects are added inside a collection simply by using an add Array logic node, with the Collection as the input Array.
3 + 4 + 5 is OK we have a Class Factory able to create 3D objects, where each object represents an instanciation of a Class. Each Factory class Methods are realized thanks to the logic node Function
made by @zicklag
6 is TBC as it needs now to be test further on, in order to confirm/define some rules to reproduce OOP inheritance.

I modify with 4. A Class is an Empty or a standard mesh object.

And always what’s amazing about Armory is that it’s very fast, even with a lot of neurons. Indeed, we could fear an additional cost of CPU time with a switch to OOP.
It seems to me that on the contrary with this first test, if I compare it with other realizations, it would allow to reduce the number of Logic Nodes, to use more native Blender possibilities and thus to gain even more in performance.
See therafter picture for a load test

For the next step, I will test a behavior well known in OOP, that is Observateur/Observable, and thus go deeper with point 6 of the OOP proposal for Armory.

Next step:

6 is now tested OK
Done by adding several “Observateurs” to an “Observable”, using a Method belonging to a child Class of the parent Class.

The technic used is as follow :

• The generic Class Neurone_0 has 2 children, that is 2 “Empty” Observateur and Observable

• when I want to call the Method M_AjouterObservateur on an instance of the Neurone_0 (that is the objects created by the Factory of Neurones), I have to call the Method of it’s children Class Observable, that is in fact a specialized Class that has this Method. Thus all needed Observateurs become registered for this Neurone.

• for example on the following system console picture, the method M_AjouterObservateur is called here with the following resulting print that shows that effectively the tab of the Observable, that is in this case for the neurone N0_1 (= Neurone 1 of the Layer Input ) register observateurs of the following Layer.
  

After a few days of tests with OOP method for Armory SW dev … some news:

• The new Neural Network made using this OOP approach is coming to life. See picture below
  

  

• I discover using it that this OOP approach proposal gives great advantage in the lisibility of the application.

For example, when you clic on an object (that is a Class) into a Scene, as you see directly what are the Methods of it into the Armory Traits window, thus you kickly see what is the Logic Node Tree to select in order to modify the behavior of a Class. (for example here it’s about +15 traits and +12 Class, and the quantity of logic Nodes is divided by an approximate factor of +20 compared to a functional approach thanks to inheritance capabilities )

Hopping that you will find it usefull for you too and that you will soon give us some info on your own tests of this OOP proposed method for SW Dev within Armory.

News: I focus the design approach to get a best how-to with it for some things like to keep performances too in this OOP approach (as it was the case when using array of array of array in preceeding tests) that is to keep good alignment of datas in memory, keep cache friendly things and maximize the use of SIMD for example.

[zicklag]

Wow, that’s cool. Good job @Didier. Neat that you go that working and that you actually implemented it for your project.

[Didier]

@zicklag something useful at this stage would be to have feedback from those who have thoroughly tested/benchmarked the Kha.simd package but I fear that perhaps only @lubos is currently the best placed for this feedback when working on the Graphics2.hx for example?

[zicklag]

Unfortunately simd only works on the hxcpp target, which Armory doesn’t use anymore. Development builds will use Krom and the production build will use the HL/C target so we won’t be getting any use out of it for Armory. It migh be possible to make simd for HL/C, but I wouldn’t know.

Kode/Kha/blob/master/Sources/kha/simd/Float32x4.hx

[Didier]

@zicklag At first sight, I’m looking for mainly reusing what’s available today in Armory/haxe…, so it’s easy to define for example custom iterators and iterable data types, and I focus on how to complete/provide/reuse a set of language abstractions/logic nodes/3D objects/… and optimizations for an object oriented high-performance computing in Armory.

Thus if the simd.hx is not interesting for all kind of platforms, it’s however I think an interesting example of a good way to organize things to make some cache-friendly things.

Looking for which strategy is best for an efficient OOP aproach in Armory will depend I think too as well on the hardware architecture/platform planned to use, but also the data access patterns+ dataset characteristics in the SW design.

Maybe @RobDangerous could give us advice in this domain on how to best use things like for example the haxe Map<K, V>(IMap<K, V>) , generics (see https://haxe.org/manual/type-system-generic.html) and iterators ?
It would be interesting to know for example how to get the equivalent of a hand-written SOA layout with Haxe, like when a compilator is able to make for us things like smart function inlining, constant folding, … in order to get a more efficient application.

[RobDangerous]

Sorry guys, I don’t understand what you’re talking about. I can just tell you that the simd API does not need to be profiled because every function literally just creates a single intrinsic.

[Didier]

@RobDangerous it’s about mixing a standard OOP approach with a data driven one, that will take care of things like memory behavior, playing with the cache, data organization, … in order to get optimal performances. Thus maybe some things and astuces already available in haxe could be reused if well known and understood ?

[RobDangerous]

Sorry, still don’t understand you. Also don’t really want to, I suppose, none of this looks like it would be something I’d like to think about.

[Didier]

@RobDangerous sorry for not being able to explain it better than by defining an object/data oriented design approach that takes advantage of the Armory 3D environment to facilitate development, but while focusing on performances that make the most of what exists. I thought that your activities on kha could be the source of good ideas about performance and I fully understand that you are not interested.

[RobDangerous]

The kind of higher logic I see discussed here is nothing I actively think about because I’ve never seen it become an actual performance bottleneck. Can only give the advice to get rid of standard OOP ways of thinking.

[Didier]

maybe if I could give you an image : imagine that you design a game using a high quantity of particules … a simple class inheritance can already be prohibitive for the necessary performance/FPS during some intense loops (no contiguous allocation in memory; lot of cache misses… )