Hum , yeah you can use python to access particles data, and that’s probably what they did in animation node. But AN is an unofficial addon which means it leaves more room for these kind of hack.
Since the particle system is going EOL I won’t bet on being able to retrieve particles data into GN.
But hard to tell since I’m not a dev.
For sure we’ll probably going to have our brand new but incomplete geo nodes, alongside the complete but limited old system, being modifiers, particles , physics, all that for a long time, which will probably makes some stuff very clumsy to do. But it’s the only way to move forward.
If you want to take advantage of everything without waiting, your last resort is indeed python.
The good news is that the more times we wait, the more complete GN will be and the less dependent of old method we’ll be.
Well at least it’s easy to add birth time with simulation branch, but it’s difficult to add your own physics solver, but probably someone clever will make a few nodegroups for a few dollars on gumroad
It’s just that I wonder how hard it would be to develop attribute reading from the particle system modifier since Cycles material already have a hook into it and the particle instance modifier partially too, they should really have been made geometry attributes from the beginning. But I guess it involved touching the C part of Blender codebase and a lot of technical debt so it’s not trivial.
I don’t think physics, force fields and particle systems will be deprecated anytime soon in favor of equivalent functions with geometry nodes. We’ll see.
And finally, the big “Move UV layers to generic attributes” feature has been committed! Which means this will be in for 3.5. This will be huge for game pipelines as you will be able to manipulate uv’s in geonodes and export the mesh directly without workarounds…not that I have actually tried it yet…
Has the handling of attributes changed in 3.5? In this setup the subdivide node wiped out the crease attribute in 3.4 but worked fine in 3.5. I couldn’t find anything related in the Release notes
Blender is open. Unreal can make an official geometry nodes plugin. Anyone else can also. Blender devs are small in number, small in salary, low on time for new things, high on number of undelivered things they already promised, very high on bugs that need to be fixed.
Well. Blender devs have been giving geometry nodes a lot of dedicated attention the last couple of years and we have seen a lot of very interesting results from Blender users. It is already gathering a lot of attention especially in the vfx and games field so it would not be a surprise if Blender devs consider making a plugin for both Unreal Engine and Unity.
I think that would bring more sponsorship funds for Blender as geometry nodes can now be used in game engines and become a competition for Houdini in some measure which is very expensive.
I think Unreal might make one but they seem to have a very good relationship with Houdini. I may be wrong.
Not sure if it would be really worth it. Unreal has its own Geometry Scripting now that can be used in blueprints. I haven’t tested it yet, but it seems to have quite a lot of functionality already.
There is Alembic export which needs some care and would profit other free open source engines like Godot. I don’t think anybody actively working on Blender’s source code should be concern by a specific proprietary engine from a company that makes billions of revenue a year. Epic can afford to develop that plugin directly, not unpaid contributors who work on their free time.
Didn’t somebody make a Blender engine for Unity on the Blender market? Perhaps you could contact that person and work with them directly in order to create the plugin you want.
@robin.hohni I did hear about Geometry scripting. Haven’t looked into it much myself. Maybe that eliminates the need for geometry nodes from Blender or Houdini in Unreal engine. It will eventually tbh.
So I guess there is no need for a plugin from Blender but I feel this gives Blender users the ability to use geometry nodes in Unreal engine rather than learning geometry scripting but if it doesn’t happen, one might just learn Unreal Engine’s instead. Epic is trying to make Unreal Engine an all in one package and its getting there.
@audiumn I doubt there would be a plugin from Epic, I think they would push geometry scripting and promote it rather than plugins from external softwares. I think I will look into geometry scripting instead. Thanks.
@melvi I think in your wish you omitted couple important things.
Geometry Nodes are something that has the ability and potential to grow into almost every area of Blender - aka Everything Nodes. And judging from last two years it is slowly happening with simulation nodes being just another step.
Theoretically if Everything Nodes are going to happen how can you expect from developers to essentially rip - lets say 20%, 40% or 60% of the entire Blender codebase - and graft it onto another project? That is a massive amount of work. And it will slow down the development of Blender as a stand alone package, because the people that are responsible for GN now will need to work on GN-UE addon too.
The closest thing that works like the thing you imagine is actually Cycles. It is a sizable chunk of Blender used in other DCCs. Now look how it is developed. It has its own stand-alone repository and It is implemented in Blender as an addon. The plugins/addons used in other software (Cycles4D for example) are NOT developed by Blender devs. GN in comparison are becoming core part of Blender itself, are not an addon and don’t have a separate repository. Good luck ripping them out without sacrificing performance and usability and wasting hundreds of work-hours that could be spent on improving Blender as it is.
As others said - you expect from a team of ~30 people from a non-profit organization to do something a multi-bilion company can do itself without sacrificing any of its current goals and paying pennies for it compared to their revenue. Get real.
I never said I expected. I asked and concluded after posting and hearing from others that Unreal Engine users are better off learning Geometry scripting by Unreal Engine since its integrated into the engine and Unreal devs will be more focused on it.
Obviously, Blender devs are also better off not focusing on a plugin since Geometry scripting by Unreal engine is now a thing and should probably focus on Blender.
Nodes: Use dynamic declarations for group nodes. “one [user-visible] benefit is that user-created socket descriptions are now visible directly in the node editor for group nodes and group input/output nodes”
I can say for sure that the ability to write to actual UV data is saving a lot of time in terms of making geometry for levels in the Godot engine, why go through the process of manually unwrapping everything now if a decent chunk of it can just be automated?
To note, areas that require precise or complex unwraps can still be unwrapped manually, just tell the tree to not write any data related to those faces.
Been waiting for feature like this since GN was released. To edit/select/rotate/translate/etc generated geometry directly in viewport. That would be an awesome combo of procedural and classic modeling. I think that can be realized with something like “edit mode node”… (video example is just some editing magic
. For now it’s like 5 nodes with animation nodes.
)
