In T97288#1340158, @warcanin (warcanin) wrote:

you have to go in flat shading to get a good result

I believe the issue lays in bpy.ops.paint.image_from_view. But I cant quite find where this operator is declared: https://github.com/blender/blender/search?q=image_from_view

In T85962#1326032, @warcanin (warcanin) wrote:

I don't even understand why is this a problem.
I am on the lastest 3.2 alpha so maybe there was something added that was not present before but if your goal is to export to a game engine you either want to have multiple instances of the same object wich you would make instance real or you would want everything to be joined on one mesh and you would use realize instance.
In the case of make instance real the UV are already there and in the case of realize instance you just have to go to the attributes of the object and convert them to an UVmap and it's done.

If anyone can tell me if i didn't understand the root of the problem it would be appreciated.

In T96003#1320337, @Germano Cavalcante (mano-wii) wrote:

It is preferable to follow the bug report convention as described in submission template and guidelines.
So developers familiar with the template will know better where they want to look for specific information.
I will edit and description...

Could I suggest adding an option for manually setting the "tilt" used by the node - *as a vector*?

In T96003#1313198, @Pratik Borhade (PratikPB2123) wrote:

Hi, Thanks for the report. I simplified your file and I think issue is related to GN generated attributes: T93440: Viewport performance drops drastically after switching from atributte visualization to solid view
Will close this as duplicate. Feel free to comment if there is misunderstanding. I'll reopen the report in that case.

T96003.blend2 MBDownload

Thanks @Philipp Oeser (lichtwerk) ! 👍

Thanks for opening this as my report was closed. The sample file request slipped through my mailbox

Please dont push on this any further :V

In T85962#1292483, @Philipp Oeser (lichtwerk) wrote:

Does this help in your workflows rBf6888b530ac8: Attributes: add operator to convert generic attributes to other types ?

Where is this new MESH_MT_attribute_context_menu supposed to be located? I cant find it anywhere in the latest alpha that I just dragged down from the build bot:

Task updated with the requested info.

I spoke with xp-Pens support, turns out the issue was that the driver had to run with administrative privileges (which it was not configured to by default) - most softwares were unaffected, Blender being the only one getting the lag as a result.

So uhm, I bought an i9-12900K recently and updated to Win11 hoping the bug would be less apparent, uhm I just wanted to say that the experience is quite unusable even with my new configuration.

In T93750#1266200, @Germano Cavalcante (mano-wii) wrote:

It must be related to the same problem described in T93408: Snap performance regression at high poll rate.

Somebody told me of a new "realize instances" node over in a Discord community:

In T85962#1239131, @Jan Kaderabek (jendabek) wrote:

No, waiting for that as well. I even asked about this on GN devtalk many times, but didn't get any response from devs regarding this (bug?).

I can confirm. Actually in the latest alpha its even worse, not you cant even apply instances at all it seems.

Does the join node support UVs yet? Its rather useless to me until it does & Boolean union often destroys the geometry

Please dont forget about this one

Thank you Jeroen 👍

Along with folders, I would also like to see an asset tagging system that's independent from folders. So you can tag each asset with an unlimited amount of tags and then search entirely by these tags, for larger databases with a large variety in assets I believe management would be easier this way.

Something to add is that the issue only occurs when textures are visible in the viewport - might help with figuring out whats going on

If you do have the freedom of adding features as you like to the Boolean modifier. I certainly wouldnt mind if we got to see options like inset/outset (moving the area that would normally be cut out along its normal and creating an extra edge around it, so it would act kinda like edit modes inset tool).

Ah, thats fantastic. Im deeply in love with geoemtry nodes already :) I hope we will get to see fast booleans some day as well

In T89534#1184627, @Hans Goudey (HooglyBoogly) wrote:

Thanks for the report. However, this is actually not a bug. The confusion comes from the implicit conversion to mesh in the curve modifier stack. When you add a bevel or subdivide modifier to a curve (or any generative modifier), it is converted to a mesh.
Meshes can't be used for curve deform, so the curve that's used is the last point in the curve modifier stack that is actually a curve.

In 3.0 we are building the start of curve support in geometry nodes, there the conversion from a curve to a mesh will be explicit, so easier to reason about.

Any chance on seeing some basic support for geometry nodes modifiers & node groups any time soon?

In D8445#293039, @David Swift (rococo) wrote:

In D8445#292725, @Mr Chocolate Bar (WillyWonka) wrote:

However the downside has then been that mirroring & using deform modifiers have always been difficult because of the issue described here.

I feel like the real solution here is to extend face instancing to make it behave more consistently over mirroring (e.g. by computing transforms based on texture coords like I suggest above).

Benefits:

• Only adds options where they make sense contextually: in the face instancing options
• Improves face instancing
  • More easily visualized and edited using existing tools
  • Makes it easier to drive instances procedurally e.g. through generated texture coords
• Provides a more natural transition to geometry nodes in the future

Downsides:

• Patch doesn't exist yet! Although I did implement a basic prototype
• Deciding which way round the coordinate system belongs will probably be a big discussion

Seems there is an abandoned branch for this already: https://developer.blender.org/D8445

In D8445#279243, @David Swift (rococo) wrote:

Would it be fair to say at this point that Geometry Nodes provide the generalized solution to this kind of problem and the old way of doing instancing will slowly go away? If so this "fix" would therefore be unnecessary.

On the other hand the same problem should be considered if creating a node that converts faces to points/instances. My recommendation would be to use the texture coordinates instead which are more easily visualized and operated upon.

Also I wrote a summary of all the features requested in https://developer.blender.org/D3203 , I also added in some suggestions of my own here:

I have a design concern about having bake materials like first proposed by @Brecht Van Lommel (brecht) , if there are some other nodes in-between the output node/bsdf node and the bake-to-texture node and the "bake material" is supposed to be able to bake other materials on the objects its assigned to, from an engineering standpoint how would the baker know what to write to the texture or any attribute representing the texture?

Hi, Im interested in doing an attempt on implementing this, Ive been looking a little at \source\blender\draw\engines\eevee but Im struggling to figure where exactly code for a baker would go.

Sorry about the intrusion but it would be awesome if we got to see the fast solver with geometry nodes, the exact solver is not very useful in many situations with complex geometry (at least when realtime feedback is important) - it slows down the viewport too much.

In T87270#1142616, @TheRedWaxPolice (TheRedWaxPolice) wrote:

Hmm, did you try clicking the icons on the right?

Its worth mentioning that the objects still get pasted, so in my case here where I used the collection as a bool cutter collection this results in a bunch of ghost cutters that I cant alter, but that still cut into my mesh.

Fantastic. I can see Bastien made a fix for it already 👍

In T85931#1118027, @Philipp Oeser (lichtwerk) wrote:

Cannot reproduce here.

Are you sure you actually switched to the appended scene after appending?

If you would intend to implement this yourself, then this would be fine e.g. on DevTalk to discuss it with other developers.

Is there any other way that I can present the idea to the developers?

In T81931#1038784, @Hans Goudey (HooglyBoogly) wrote:

It's an interesting idea. Although I sort of feel the need for all these width options might be a sign of some other less visible design flaw in bevel. Not sure though.

In T81931#1038784, @Hans Goudey (HooglyBoogly) wrote:

This sort of detailed feature request really belongs on https://blender.community/c/rightclickselect/, not here. Anyway, the policy is not to allow feature requests on the bug tracker.

It's an interesting idea. Although I sort of feel the need for all these width options might be a sign of some other less visible design flaw in bevel. Not sure though.

Personally I would like to see this get merged into master as soon as its any what useable. The sooner we have anything that saves us from having to append blend files manually the better!