Hi, I hope i haven’t overstepped any boundry, but I reached out to aws to ask if they would ever consider open-sourcing krakatoa and x-mesh for blender. They wondered if I had contacted blender about this, obviously now would be the time to tell you guys, first i wanted to see if they would even give my request the time of day, and so far they’ve been replying. Previously they said they made a ticket and would get in touch with some people, but here is todays email from them.
Maybe this can shed a bit of light:
According to that, Apache 2 projects can be included in GPL v3 projects, however it’s not compatible in the opposite direction, so basically Krakatoa could be implemented in Blender (not sure if natively but it seems to be compatible) however Blender could never be implemented inside Krakatoa… which is not the case we are talking about so… it can happen if they want to.
On the other hand if Krakatoa Standalone is still a thing it could be implemented as a third party render engine like LuxCore for example, being Krakatoa a much more simple render engine which basically takes into account a few small things from the original 3d scene, so it’s an “easy” to implement engine as an addon, just export the scene as required with the required parameters and kraktoa could be able to read it and generate the frames.
Now another different topic would be to use PRT as particle file format, but Alembic may be used if it’s supported (albeit less efficient) so the problem could be perfectly solved.
In the end, my personal opinion based on what I know, krakatoa can be implemented in Blender as an addon, specially if they still has Krakatoa Standalone
That’s cool to hear. (I think i should mention i know nothing about developing, and stuff like that).
Krakatoa has been discussed recently here:
Cycles is also Apache 2 licensed, so that by itself wouldn’t be an issue.
that being said, there is no intention of integrating it at this point, however that’s not because of the license, here’s what brecht had to say on the subject the previous time people asked about Krakatoa
I think what @brecht said it’s the correct path to follow, Krakatoa is a very good but a very old piece of software, with some great things, but Cycles is capable of much more in a much more advanced way, however it’s true that Krakatoa was able to render billions of particles with a relatively small memory footprint while Cycles is incapable of that in the same efficient way, but that’s probably because of the way it handles point clouds and some things can be extracted from Krakatoa as ideas for the future of point rendering in Cycles, which TBH it’s already very good, it just lacks the arbitrary attributes import for Alembic, which is on the works right now.
However I think it could be a great idea for an external / indy developer to create a Blender / Krakatoa integration, a good exercise and a good tool for many of us, no doubt, so I would not ask for a Blender native integration of Krakatoa, but rather an addon that can rapidly leverage it’s advantages and it’s not tied by other constraints that can be present in modern path tracers like Cycles, like memory footprint for other reasons or other details, it’s just simpler and more efficient for what it does, but just for that, so as an addon can be a great addition
Let me update this answer:
This is the Krakatoa repo, it contains Krakatoa SR, which is the standalone version of the engine, so with this it should be totally possible to integrate Krakatoa into Blender, probably as an addon rather than included, but it should be possible
Sorry, i’m not keeping up well with blender discussions. I’m not a dev unfortunately, i wouldn’t know how to implement anything. I am wondering though, do you think blender will make their point rendering as efficient as krakatoa, like for billions of particles? At the moment, blender seems maxed out at millions.
So far I’ve renders 100 million particles with no problem at all.
However if you are using the old particle system you will encounter such limitation, you have to use Geometry Nodes and Point Cloud, and using a cached particle simulation in alembic is my preferred way, to avoid clutter the scene, but you have to use geometry nodes and render the particles as points, don’t use the particle system and don’t instance geometry in the points.
One last detail, this kind of question is not for this forum, you should go to blender.community or blender artists for this, in the top part of the page you can see a blue banner with a warning about this
(I mean the usage question, not the other part of the thread )