- User Since
- Oct 7 2012, 2:37 AM (362 w, 3 d)
I will investigate further.
Overall looks good. Just a few lines worry me a little.
What about this line. Will not have problem too?
@Joana Zimmermann (Chutney), try to run blender_debug_gpu_glitchworkaround.cmd that is included in the download and confirm that the problem seems to be solved.
This can help in the investigation.
I'm not sure, but check V3D_AROUND_LOCAL_ORIGINS and try using tc->center_local.
I spent yesterday and today investigating.
I fear don't have much to do.
These AMD GPUs have reached a state that requires workarounds to workarounds.
Depending on how many users use and report problems on these cards, I can look into a solution again.
But for now ... archiving :\
Interesting to see that CTX_SCULPT and CTX_PAINT_CURVE can be set at the same time.
This may however be hiding some other bugs.
In addition to this patch, I propose to create a new flag (T_SCULPT) for t->flag and replace other possible errors due to testing with t->options & CTX_SCULPT.
I can no longer replicate the crash.
However now I see a glitch when I select the vertices with circle select.
I can't reproduce the problem with the last build.
Could you share a simple file with the steps to reproduce the problem?
This would facilitate the investigation.
@Campbell Barton (campbellbarton), do you know what may be happening?
This works as intended.
In Blender an object can only be scaled towards its axis.
Therefore if the axes are not well aligned, an approximate result is obtained.
You can solve this by making a parent with another object but this aligned to the cursor and then scaling the parent.
- Rename transform_op_mode_*.c to transform_mode_*.c;
- Rename transform_op to transform_ops;
- Rename transform_op_orientation to transform_ops_orientation;
Ok I understand your concern but you have to consider the other side too.
If, as before, cage is used for occlusion, some visible vertices cannot be selected.
Cases such as the modifier mask or subdivision may mislead the user into thinking these vertices can be selectable:
Mon, Sep 16
Please use the bug reporting template and provide all the requested information.
Good to know :)
The cursor does not move away in my case. Did I get something wrong?
But in fact, the proportional edit circle doesn't really make sense when moving the cursor.
This is something to be discussed.
Can you try running blender_debug_gpu_glitchworkaround.cmd (that is included in the download) to see if the problem may have any known workarounds?
If the problem does not continue this is a good sign.
I can't reproduce the problem on my end.
This is a known limitation.
Can you provide a simple file to make it easier to investigate this problem?
Sun, Sep 15
Fri, Sep 13
Here the commit to fix the assert rBf7e8b580989e
For me it's ok. (The assert can be fixed in another commit).
The problem is that the Snap with of type Closest uses the bound box to snap.
But in this case the bound box varies with the movement.
One solution would be to use Texture Space as it does not change.
@Campbell Barton (campbellbarton), any ideas?
It's ok now.
Thanks for the patch, it will be committed.
Thu, Sep 12
Is there a flag in the transform code to apply the scaling in object space?
I had some white space warnings when applying the patch.
- Fix unused thread
- Fix elem_index_dirty flag
It's ok for me.
- Use new BLI_math function;
- Fix compiller errors.
- Rebase to master
Wed, Sep 11
We already have bug reports about boolean failing.
An overview of all these bugs can be seen in T47030
This is not a bug but it is how the shadowmaps used by pbr engines work.
It's a limitation due to shadow resolution, but can be mitigated for example by enabling the Soft Shadows option.
Try to run blender_debug-gpu.cmd that is included in the download. After Blender closes, the logs will be in a text file which can be attached here.
It seems that the driver of your video card is not the most current.
Try installing the latest version of the drive from the Intel website:
Tue, Sep 10
@Brecht Van Lommel (brecht), in pre 2.80 versions, the occlusion was tested using the cage faces.
This behavior has been changed without much consideration.
Whether using the cage, or the final mesh, each case has its benefits.
I wonder if it's really better to go back to the previous behavior.
As can be seen in the related report, this is an old known limitation.
I didn't notice performance changes on Windows + Intel(R) HD Graphics 4000