Procedural 3D assets generator

[IMPACT]

When making a game, creating the visual assets is one of the most important part. The visuals are the first contact players have with the product, and define their first impressions. In a traditional process, the artists spend hours handcrafting each of these assets.

This part is incredibly time-consuming and expensive, especially if the game offers unique items for each player.

With the gaming movement growing more and more on the Cardano platform (over 67 proposal at the time of writing) the need for high quality, unique assets will grow as well.

Is there a way to simplify this process, or even automate it? Enter procedural generation:

Procedural generation is the art of making content without manually authoring it.

ProtonGraph offers an easy way to generate 3D models, without limiting you to predefined categories. You have access to a lot of small building blocks you can chain together to create a graph. Think of it as a recipe you're giving to your computer to create a 3D model. These models can then be used in game just like any other created by traditional means.

Since this process is completely procedural and non-destructive, changing a few parameters let you get different results as well, enabling infinite variations at little to no cost. Making unique items on the fly now becomes possible, and you won't end up with the same looking generic assets, which is way too common today.

To summarize, ProtonGraph is:

• Free and Open-Source Software (FOSS)
• MIT licensed (super permissive, no attribution or fees required)
• Gives you full control over the procedural generation
• Can run in headless mode, so you can package it with your game or app (ongoing work)
• A software that already exists, but needs improvements
• https://protongraph.com/

On the technical side, it's built with the Godot engine, and the code is structured in a way that makes it easy for new contributors to add new functionalities:

• Each feature is packaged in their own node
• Nodes are independent, they don't need to know anything about the other nodes
• New nodes don't break existing projects

This delimitation makes it really easy to add new features without breaking or even touching existing code. It allows the software to scale really well and adapt to the future needs of the community.

Procedural generation is a complex topic, but has proven its utility across many titles, including some top earning AAA games. Today, game developers aiming to leverage this technique have limited options:

• Write their own tech
• Use another software

Most alternatives are closed source and pricey, which bars small developers from using them.

ProtonGraph aims to be a free and truly open source software, forever. By uploading it on public collaborative platforms like GitHub, any developer is free to inspect and improve the software, ensuring it can stay relevant to users' evolving needs. This way, the community is free to add any features without any constraints if they choose to.

It follows the Unix philosophy of making a software that does one thing, but does it well. Here we're not trying to make a massive all in one factory like Blender or Houdini, we're making a small, focused tool that can be used or embedded in bigger projects.

We're making a small brick, that can be audited and trusted, for the gaming community to use.

One example is the "Aedou: Realm of language" project (https://cardano.ideascale.com/c/idea/401098). It's actively using ProtonGraph for their level generator, so players can create new in-game locations with ease.

Risks are quite limited for this project.

The software already exists (cf GitHub page), the core functionalities are working already, but this project really needs some refactoring (to make the code easier to maintain in the future) and an improved user experience (UX) (Performance optimization and new features are coming later).

The biggest risk comes from the MacOS and cloud support. This software runs fine on Windows and Linux, but MacOS support is complicated as it requires Apple hardware to test it properly, and I don't own any. This forces me to rely on external contributors to ensure everything is working as intended on this platform.

Cloud support is also planned, but I haven't started working on it, so I don't know what kind of limitations I might face.

[FEASIBILITY]

The goal is to complete a stable and working version of ProtonGraph, and distribute it to as many game developers as possible. Right now, we have a working prototype, next step is to make it production ready.

This work is mostly software development. Both me and my coworker are experienced programmers, and we can connect to the Godot community if we're looking for support or technical assistance. (ProtonGraph is a software built using the Godot engine, it started as a simple plugin, but became a full standalone software later).

This technical stack is really easy to use, extremely well documented and packed with features which will directly help this project.

Work is planned for three months, according to the following roadmap:

Roadmap

[Month 1]

• Port the core software from Godot 3 to Godot 4
• Add the basic features nodes for simple projects
• Add built-in documentation to every node
• Release the beta 1

The goal at the end of the first month is to have a solid foundation we can build upon, not a feature complete software.

The beta will be released on the ProtonGraph discord server to gather early feedback. There are 110 people there, and I expect at least 10% of them will try this build.

[Month 2]

• Fix the bugs reported during the beta 1
• Act on the feedback (if any)

The goal with the feedback is to detect major design flaws early, not working on "nice to have" ideas that would take too long to implement. Otherwise, we won't keep up with this roadmap.

• Focus on the terrain tools
• Release the beta 2

The goal of month 2 is to release the "Terrain Update", a version of ProtonGraph with enough features to generate terrains, cliffs or any type of landscape. These nodes include Heightmaps features (ported from the old version), Erosion and Signed Distance Field (SDF) nodes.

[Month 3]

• Fix the bugs reported on month 2
• Focus on nodes to create houses, buildings or man-made structures in general
• Release the beta 3

I'm expecting a lot more people to try the beta 2, so a lot more issues reports as well. The goal here is to ship the "City Update", with new nodes to generate artificial structures easier.

[Extra work]

These are important features that don't necessarily fit into a specific month, we will work on them when we have time.

• Custom Nodes
• (For users to write their own nodes inside the software).
• There is a lot of unknown about this feature.
• Messaging protocol.
• To communicate with other applications and sent data (mostly, the generated 3D assets).
• We have a Kafka implementation of this in the current version, but it's incomplete.
• Engine plugins
• Let the user run ProtonGraph in the background and get the result directly in their game engine of choice. This can also be used to get the models at runtime when the game is running.

The requested budget is $8000 split in two parts: Part time salaries and code bounties.

The salary part is split between me and another member of the team, so we can both work part-time on this project.

Month 1 - $2000

Month 2 - $2000

Month 3 - $2000

Total - $6000

This would be a fixed amount over three months and covers a total of 540 hours of work.

The Code bounties part is a reserved amount of cash we can use to pay external contributors to fix specific, well-defined issues we can't (or don't have time to) fix ourselves. It is set to $2000.

One example is bug fixing issues that only happen on MacOS (or another environment we don't have access). The bounty amount depends on how hard it is to fix the issue. Implementing complete features could also fall in this category if we don't have outstanding issues.

In the case we don't use these funds for bounties, we can extend our work by one month as well to complete the work defined in the [extra work] section of the roadmap.

Budget recap:

• Part-time salary for 2: $6000
• Code bounties: $2000
• Total requested budget: $8000

Team members:

Gilles Rivière - https://github.com/HungryProton

• Software engineer and full-stack developer, for the last seven years. I've been doing game development as a hobby for even longer. My public work includes tools such as ProtonGraph, or Scatter which extend the design capabilities of the Godot engine.

Julian Bauch - https://iuilan.com

• Julian is our UX/UI designer and front-end developer who develops innovative interfaces and solves interaction problems. He holds degrees in computer science and design and has diverse work experience in software development, front-end, UX/UI, and real-time generative art projects. Always inspired by possibilities, he loves to question and innovate.

We are also part of Educhainment, a funded project in Fund 6 & 7.

https://www.educhainment.com/

[AUDITABILITY]

The project is open source and hosted on a public collaboration platform (GitHub). This makes the whole process transparent and easily auditable by anyone.

Progress will be measured against the roadmap above, especially the three main milestones: The beta releases. We're planning to release a new beta version at the end of each month for public testing.

Success is achieved when we publish a working version of ProtonGraph able to generate a small scale city procedurally. (This is the goal of the third milestone described in the roadmap).

Why a city in particular? Because it's complex and varied. You can find buildings, houses, trees, roads, everyday items and so on. If the software can generate all of this, there's a good chance it has enough nodes for 80% of what you can find in any video games.

That's the difficulty of this project as well, I can't know in advance the exact list of all the nodes I'll need to write, that's something I'll discover as we make progress and listen to user feedback. But I'm fairly confident we can get there in three to four months.

This proposal is a repeat of a previous proposal from Fund 7:

https://cardano.ideascale.com/c/idea/382984

I believe it was not funded the first time because I poorly described the use case and while trying to keep it concise enough to not bore out people. This time I'm trying to get more in details about the intended audience, why it could be useful and the actual plan to get there.