Up to now I’ve been using vvvv for 2D work, or simple 3D work where the objects self-illuminate (texture maps). But I had an idea needing multiple moving light sources over an entire scene of objects, and I can’t seem to find any obvious way to do this.
Is there some tutorial on lighting 3D objects in vvvv? My apologies if I’m being a clueless newbie, but I have searched using the obvious terms and looked through the documentation, but the concept of “lighting” just doesn’t seem to exist in the same ways it does in other 3D and rendering programs.
The only thing I have been able to find examples of involves dealing with each object in the scene with each light, and even then it’s a precious few types and numbers of lights (and materials), with anything else requiring writing a custom shader. vvvv seems too elegant in every other respect for it to be this clumsy, so I must be missing something!
i am afraid to say that it is really this clumsy or how we’d like to call it flexible. lighting is a shader operation. shaders in vvvv are handled in effects which take meshes and draw them applying their shaders.
so if you want multiple independent meshes to be influenced by the same light you need to draw them using the same effect applying the same parameters. alternatively you’d try to put as many meshes into one (using subsets) so that you can limit the number of mesh+effect nodes used in your patch.
now vvvv comes with some effects that do lighting like the PhongDirectional (EX9.Effect) and PhongPoint (EX9.Effect) but their parameters are not too intuitive and you cannot spread the number of lights. while i didn’t find a good way to realize a dynamic lightcount in an effect (see my attempt for a multi-point-light phong effect with a static count (editable via a constant in the effect)) writing shadersnippets for differently parametrized lightsources is still an open task. i guess someone willing to work on such an include file could make some new friends around here. and it shouldn’t be too hard.
so the idea would be having a LightingUtils.fxh file that offers several functions that can be combined with custom shaders (-> here comes the flexibility). and while at it of course we could need some more default shading/lighting nodes like the afformentioned that make use of the LightingUtils for easier prototyping. anybody?
So another question: since light is additive, can shaders for each light be applied sequentially, or do all lights have to be in one shader? In other words, can I apply a single-light shader three times each with a different light, or do I have to have a 3-light shader and do it once?
@joreg: if you could sneak a needed feature for deferred lighting into the next alpha, i’d port a technique… ;)
(tabula rasa/stalker like tech which is explained in gpu gems afaik)
@media: in theorie you could compute one light per pass and then add up the resulting passes but thats not the typical way. the much more performant way is having all lights in one shader.
sorry, was in sort of a hurry yesterday. so i’ll elaborate a bit…
coming from non-realtime 3d i just started with hlsl when i tried vvvv like 1,5 years ago and always looked for ways to improve my shading. Deferred Rendering/Shading is basically a technique which moves the light evaluation of a 3d scene to a 2d space by calculating the actual lighting from buffers of a pre-pass shader which output scene depth, normals and other attributes needed for the light calculation. (for a better understanding of deferred shading maybe also look at this nice gamedev journal post.)
i’ve heard about deferred rendering/shading first when i ported ArKano22’s SSAO technique. the patch already has the basic deferred layout implemented, but opposed to full deferred rendering it does light evaluation with a simple cubemap lookup like the original example.
now to get fast deferred light evaluation (i’m talking hundreds of pointlights at 60fps) going in vvvv one would need to add some simple shaders for a lighting pass (like the ones from catalin zimas excellent (though xna) deferred tutorial) and a way of to optimize pixel overdraw in the light calculation by e.g. using the stencil buffer to reject unlit pixels or rebind the rendertarget of the pre-pass as output rendertarget for the light calculation. (and thereby making use of early-z rejection)
so what would be really needed is the way to optimize the drawcall in vvvv by exposing one of the mentioned techniques. (maybe they are already exposed and i’m just to stupid to apply them??)
here are some further links to good papers/articles about deferred rendering/shading:
edit: i previously spoke to our belovvvved devvvvs about this but unfortunately never came around to sum my thoughts up and deliver some good links. sorry guys, just had too much urgent stuff this year)
-also this is a quite nice differentiation of deferred rendering/lighting (although the author is quite biased ;D)
sorry for shamelessly bumping this up, but this is something i’ve been trying to achieve for quite a long time, so i’d really appreciate if someone could comment… :)
here is an excellent sample by andrew lauritzen which enables one to check out the performance of standard deferred methods. (full deferred rendering with various culling modes, light prepass and tiled deferred shading) the sample only runs under dx11, but all techniques except the computeshader based tiled one are quite common in dx9 games and therefore should be doable. also the non culled modes of this demo illustrates quite good why some lightdraw optimization would be needed for a vvvv adaption.
