Or make do with doing it via the modifier interface until then. It’s inconvenient, but not that bad.
I think one of the main misconceptions most users have is the "visualize everything in the viewport" concept, bias coming straight from game engines
Blender is not a real-time engine, the rendering process is done separately from the viewport and can handle a higher workload with ease.
2 Likes
It’s not a misconception. It’s a goal to strive towards.
The offline rendering software is increasingly trying to give the users as realtime and interactive feedback as possible, and the game engines are increasingly trying to get their realtime rendering capabilities as close to offline renderers.
We should be able to visualize everything in the viewport. Viewport and rendered being two separate things is a paradigm that should be a thing of the past. We are not yet technologically there, but 10 years from now, the idea of working in a viewport that doesn’t represent the final image output will be a laughable prospect.
4 Likes
It’s an interesting question, in environmental art at least, technologies between DCC’s and game engine are so drastically different that it seems like a very improbable challenge to resolve.
Oh I’ve done that. It really feels like a hacky workaround that’s incomplete.
For one you can’t set the default for inputs to be fields and have a specific default named attribute. You also cannot do that for outputs as well. Having to enter these values everytime I add a new modifier gets really tiring. Unless there’s some recent update I’ve missed in 3.1 so far?
I’d say we are there already with Cycles viewport shading, however it’s not very convenient to work with geometry in Cycles mode, so you still need to rely on Workbench overlays. And that’s where the biggest bottleneck is in Blender right now.
Although the viewport doesn’t need to have final render quality to be useful. In fact final render might have too much visual clutter to be usable when editing the scene. Viewport just needs to show accurate-enough visual representation of the final geometry. So in case of Geometry Nodes it would mean displaying full amount of instances by using smart optimization like distance-based culling, proxy geometry, point clouds ,etc.
1 Like
I would like to give a “small” QualityOfLife (QOL) feedback for the GN.
It would be very helpful if we had a “Mute/Bypass” button on the top right (optional/ yes-no) in the form of a Monitor icon to bypass a node without relying on the Keyboard shortcut abacus.
I’m sure that a lot of people (including me before) do not know such a feature exists let alone that it’s called Mute
You find it also in the right click context menu, and Mute is a quite common term in software slang for hiding the contribution of “something”.
Anyway a hide icon would be nice i guess.
Note that M key toggles the “mute” state, so that you can mute many nodes at once, and you can also do fancier stuff like enabling and disabling many nodes at the same time.
2 Likes
Anybody can confirm Blender 3.1 (any build) crashes when painting density (using vcols / weights)?
For bugreports it’s better to use the bug tracker (help → report a bug). Over here bugreports will get lost/forgotten.
Also, your bug is unrelated to the topic of this thread, because there are no Geometry Nodes in your file.
That said: no I cannot confirm. Over here it paints just fine. Best post all info to the bugtracker, that way probably more people will get to test it on different systems.
There is Geometry Nodes modifier on that plane, with the most basic scattering setup. Any Blender 3.1 crashes once I start painting the density.
I was about to ask here before bothering devs with that.
Ah, I see. My bad. Because the nodetree was zoomed in on an empty spot I mistook it for empty.
But my main point still stands: report bugs in the bug tracker. That’s what it’s for.
Well, this is the developer forum. So you’re actually bothering the devs more by posting it here 
If you report it as a bug, it just lands on the pile to be looked at. Here it asks for attention right now.
I don’t blame you, I assume you try to do the best thing. But I assure you reporting bugs in the bugtracker is better than here. The bugtracker has all the tools available to sort bugs/request more info/not forget about them.
1 Like
Reported the bug here, it has been already confirmed: ⚓ T95205 Realize Instances node saved in 3.0.0 causes Memory leak when painting
Sorry for bothering.
3 Likes
Thank you for reporting!
[modmoderVAAAA] Thanks for the interesting solution to do a solidify, I was having problems with Normals being reversed. after a bit of playing, I came up with a different way of doing a solidify. using curves and a curve to mesh. it seemed a bit simpler (apart from the horrible Vector maths to point the curve Tilt in the correct direction. it is just angle between 2 vectors with a hack to also get negative angles)
This currently only works for positive offsets. I would need to add some checks and switches to make it work for negative offsets but though I would keep it simple
is there a cleaner way to calculate the angle between a vector and a normal and being able to determine positive and negative angles
1 Like
Is what a known issue? We’re not telepatic you know 
In case you mean the offset of the instances to your base mesh, isn’t it just because of the random offset added to the point positions ?
I think they are referring to the (obviously incorrect) object dimensions in the N panel.
ah yes, that’s probably it.