I’ve done this render quite some time ago with 2.79. I want to recreate it with 2.80 and my new knowledge, but unfortunately there’s a bug with particles not following displacement. Whole particle system is going to be rewritten so I’ll wait I guess.
Known issues:
Non hdri lightning. The background here is just image plate. And it’s lightning is reversed xP (clouds shadows are on the opossite)
Noise: render took 19 hours if I recall correctly, but heterogenous volume scattering is terrible to render.
Also, there was no multiple importance on volume back then.
Materials: those medium bushes there have no principled shader. They look terrible.
Aroud 6-7 million particles here.
You can get pretty good fog results by just using noise and gradient textures as well … I was about to show it to you with Eevee but the current build appearently broke the former working gradient texture support
But yeah … just use the gradient texture to get the fog on the bottom and multiply it as with a noise texture. Use the distort value of the noise texture to get more intresting fog-like patterns and also just play with the values a bunch ^^;
oooooh … you were talking about the grass and not the fog … my bad, that was a misunderstanding. Also I said I wanted to use Eevee, because I didn’t want to render for a long time to just get some feedback across.
Okay then I might not understand, what you’re using the particles for. But I’m kind of curious so if you want to explain it to me, i’d be interested.
Also I currently don’t see cycles development being slowed down by Eevee. First: we’re still getting a bunch of new features for cycles with 2.8. So there’s still work being put into this engine.
Also: since both engines work really similar (from a users perspective), we get the benefit of increased workflow speed with cycles, because you can use Eevee to make procedural textures and “shader drafts” for cycles pretty much in real time.
Also: you can now “outcource” render intensive stuff like volumetrics to eevee and save render time in Cycles using both engines and compositing.
You can now also animate your scenes using Eevee and render them using Cycles so animators can have a much better understanding of how their animations will look like when rendered.
And last but not least: making Eevee and making Cycles requires similar, but still diffrent skillsets and if I’m not mistaken, the core developers of Eevee have not worked that much on cycles before.
If everyone working on eevee was put to cycles we would have much more stuff done.
Particle system is going to be rewritten from top to bottom. We need path tracing optimizations (looking at e-cycles there) and other path tracing alorithms, like metropolis. Cycles sucks with caustics, if you want to render anything that’s connected with glass and light as the main theme - you’ll get quite a headache or dark, noisy results. We also do not have proper prism effects - I know cycles is not spectral renderer, but it should be made up at least in semi-way, because now it’s not physically accurate at all.
Displacement still has no proper support for modifiers - so for example particles will be rendered in the place before displacement. There’s still no one tile rendering - one thread per one renderer is still a thing. Good thing we have cpu+gpu, but that’s still not the best way.
The thing is … I don’t think, that some truck engineers will be that helpful when it comes to engineering a boat. And the guys, that volunteerd work to create Eevee might not have had the knowledge and motivation it’d take to solve some of the issues we have with cycles. Also regarding your mentioned issues:
1st: Glass is really complicated. And I don’t know a single engine, where glass and caustics aren’t more difficult to produce. And only few simulate chromatic aborations and similar effects.
There are some engines, like Luxrender, that will produce those super realistic prism effects. But you sacrifice so much performance to gain a banefit, that hardly anyone will ever notice in your scenes … and if you really need simulated light, you can always use those kind of specialized engines. But cycles is more general porpuse and therefore those kind of effects are not deemed critical enough to sacrifice the development and performance costs.
2nd: The thing is … when you do something within a shader, it can’t have any influence on particles. Because all the modifiers and particle systems are first being computed and the shaders work with whatever geometry the modifier stack has produced. You can’t make a shader have influence on a particle system because now, you’ve got yourself a loop in your pipeline. If you want a shader to influence a modifier, you will need to bake it as a texture and use it in your modifier stack. This however is easily done with displacement.
I don’t know, what the benefit of this wouldt be to be honest with you. What’s the downside of letting each core deal with a diffrent tile?
