It occurred to me that it would be very useful to be able to use RGG files as a source for procedural plants in other tools and engines (Unity, Unreal, Godot, Blender, etc.) for interactive experiences, games and similar projects.
In a way, it is similar to the headless usage, but I envision a end-user having a RGG file as source for a plant and a call from another script leverages the GroIMP “core” to process and generate n-steps of such plant, allowing for the engine to render and then interact freely with the mesh/object, allowing for complex environment/game logic to interact with the models at runtime.
My most immediate interest is in such a tool for Unity. Has there been any work or discussion in GroIMP around this kind of integration? If not, I would be interested in developing it and would appreciate some initial guidance.
I have read parts of the wiki and documentation, but I did not immediately identify which parts of the codebase are responsible specifically for the RGG → object/geometry output pipeline, that is the most critical part for this application.
We experimented with this kind of integration at several occasions.
Yet we did not choose the way of extracting the core functionalities, but running GroIMP in the background as a service that can provide 3D models.
Furthermore we started experimenting with a web socket server in GroIMP which allows to synchronize scenes between GroIMP and in our case a AR-headset running a Godot app. This approach works similar to operational transformation and only forwards the changes in the 3D scene. While this allows us fast updating it requires the client to render all geometrical objects of the scene as individual meshes which is a bit limiting.
This project is in a rather early state but you can find the code here:
I was aware of GroLink and your game! Currently, I am learning the XL language and modeling some trees, the power of the language is immense and it is surprisingly ergonomic if I may use that word, we can only imagine the potential it has for environment building in game engines.
Forgive me if any of my questions is better answered by documentation, but is it possible to make the HTTP Server “portable” in the sense that a distributed game built from source by the engine (say, a Unity .exe build) is enough in the client side, with no more setup necessary?
One of the goals of my embedding idea would be to have direct, reliable access to the plant engine (perhaps in compile time) as to minimize setup and overhead (both in developer and end-user experience). However, if GroLink supplies that already or can be set up to do so, then i guess my problem is solved
Given that the forester game requires installation of the plugins, I imagine that there is room for improvement there. I would really appreciate if in your experience you could give me some guidance as to what is the best way I could contribute to these goals!
Would it be more productive to implement such “portability” into GroLink or to use a different, perhaps new approach to achieve such objectives?
At this state each RGG-project require a running version of GroIMP which it self requires java. You could try to extract parts of GroIMP to make it more “library like” so you avoid starting GroIMP as a process but this would still require java and to be honest would be very very hard to do.
I would assume the best way for you would be to “bundle” GroIMP with a java runtime environment to one stand alone exe and ship this exe with your game. Than you could start this GroIMP/java exe from your game and you are good to go.
Or another way would be to use GroIMP only in the “creation” as an addon/plugin to the game engine and ship the game with pre-generated plants.
Regarding the forester game:
It would be quite easy to improve this depending on your use case. You could, for instance, create a new project and push your RGG code from the game engine and run it or load an external gsz project. You can find examples for this in the provided git repository, on the wiki or on the integrated OpenAPI documentation.
