I’m Colin, and I’ll be working for this GSoC project adding node previews for nodes in the shader editor.
During this summer, I’ll do my best to improve the way people previews the nodes when editing shaders.
Synopsis
In Blender, the material and shading system are controlled via node-trees where the user creates a material with a combination of nodes (mixing colours, reflectiveness, …). This system produces a complex material from a simple shader tree. So there are currently two ways to get feedback: the effect of the material on the objects of the scene and a small preview on primitives. Overall, the current system only exposes the end result of materials.
Previously with the blender internal rendering engine (in Blender 2.79, in 2019), the shader nodes used to have a small preview area where the user could see the node’s effect. It was removed since (Blender 2.8 and Eevee replaced the internal render engine causing some major changes in the code). My proposal is to bring this functionality back. Indeed, it is one of the most expected features by material artists.
Benefits
As it was the case with the old Blender Internal Renderer, having node previews was useful to have a sneak peek of the middle tree effects. By previewing the node effects, shader editing will be a little more responsive and node trees will be easier to understand according to artists on the feature proposal. This becomes especially useful when artists create procedural textures and complex procedural shapes inside the material shader. Regarding the practical part, a toggle button on the top bar of each node will make it easier to preview effects.
Pdf proposal
Here is the complete proposal for the one interested in reading it. (keep in mind that the schedule is approximative and I might differ a bit) Pdf here
Feedback
Please use the following topic in order to give useful thoughts about this project.
Today is the “official” starting period of this Google Summer of Code project.
But, during the community bonding period, I’ve been doing some work in advance because my school will end a bit late.
Anyway, here are the things I’ve been doing for the pat two weeks :
Understand the task I’m working on : exchange with other developers about the different ways to uniquely identify each node for previews.
Browse the code to explore the systems already there : SimulationZoneID, ComputeContext, bNodeInstanceHash.
Decide to use the ComputeContext basis for node previews identification.
Read and understand the best I can of the render_preview.cc file used to generate previews for materials, collections…
Dealing with UI : I had discussion in the Feedback thread about the preview design. The main problem raised by users was the lack of consistency when toggling the preview (the node would change size). To have a uniform preview system across node editors, I submitted a first patch regarding the compositor nodes to fix this design in all areas. See here.
When doing all of this, I experimented many things and I pushed them in a branch. This branch will probably track the future progress, but as I mentioned in the proposal, I might restart from nothing (while keeping the main ideas in mind), to have a cleaner design (code meaning). And when rewriting, I might do it in another branch (will decide with Thomas).
That it all for those two and a half weeks, I’m looking forward to having more work done and little first demos.
PS : I’ll put here the time counted by my computer spent on XCode. (Please do not consider it too much, because some more time is spent exchanging in the forums and thinking designs on the paper)
fix memory leaks due to preview rendering stops when entering/leaving nodegroups
have it all work seamlessly in release builds
complete the UI patch
TODO next week :
Mainly work on refresh event (currently refreshing endlessly), this involves dealing with partial tree modification (we will probably not want to refresh all previews when a single node is modified). I’ll have to understand how the node editing events work and how to handle them.
This was my latest full week of class and I did not have much time to work mainly due to some body issues (too much sport ). I’ll be fully on GSoC next Wednesday .
I did :
fix wrong linking when nodegroup is connected to the output
first implementation of previewing event : when the nodetree is updated, tag for refresh every nested tree
some cleaning of the already done work
fix previewing nodegroup output node
try to force eevee rendering when previewing non-shader nodes (I will probably remove it then)
Interrogations of the week :
When to redraw previews ? The ultimate point would be to redraw only when the left graph of the node is updated, but Blender doesn’t have this feature yet, so the approach taken was to increment a nodetree state of change (variable i) and then compare it to the preview already drawn. If the variable of the preview differs from i then the previews need to be rerendered. It is far from optimal but it is the unique option right now.
If some wants to try at the current stage, I link here a build from yesterday.
TODO next week :
The current state of the project is pretty neat, and I think the fundamentals are here. This is time for a first optimisation thing : AOVs (Arbitrary Output Variables) which will be used for optimising non-shader nodes.
Sooo here are this week’s goals :
find a way to gather multiple nodes in one render process
probably useful to add a preview queue (non shader nodes would be rendered first because they are faster to render)
try a first implementation of AOVs by adding AOV node right before rendering the nodes
It has been a month now since I started, and it’s time to explain a bit how it went. When I was coding I always felt confident about what I was doing, but I struggled on planification and finding the right approach. That was not really intense due to this school period, but I managed not to be late.
Communication have not been hard I can say, and blender chat really helped me some times. One quick lesson I learnt is that I should always think twice before asking others, because in most cases I could find a solution by myself a soon as I formulate a comprehensive question.
My class finished at the middle of the week, so I was able to work much more at the end of the week and fully do the AOV optimisation.
I did:
add AOV support for every non shader nodes (still some issues and limitations)
learn more about thread memory sharing (locking, mutex, …)
fix a lot of issues coming from this addition (deadlock between thread, passes management)
update tag for the ui to redraw the nodes when the preview render is progressing
Todo next week:
fix a bug about AOV that wont render when nothing is connected to the Surface Output of the material
finish AOV implementation : background scene
maybe move the previewing stuff to make it listen to the events (node modified, preview enabled…) (discussion needed with the mentor)
if times left : make some plans for the UI/UX touches : very important to do because the user will need to be able to use it correctly in order to try it.
This was a tough week for me, I had to deal with many things at the time, and it was hard to manage. I did many mistakes by wanting to exchange with others while coding on multiple branches. Lessons to learn here: take more time to analyse the situation, and the priorities; dont rush things and prefer quality over quantity.
I did:
try to fix the AOV related bug (took me a few hours to understand that I did not know enough to do it quickly so asked Brecht for it)
This week has been productive for me, and I’ve been able to spend many hours on the project.
This week challenges:
I wanted to rebase my working branch on the latest main after the merge of a patch I did on the main branch. This put all the new commits as mine in the PR, which showed a change of hundreds of files.
What I did to fix this was first to extract my precious diff git diff > my_patch.txt and then force pull my main branch from the origin.
What to learn from this ?
NEVER work on the main branch even locally, keep it in sync with the origin main branch. This way the diff between a branch and the main is always what we want.
It is probably not what people would recommend, but it will avoid me many errors and problems.
This week started slowly, I wasn’t in a great shape, but I managed to do more things at the end.
Nothing special to mention from my side, no blocker nor incredible discovery. I’ll probably publish those reports on Friday from now, because I find myself forgetting the main points of the week when thinking on a Monday.
I did:
have the compositor transition to ImBuf landed
use ImBuf for shader previews in the main patch
use a Render to gather all node previews and deal with locking/unlocking the result
fix a memory leak happening for a few weeks (I used a constructor for a struct and just freed the struct without calling the destructor)
remove the ability to preview some useless nodes(preview wise) → it simplified many many things, I should have done it before
a lot of code cleaning and fix minor issues
add comments, rename variables
→ Now the patch is ready for review, and I’m honestly proud of it
The program for next week is currently undetermined, I’ll try to be really responsive to have some reviews on the patch.
No demo for this week, because nothing changed for the UI/UX.
Nothing new this week, it has been slow at the beginning, but the end of the week was really tense.
The main goal of the week was to fix all things that could go wrong in the first functional patch. I am finally more efficient when it comes to git chrckout/commit/merge and around code stuff. It’s also easier for me now to browse the code seeking for the origin of a bug, and figure what to do. I’m really proud of the way things happened until now, and it improved a lot my student skills.
Some things I learnt along the week:
C++ unique_pointer and std::move, that was really hard to understand (I already tried few weeks ago)
git hooks which allows me to format automatically the modified files before committing (very useful)
I did:
start thinking about a way to update individual node previews
fix all errors and wrong code practices mentioned by Hans and Brecht in the patch
Next week:
implement individual node preview refreshing
update the release notes when the patch will be merged
recover from this long evenings I spend bug fixing the patch
I hope to end the major work by the end of next week, in order to go on vacation.
I implemented everything that was missing, I have it all ready on my hard drive and pushed on my clone branches.
I’m still waiting for the main patch to be merged in order to create some PR (Pull Request) about the other changes I worked on this week.
Now that the major changes are all or under review or ready for review, I’ll take some time to prepare the new year incoming (reading books, studying…).
I did:
add the background scene for nodes rendered using AOVs
refactor the previews of the output nodes (material/group/AOV)
stop the render of the previews when going in/out of a nodegroup
AND add the support for rerendering of only the updated previews
→ this involves a thing I wasn’t aware of: false positive. In a nutshell, that is when a node preview is redrawn but nothing was changed. I try to limit the amount of false positive that the user will experience, but that is a tough question.
Little demo of the partial rerendering of the previews:
Next week:
Create new pull requests for the latest changes I made, and be ready for modifying them
Begin the elaboration of the final document for the GSoC
Nothing was done this week, and I’ll be in vacation next week too, but I might be able to do some fixes and complete the final submission document for the GSoC.
I took some time to hike in the mountains this week so I was unable to code.
However, I completed the final submission file for GSoC, you can find it here.
I also fixed a bug with output nodes a few minutes ago PR 111604.
As a student, I’ll be back in class in a few days, so I apologies in advance for being hard to reach in the future. I’ll start my second year of computer science engineering. At the end of this upcoming year, there will be a very very important exam, so I’ll mostly focus on studies this year. I’ll come back with other projects later on.
I might be able to do a few fixes for this project during the holidays happening every two months.
I thank you all for the help and support during this summer, it has been an incredible experience; wish me luck for the upcoming work.
). I’ll be fully on GSoC next Wednesday 
.