User Details
- User Since
- Oct 16 2008, 6:09 PM (714 w, 3 d)
Sep 25 2020
Jul 9 2020
Jun 3 2020
May 23 2020
The commit message should be "mesh lights" instead. I should have reused the description in the review which is way more accurate of what this actually does.
May 18 2020
Shall I push this then?
Feb 12 2020
Jan 12 2020
I'm testing this in a very simple file with an emitting suzanne mesh and a diffuse plane on the ground but I can't see any performance difference. Probably it's not worth submitting but will leave here just in case it's useful somehow.
Dec 9 2019
I can't be 100% objective since I've worked on facemaps, but this feels, smells, barks and looks like facemaps. In fact I came here expecting to see the code reusing them and was quite surprised that it didn't.
Oct 3 2019
Is it possible to capture the render state with something like Renderdoc? Might give you a few hints.
If you haven't tried it already, it might be an issue with alignment of the data in the indirect buffer (wild guess though).
Aug 28 2019
Looks like a duplicate of T69070 but will leave it up to triage to determine
Dec 3 2018
Dec 1 2018
Nov 30 2018
Thanks for letting me know. I'll leave it up to you guys
Apr 27 2018
Oct 23 2017
Aug 28 2017
Updating to latest driver fixed the delay here. This can surely be optimized better but it's not a blocker any more and it Works On My Machine (tm) now, so it will be up to you guys to improve this if you want.
May 22 2017
May 13 2017
Apr 13 2017
Jan 9 2017
Sep 10 2016
Sep 9 2016
Sep 4 2016
Aug 30 2016
Jul 22 2016
Put some backwards compatibility in the mix, and this becomes a nice headache problem ;)
Made some changes to my comment because even my own brain was printing parsing errors after reading it.
Hey Brecht, the problem here is converting from scene units (depth buffer to world space that we use in the shader will be in scene units) to the units used internally by the camera. More specifically we are interested in "what percentage of the camera sensor is covered by the circle of confusion".
Jun 19 2016
Jun 2 2016
Well, you can also go to blender installation folder, open a command line on that directory with shift-right click and the relevant command and enter then blender -R in the console.
May 21 2016
More comments...
May 20 2016
One thing to keep in mind: derivatives are not well defined if there are conditionals in the shader execution leading up to the .evaluation of the derivatives (For instance, read http://hacksoflife.blogspot.de/2011/01/derivatives-ii-conditional-texture.html). The cycles node system allows arbitrary code to run in order to evaluate uvs, therefore you might fall into issues with that. You may be able to hardcode this into some node (for instance, the UV node itself), and this would work much better.
May 16 2016
I'm afraid I'll have to agree that this is indeed not a bug - it works as intended so I will be closing this.
May 6 2016
Generally if the units were right everywhere (and from what I remember they are not...) scene scale is applied to all lengths in the scene, and then the geometry should not change and the focus would be the same. The crappy thing here is that some parameters from camera are always assumed to be in one unit (mm) which should not change with scene scale probably. On the other hand, the whole point of the focus is to keep, well, things in focus, so this should work regardless of the units of the scene.
Mar 22 2016
Found the bug report:
Hey @Jon Denning (gfxcoder), check if upgrading your Mesa package resolves this. There was a bug in old Mesa which was exactly this (VBO + selection = crash) and fixed two years after we reported it :). I think it was sometime in 2014/2015 which is when your implementation came out, so there's a chance latest versions are fine.
Mar 21 2016
Mar 13 2016
Committed in 861616bf693b78b070ada6cbc6aa79eb807fdde8 thanks for the patch
Mar 12 2016
Can you rebase this against master? I'm getting some errors here
LGTM
Feb 15 2016
Aaaah, indeed you're right. Thanks for fixing, Brecht.
Feb 11 2016
Feb 5 2016
As always for best results we would need a render target to store screen space normals.
It's probably caused by different implementations of dfdx/dfdy functions. You might be able to get rid of some of those by introducing some more bias to the AO effect, but you'll have to test it on the GPU with the issue to make sure it works.
Jan 18 2016
Jan 13 2016
Note - if you comment this out, you'll probably be able to sculpt normally but your normals will be wrong in non-optimal drawing. The change is very subtle, you might miss the error unless you expect it, it should be apparent there. Try GLSL mode it should appear there.
cdDM_update_normals_from_pbvh makes sure normals are updated even when we don't use optimal drawing from pbvh. It basically flushes the changes from PBVH to the derivedmesh itself. It's mostly useful on non-solid draw mode or when we can't do optimized drawing with PBVH (check can_pbvh_draw function)
Jan 11 2016
Jan 7 2016
Jan 6 2016
Jan 3 2016
Jan 2 2016
Actually, I agree with @Brecht Van Lommel (brecht), using BLI_polyfill_calc might be the way to go here.
It just needs to be called after every edit. Maybe we should test how well that works first?
If artists find the old behaviour still useful then I guess it's fine to keep. Added some inline comments.