new render core
Community Forums/Showcase/new render core
| ||
| So, I've stopped work in the 3d editor to finish the renderer. Previously there was an issue with moire shadows. I've been tinkering around and here is the result:  Main features are Dirty Grain look, dynamic shadows, ambient occlusion (SSAO) and colour bleed. More work to be done on full integration with everything else, but I'm beginning to be happy with the results. The four deferred images are: Shadows, RGB, Normals, FX |
| ||
| Hey Adam, The grainy effect looks good, with the shadows too. Are the vertex colours indicative of the the vertex normals? Which deferred image refers to which phase of rendering - i can guess, but if I'm right then I think there might be something wrong somewhere. |
| ||
| the deferred pics on the left are: top: shadow buffer middle top: diffuse middle bottom: screen normals bottom: fx The normals are created within the shader and are screen based not model based - so look a bit weird. so when you move the view, the normals all change Here's another shot with similar models, different colours though so I can check how the colour bleed is working:  I'm also sacrificing accuracy for speed. as this is all realtime. |
| ||
| Nice, wish I understood math :) |
| ||
| Looks great. wish I understood math :) You and me, both. |
| ||
| The normals are created within the shader I feel like this is a stupid question, but how does that work? Don't normals require access to information from areas potentially quite far from the fragment position? Hence normally being precomputed vertex properties? Engine looks fantastic, either way. |
| ||
| That grained look reminds me on Cycles-Rendering with Blender. Can have good results but is not useable for every game style ... casuals tend to want "polished" look. Did you check how "grained" and "text without background" fit together? Maybe it makes readability a bit worse. bye Ron |
| ||
| @ Yasha I feel like this is a stupid question, but how does that work? Originally I created the normals myself per model and fed them into the shader (which is the usual way). But there is a big overhead doing it (I found) on the CPU, so I looked at various ways for the GPU to do it. not quite as simple. Then I stumbled upon this little GLSL shader beastie: Vertex code: //get the actual vertx depth vertexDepth = gl_ModelViewProjectionMatrix * gl_Vertex; Fragment code: //get the automatic vertex normal vec3 X = dFdx(vertexDepth.xyz); vec3 Y = dFdy(vertexDepth.xyz); vec3 N = normalize(cross(X, Y)); vertexNormal = vec4(N.xyz, 1); It gives you screen normals. lighting can be a bugger though @ EdzUP & GaryV Nice, wish I understood math :) Would you believe I have a problem with numbers and math? But... If I can draw it, I can come up with something to solve the problem. My brain doesn't process equations so I have notebooks full of 3d axis, drawings of models, how to solve angles, etc. It's one reason there is a dirt look. I know how things should work - couldn't get them to work - and came up with something different. so nothing is quite as it should be... @ Derron I'm taking each step one at a time. So HUD/text etc is further down the road. The next step (once i'm really happy with the renderer) is to take the current renderer:  which has full material support, bump mapping, procedural stuff and add the deferred one |
| ||
| Wow... had no idea about the dFdx and dFdy functions - didn't realise it was at all possible for a fragment to use any information from other fragments on the same pass (I would have tried to do that the dumb way in two passes or something). Guess that explains the 2x2 basic block thing. That's a pretty fundamental piece of GPU wisdom I learned today! Thanks! |
| ||
| I did not want to sound as if I impatiently await your source code ... I just asked myself wether the grain could disturb text readability in certain scenarios (eg when you want "flat/polished" object surfaces but get that grain for free). bye Ron |
| ||
| Hmmmm. an interesting thought. I had to go into photoshop and do a quick test for you. In essence any "thin' text would get disturbed. But if that was the case, you should really be using a different font or text method. I checked with solid white and alpha text and it was fine. A good way to make sure this wouldn't be too much of an issue would be to use a faded background of black, or outline, or shadow to the text. Here is the above table with a (photoshopped) dirt render:  Hopefully the real thing will be similar? |
| ||
| think the above screen shot already shows that your axis-arrows might be a bit too faded/alphaed (blue is really hard to distinguish ... maybe it already needs that glow/shadow/outline you suggested for text). That outline effects for text are natural if the background varies - so a dark outline is nearly not visible if the bg is already dark while on bright background it allows to distinguish a bright text from the bg. Somehow I like that table... looks "rough" and "used" ... something on which you can catch a splinter. Tiles of the floor look kind of "scaled to much" - of course there were big plates, but the gap between is about 2cm .. But hmm ... is this even a table and not some kind of chair/stool? ... because the space between the planks is also a bit bigger than usual for a table... in that case ignore my critics on the floor plate. bye Ron |
| ||
| LOL No problem about the critique of the floor and table. it was a quick photoshop knockup - hence the faded axis arrow. (But you're correct about the blue not being easy to see) Also the models are just me messing around with settings, materials to see the result. definitely not any final thing for getting critique about ;) |
| ||
Here is the new tweaked render core with a proper table (not using the new material rendering) with just vertex colours. I've still got problems with moire in the shadows, but it is much less now. The shadows and AO are also being modulated depending on depth so closer objects have a brighter look. The base plane was changed from grey to a near white, which accounts for the very stark base plane. |
| ||
| if this is a proper table: middle panel is of lower height than the outer ones. There is no 90° rotated panel holding the wood :D. I like the brighter wood. The darker one fits better for "taverns" with less light. For me it now looks like an inbetween shot during cycles renders (blender cycles). It has something attracting but personally I more like the "polished" look. ... but at the end it might sum up to something visually attractive, time will show. bye Ron |
| ||
| no need to worry about what the models actually look like - i'm just test coding the render core. but yep - there are no cross beams etc on the table So, just for you Derron (standard Rameses renderer):   and finally:  And the top planks are slightly off and angled differently for a rough look. And only 2 objects used: Plank and Leg! |
| ||
| pattern on the table-plane looks a bit "skewed" - intention or somehting "wrong" ? In the first shot - the bottom left plank side - seems to have some "repeating pattern" - issue? shot 2: pay attention not to create clipping errors (the "cross beams" poking through the top planks :D). You do not need to do a bunch of work just to satisfy someone criticising a bit here and there. May I ask what kind of light source is used - ass there seems to be some kind of "sun" (equal light strength) but then eg in shot 3 the legs on the left side seem to look brighter than on the right side - which can only happen if the light is restricted somehow (more on the left side, object taking away light on the right side). bye Ron |
| ||
| You can ask about the lighting, but in some respects it wan't do a lot of good. It's based on a single point, but is then modulated through the scene depending on the surface parameters - again these are just test renders :) |
| ||
Oops But the SSAO is now much better, no halo, and darker where it needs to be. |
| ||
| Looks way smoother (but also lost that "hard/used" look of the wood - did you change the material too?) bye Ron |
| ||
| yep, the materials are not being used, just the rendercore. So the only thing being used is the vertex colors. Much simpler to test things that way :) |
| ||
| You might look into things like "physical materials" ... so you could define how materials accept "shadows" ... or how "blurry" they make shadows. Same for reflections etc. @Table it looks kind of "displaced" ... intention or mistake? bye Ron |
| ||
| so you could define how materials accept "shadows" Definitely a good idea there about the shadows/material and one i'll look into. For now it's the shadows themselves and how I can give a better look. |
| ||
| Subdivision surfaces might also be of interest (but in contrast to your "low poly look"): http://www.blendernation.com/2014/11/12/non-blender-animation-at-pixar-math-and-movies/ Very well explained by that old man. bye Ron |
| ||
| Excellent post there. I especially liked the way everything was explained through pictures - very easy to grasp :) Thanks Derron Quick update on this: got the shadows to work the way I wanted them and also took the advice of materials with shadow properties. RenderCore now has ability to blur shadows per object and also a global shadow/light variance parameter that modulates the resulting light and shadow from very bright (bright sunlight/polar) through to normal daylight and down to darkened muted light/shadows for night/dark areas. |
| ||
Here is a quick shot of RenderCore with some lighting thrown in. Lighting is not currently supported. I'm just running tests: 5 lights with different parameters, colour, falloff etc. And a quick one showing the soft shadows (which are controllable per object)  |
   |