As a NPR artist, this NPR engine idea is a solution in search of a problem. Eevee works perfectly well for NPR work already
2 Likes
To me, it sounds like a way to allow for better integration of things like the Goo engine, which so far was a custom hack into Eevee as far as I understand it:
4 Likes
Goo Engine is an entirely separate fork of Blender with massive changes to the source code - changes that were formally rejected by the Foundation, so they made their own branch. If the Foundation wasn’t interested in the NPR features Dillon made then, they’re definitely not going to actually care about real NPR problems now.
Last I checked the Goo Engine was going to become its own built from scratch renderer based on ideas taken from their modified Eevee and also from Eevee Next. I hope the Goo and Blender Foundation people decide to collaborate by either upgrading Eevee Next or simply make another renderer like Goo Engine set out to do. NPR is cool! 
4 Likes
Again, to me it sounds as if this NPR engine might allow the kind of functionality as it can be found in the Goo Engine. If true, it wouldn’t be a solution in search of a problem.
This proposal looks at least like a step in that direction.
3 Likes
I am not sure whether the proposal would be 100% compatible at this point with what is require in the Goo Engine. Nevertheless, I agree with you that a collaboration would be amazing. Who knows.
For an overview of the features intended to be supported see this board by Dillon Goo Studios.
1 Like
This board is for Project Juniper, the custom NPR engine Dillon is building. It has nothing to do with the projected NPR Engine from the Foundation
This is literaly quite from that proposal
3 Likes
I say the more, the merrier.
Maybe the question is: What kind of NPR work?
For example, there are many techniques which work perfectly fine for stills and immediately fall apart in animation for lack of spatio-temporal stability/coherency, which is often specifically tricky to obtain in NPR, for it often uses highly discretized representations (when compared to photorealistic rendering).
That, by definition, invites all sorts of aliasing-problems, moiree patterns etc.
Even without having fully read through the proposal, I think I take from it said proposal acknowledges this:
- NPR requires way more customization support than PBR, and requires exposing parts of the rendering process that are typically kept behind the render engine “black box”. At the same time, we need to keep the process intuitive, artist-friendly, and fail-safe.
- Some common techniques require operating on converged, noiseless data (eg. applying thresholds or ramps to AO and soft shadows), but renderers typically rely on stochastic techniques that converge over multiple samples.
- Filter-based effects that require sampling contiguous surfaces are extremely common. However, filter-based effects are prone to temporal instability (perspective aliasing and disocclusion artifacts), and not all render techniques can support them (blended/hashed transparency, raytracing).
For these reasons and because of the usual lack of built-in support, NPR is often done as a post-render compositing process, but this has its own issues […]
[…]
In addition, the NPR engine is also capable of running its own scene synchronization to generate its own engine-specific data when needed.
greetings, Kologe
10 Likes
Light linking and light nodes are not in Eevee (traditional) they are Cycles only, so not porting adding.
light linking, light nodes (or any way of adding textured light cookies), and stuff like being able to better control z buffer data would be a win for all sorts of workflows for sure. really hope that stuff gets in!
5 Likes
I tried your method, and unfortunately nothing works for me. Perhaps it’s the version of eevee next? Or am I doing something wrong?
1 Like
any changes in priority of parallax occlusion?
1 Like
Make your voices heard:
1 Like
No idea how a poll in the developer forum could be reasonably representative for the community. Even if it was, you would first need to present the current situation, the options and all that to get a usable result in the first place.
I don’t see what the value in this kind of post should be.
4 Likes
Unless users are willing to maintain render engine that doesn’t have developers attached to it, it’s developers decision to make
1 Like
To remove it, because then they can focus on the new engine. If its not for you then use an older blender version… I dont see a problem here.
5 Likes
I don’t see how that’s a decision that the community can take, honestly.
2 Likes
It seems like it might be a little early to remove it. If, for example, EEVEE Next still has some issues in 4.2 (quite likely) users could fall back to the old one while still using other new features coming with 4.2.
Not suggesting it should be maintained for long but one version with overlap wouldn’t hurt and would be safer I think. It would also make it easier to compare the two directly (for those not using Alpha versions).
7 Likes