Wasn’t this modifiers going to be the modifiers created using nodes themselves so they could be modified?
Instead of being C++ blackboxes.
Don’t get me wrong, I see the benefit of this, but wasn’t the idea to recreate the modifiers using nodes that could then be modified and used as a starting point of a more complex thing?
Last I read, the majority of modifiers will get their own hardcoded node version, but a handful (like the array modifier) will not be ported that way because of the ease of recreating its functionality.
I am pretty sure there is a planning article on the dev. site that talks about this.
Some, such as displace maybe, but things like remesh modifier? I mean that’d be very difficult to do with some atomic math nodes, and probably perform a lot poorer than pure C++ code. Even in other procedural, node based modeling DCCs, things like remeshing are self contained nodes you can’t really “open” any further.
If some advanced modifier were recreated using atomic nodes, their interior would be so complex vast majority of users could not make sense of it anyways. Especially given how GN are designer, where even the most trivial operations usually end up in a long, confusing linear graph.
And if you, instead of atomic nodes, wanted to have some higher level nodes, then you’d eventually arrive at a conclusion, that having a remesh or decimate node is the right level of abstraction, and there’s not much need to go any lower level.
Yes, some operations me be needed as C++ nodes, but the idea behind all these nodes was to get as much performance as with C++, I get your point about remesh, but not about Solidify, maybe some basic operation inside solidify has to be done in C++ as a generic operator that could be used in other trees, but not the entire node.
What you say is true, however things like a fluid solver are done in nodes in Houdini for example, granted some basic operations are basic foundation generic nodes that have to be in C++, but again, it’s not the case of Solidfy, and it was not the idea behind Function nodes.
If we start getting hardcodes things I’m afraid that this will become black boxes again, like the modifiers, and the idea of replacing the modifiers with node trees that you can improve/modify won’t be there any more or will be limited.
So to recap, I get that some basic operation nodes have to be done in pure C++, but something as the Solidify modifier should be a node group with as much as possible functionality exposed and created with nodes, and there should not be any performance difference with the C++ version, that’s the foundational idea of nodes for all this.
the other side of this coin is the possibility that we end up with slower and less effective versions than the built-in operators. I could see a future where devs decide to stop maintaining and deprecate the ‘old and fast modifiers’ in favor of the nodes-only version. maybe i’m just paranoid 
Last I checked, the geometry nodes work in much the same as Cycles shader nodes using SVM, in that they are compiled into a program rather than interpreted (ie. they are not backed by Python for their core function).
For evidence, switch Cycles to use OSL for complex setups for interpreted shaders, and notice how much slower the rendering is (at least this is how it was in 2.79, I have not checked since).
That’s not an option, it has never been, it was mentioned several times along time with Particle Nodes, Function Nodes and then with Geometry Nodes 
You two arguing what geo nodes ought to be is hardly appropriate in a students GSOC weekly reports topic, so I split off this conversation, please try not to stray too far off topic in the GSOC threads in the future.
“Proper port of the functionality of the following modifiers to the new Geometry Nodes system (In order of priority): Smooth Solidify Remesh Decimate Bisect (optional)
Existing Modifiers will be split up into several atomic nodes where it is appropriate. Nodes will support different available geometry types (Mesh, Point Clouds, Volume, Instance) where possible. New nodes will be tested and supplied with developer and user documentation.”
While I do agree that it would be inappropriate to argue about what geo-nodes ought to be in the gsoc page the deliverables clearly mentions splitting to atomic nodes where appropriate. This to me sounds like it would be appropriate to talk about how exactly that is done. That being said in general sense I think that is in large part a conversation he should have with Lucke, since he would have the best idea how that first in the over all design of the whole system.
In philosophical sense I do think all of these should be composable from atomic nodes in completed geo-nodes system, however, I also feel that especially for remesh that would be out of scope for a gsoc project. Also far as I can tell a gsoc project implementing bunch of modifiers in a black box doesn’t bar or stop the geo-node projects from evolving towards system that could do the same things with node groups.
Still, though, I do think solidify is likely to be one of the better starting points for composing out of atomic nodes so it might be wasteful not to experiment with the idea there.
No-one is trying to stop that, everyone can happily carry on in this thread, I merely split if off from the weekly report thread since that was not the place to have such a conversation.
I understand the split, not a big deal
Also @3Rton
Existing Modifiers will be split up into several atomic nodes where it is appropriate
That is exactly what I was referring too