- User Since
- May 29 2021, 11:40 PM (20 w, 6 d)
Aug 26 2021
We will need more information. Are you exporting .fbx files from Maya and importing them into Blender? If so, then it's possible that Maya and Blender are expecting different units (centimeters vs. meters).
Jul 8 2021
I believe this is intended, albeit surprising: deleting the object just unlinks it from the scene. It still exists, just without any users.
Jun 25 2021
Ah, good find. I must've been scrounging around with the wrong keywords.
Jun 24 2021
I can confirm this on the 3.0.0 alpha.
I'm not observing anything significant on Windows 10 (with a GTX 1080) or on Ubuntu 20.04 (with integrated Intel graphics) with that file.
I can't reproduce this on 2.93.1 or 2.93.0
You had the node tree pinned. This causes it to remain in the Shader Editor, even if you select an object with a different material.
The problem here is that Remesh doesn't keep any material data -- you can see this by just assigning a material to an object and then adding Remesh to its modifier stack. It's not specific to Geometry Nodes.
Jun 23 2021
This may be a duplicate of T89330.
It looks like the file is missing -- can you attach that to the report?
I can reproduce this. Here's the failing assert:
The example I've got is so fragile that it might not be very useful (exactly recreating the topology by hand doesn't cause the bug). I'm going to put this on low priority and leave it on 'needs information', so that it isn't in the triage backlog. I will update this task if I get something more interesting.
Can confirm this in the 3.0.0 alpha. I get an assert failure in the debug build:
That behavior occurs in image editors because you can't have a pixel with a brightness of more than 1 -- that's the hard upper limit. A Multiply layer multiplies the values of pixels together, so, in that case, you do always darken.
Can you attach system information? You can save it from blender by going to Help > Save System Info. Drag the resulting file into the comment box and it'll be attached.
Yes, I was getting a lot of crashes from this. Many operators will crash Blender if given NaN coordinates.
Okay, I've replicated the issue and updated the bug report with the details.
It looks like it's importing the bone as an empty, rather than creating an armature with a single bone. It's definitely something specific to the .fbx: if I import the .dae and export an .fbx (with no leaf bones), that .fbx imports correctly with a bone.
Please add a written explanation of the bug -- a video alone is ambiguous, since we can't tell exactly what you're doing.
Great! I'll close this report, then.
Thank you for the good .blend!
Jun 22 2021
Ah, yes, it's a lot more consistent with the original suggestion of using the monkey head -- I almost always crash on Windows. Still nothing on Linux, however, which is quite odd.
I'm now having some trouble getting this consistently -- it's happening only some of the time on Windows and not at all on Linux (both on 2.93.0). I do not see a clear pattern, such as the way in which I draw the cut zone.
I can replicate this on Blender 2.93. It also crashes a recent 3.0 debug build, producing no output.
Great, thanks. This looks like a duplicate of T89360. A fix was merged, so the next alpha build should have this fixed. I'll merge this into the older task.
Can you attach that .blend file to the report? That will make it easier for others to replicate the problem.
If this isn't something that used to work, and is now broken, then this is probably not a bug.
Added some context.
Proposed a fix in D11672
Can you simplify the .blend file and still cause the crash? We'll need an example that causes the problem.
Looks like rB211d7ff3cf27 lost this sanity check:
Do you have an example of the expected behavior, and which version of Blender that you got that behavior?
Oooooooops, I forgot to actually attach it...
It looks like you attached an opengl DLL to the task. Did you mean to upload an image?
Jun 21 2021
Since there hasn't been any further information, I'll go ahead and close this task.
I have gotten an actual crash on the 2.93 release build. I think something is getting corrupted -- it causes undoing and reverting to silently crash Blender.
I'm not having any problems copying a plain Cube between 2.8, 2.93, and the latest 3.0 debug build on Windows 10.
It looks good on the commit before rBa3f091d7ceda ... but I'm having weird problems with conflicting function declarations, and can't see if that commit is responsible or not! Perhaps someone else could try building that?
This was introduced by rB1c22b551d0c1
It definitely looks different in older versions of Blender. I had a copy of 2.8 lying around, and I can't see the sharp edges that show up in 2.93
The popup says "unknown location" because it can't figure out which file it was in when it had an error. The actual problem will be shown somewhere else in that popup.
Jun 19 2021
I think this is the same root problem as T89122
Running this with a debug build fails an assertion: