I think he meant a way to make it look like just another modifier.
In Max, you can’t tell if something is scripted or made with C++.
Both behave exactly same.
It is different than loading a preset.
1 Like
That is exactly the golden path. If done right, this is the way.
8 Likes
This is the way.
1 Like
Which will be passed on a tricycle. One wheel is triangular, the other is square, and the third does not exist at all.
1 Like
What are you talking about, and how does it relate to Blender?
Was ChatGPT used to write this response? We are not arguing against the idea that the developers have made mistakes in the past (since FOSS did in fact used to have a bad reputation), but just what is a custom modifier in your eyes as opposed to the custom ones people are making already with nodes (which actually have performance unlike Python-based addons)? For starters, they can already be declared a standalone asset and used in any file through the asset browser, does that not qualify just because it was not done with a C++ based API in Microsoft Visual C?
1 Like
He’s talking about the Tricycle of Metaphorical Analogies, man. It’s deep stuff.
7 Likes
Its only a matter of time when those pseudo modifiers would fail in certain area complitely, or will not give enougth access to necessary data to create something.
After that people like me would continue to blame developers who always try to reinvented the bicycle or some “new way” and fail most of the time (not always, of course) and blender fanboys will continue to talk about: “its just need more time to polish, its not easy to change that amout of code are you a coder? no? when you simply dont understand”, etc.
And btw, what you trying to tell me, what geonodes have better performance than C++ or performance are the same?
Geometry nodes being heavily multithreaded alone disproves the ides of them being written in Python or some similar interpreted language. Try creating hundreds of thousands of hair strands like in the recent demos, if those nodes were written in Python they might as well all be labeled Crash to Desktop.
I do not know how many people think otherwise, but it is in fact possible for nodes and other modular systems to be written in a compiled language, even the now defunct BGE sported bricks that were far faster than doing all of the logic in Python (because they were written in C++).
6 Likes
You’re literally talking about the WNBA of 3d apps. Yes, those things will be said because they are true for at least the next few years as they try to attract more and better developers.
Currently, evolution of geometry nodes is a testimony of the opposite.
At their start, they were limited to instancing of meshes without access to attributes.
They evolved to include edition of meshes and mesh attributes usable by materials, to cover Curves and Volumes types.
In a near future, they should cover Grease Pencil data. And simulation nodes will be created.
Expansion of amount of data treated by nodes is incremental.
A new chunk of data is added, tested, corrected and polished. And then, another one and another…etc.
For the moment, there is no sign of a limit that would stop this expansion.
The plan was to make “everything nodes”.
It worked for materials. It is working for geometry.
There is no reason to think, that will not work for simulations or rigging constraints.
When limits of system would have been identified, it will be possible to use that knowledge to think of a model to bypass them.
But nobody has infused science.
But until now, geometry nodes expansion only allowed to create more and more things.
A stop in this expansion would just correspond to a stop.
Ability to do what can currently be done with Blender, will not disappear because of a slowing down or stop of geometry nodes development.
That could only be the case because of massive regressions.
Blender development policy is to treat any regression has a priority, unless it is planned to abandon a feature or to accept it and find a workaround, during development of something big, that should solve it.
6 Likes
One strong point of a node based modifier is that you can adapt it to your needs when it fails. You can not do that with a hard coded modifier.
6 Likes
I spend a couple of hours figuring out how to let users change N-panel category for my add-on panel and turns out its frustratingly hard, but made it work after some hair pulling. If anyone wants to learn this I’ll share the method (which I copied from Photographer)
Is it that hard?
def n_panel_category_update(self, context):
panel = MY_PT_viewport_panel
bpy.utils.unregister_class(panel)
panel.bl_category = self.n_panel_category
bpy.utils.register_class(panel)
n_panel_category: StringProperty(
name="N-panel category",
default="My Category",
update=n_panel_category_update,
)
I use more or less this setup for my add-ons, and it works pretty well.
2 Likes
This part is easy, what drove me crazy was figuring out why panel was reseting to default with every time I opened blender, turns out needed something to be registered in the init and didn’t see that mentioned anywhere
n_panel_category_update(prefs, bpy.context)
searching for this line took me almost an hour
Yeah, that’s a good point actually, unfortunately there’s quite a lot of stuff to do with the API that you kinda just need to figure out on your own…
If you’re not already there, I’d definitely recommend checking out the bpy discord server, it’s really good to ask there if you have an obscure problem that you can’t find the solution to online.
3 Likes
Every day, I come into this thread expecting some bat guano.
Every day, I leave this thread disappointed.
9 Likes
here you go !
Have a nice day !
5 Likes
Today was a good day.
4 Likes
