What you are seeing is that some leaves are rendered before the leaves behind them and they are blocking the zbuffer. By moving the sky control you’ve only shifted the problem… instead of rendering the sky around the edge of the leaves you are rendering ‘whatever was in the framebuffer’… maybe black.
If you desire that your leaves have black borders then maybe you can fork the shader to add black borders.
Ye, I understand it. But truly speaking, I can’t understand the way you’re advice to solve it. I just found a solution, that visually works for me good without any (very noticable) visual artifacts. And I am satisfied with it. If there was “right” solution I would use it. But I don’t know about it.
…until you have something in your opaque bucket that is bright and behind the tree.
And you are saying that black borders is the only solution?
My guess was that that was what you were seeing when you thought it looked ok… because the problem will still exist but if the sky is not rendered then there is a good chance that the view you showed would be showing black borders instead of blue.
…in which case you could modify the shader to mix black into the leaf color based on transparency when not discarded.
Edit: else tweak the discard threshold until the borders are small enough that you don’t mind.
And yes, because it’s a geometry sorting issue… unless you sort all of the leaves every time the camera moves then your options are limited. (And that would be expensive.)
First image shows how it’s looks like now. Maybe there is black borders but eyes (at least my) don’t notice them. But it’s true that it become visible if bright objects located behind.
Could you give any tip how to do it?
Spherical Soft Lit PBR particles, SSLPBRP :
It’s soft particles, that have sphered normals, that are being PRB lit by the environment and are light reactive (the bright green bit is a bright green point light on a drone in the smoke/fog.
What are your system specs?
This might need tweaking I’ve only just started with shaders. Make a copy of the Lighting.j3md and put in MatDefs folder, make a copy of Lighting.frag and put in shaders. Edit the Lighting.j3md and change the bit under
Technqiue {
LightMode Multipass
for the fragment shader to
FragmentShader GLSL100: Shaders/Lighting.frag
So it uses your fragment shader. Vert can be left alone.
Then edit the Lighting.frag you put in the Shaders folder. At the very bottom where it is written
gl_FragColor.rgb = ...
Change this to
gl_FragColor.rgb = AmbientSum * diffuseColor.rgb +
DiffuseSum.rgb * diffuseColor.rgb * vec3(light.x) +
SpecularSum2.rgb * specularColor.rgb * vec3(light.y) -
(1.0-alpha) * vec3(1,1,1);
The bottom bit gives the black. Then the final line, replace
gl_FragColor.a = alpha;
with
gl_FragColor.a = step(0.01,alpha);
I don’t know exactly what we’re going for here so post a screenshot if it’s messed up (probably) and we can change it easy enough.
that’s doesn’t happen to chuck Norris when he is using windows.
i7 930, 6gb RAM, GTX470 (its an old system)
FPS is capped at 30 for video recordings, scene runs at ~ 100fps normally
oh ok, that makes sense
Are you using the depth buffer for the soft particles?
yes. I’ve adapted the SoftParticles that are part of the engine… It’s the first time I’ve opened the soft particle shader and it is nice and simple and uncluttered, it would make for a good intermediate starting point for anyone screwing around learning sharers.
Wait there is a softparticles shader already?? I was thinking I would have to make one based on this thing I saw on the Wolfire blog, where they subtracted depth to get the softness.
EDIT: Well I’m glad you posted this and I found out! Thanks! I was of the understanding I would need to create a pre-render viewport and set it to render to a texture for the depth map. Does this shader recieve the depth map automatically or will I have to go down this route?
Awesome, thanks
I’ve been updating my game to 3.1 beta 1 so I can finally use lemur and simetheral.
It did immediately break a bunch of things but some serial fixes later it was up and running, albeit with half broken gui. The DLSR was complaining about a nonexistent lightdir parameter though. So I thought, time to grab the new updated Lighting.j3md.
All work today went into updating my lighting based shaders to the new version so I could even start the dlsr without crashing. Finally got it done:
Yeeah something went wrong there it seems.
Looks like Bilinear is best but still has these odd streaks where geometries join together…
Does anyone know anything about this at all?
Does the DLSR work well for anybody in 3.1?
“Tractor beam…” - breathe - “on a corvette…” - breathe - “impressive!”
