thats some professional contribution. amazing output and well documented.

lovely!

textures on spheres using phongpoint_MRT_VSM.fx are not mapped correctly. Wrap0 = U; usually fixes the problem. in this case, textures look good but the shadowmap seems to produce errors with this setting. some polygons on the sphere get dark depending on the rotation of the sphere. (in top area of the image)

@fibo: the fxaa module doesn't have a proper fxaa effect, it uses the one in the addonpack. make sure you have it there.

wonderful!

uber nice

tnx to everyone! happy that you enjoy it :)
@u7angel: your probelm is not related to the engine's shaders, it's about UV texture coordinates generated by Sphere (EX.9 Geometry) node.
the sphere mesh should be like a grid deformed, so where it closes there are overlapping points with different U texture coords (0 and 1).
...Like the Cylinder node works.

i've actually wondered for quite some time if this is just some flaw in vvvv or the default dx9 primitive behaviour..

NICE and thx again for well documentation

look at the size of that patch !!

great thank you so much

really great work! thank you dottore!

@dottore/all: have you ever tried to reduce the amount of necessary links?

building up the scene looks like quite some amount of linking work. (even if you know of the CTRL-SHIFT-D and CTRL_SHIFT-V features that do most of the linking for you). or at least readability and editability drop by each primitive added to the scene.

i wonder if we could use those old s and r nodes to do some kind of automatic linking. well those old nodes have a pretty new feature that probably nobody ever used / trusted upon: automatic connecting to the nearest sender, where nearest needs to be understood in terms of the patch hierarchy.

imagine a patch system that has one patch scene that includes 2 patches room1 & room2. now we could place some modules in room1 (e.g. a light source module sending all necessary light source infos). now put some rendering modules that consume (receive) those light source infos into the same room. they will connect to the light source placed in room1. if you now use the same structure in room2 they shouldn't interfere.

the "patch distance" to the other room is always bigger (think of a relative path that needs an additional ".." - to get into the scene patch - and an additional roomX to get into the other room).

if you miss to place a light source into room2 it will however just connect to the light source in room1.

However it might also be a nice idea to just drop an additional light source into the parent patch "scene". now each subpatch that has no own light source will just use the parent light source.

so i think if used right, we could get some magic plug & play from that. one could also think of many other infos (like global transform??) that could be received via that system.

i'm not totally aware of all pros & cons, but the abstract idea is that sometimes hardwiring is better and of course more flexible, but sometimes autowiring can be flexible enough and of course offers faster patching.

i guess that in cases where now typically only one data source (e.g. light) exists autoconnecting is a candidate worth testing.

so: i never used that feature myself, but i would give it a try. in earlier days i would have said: never use s and r nodes if you want to keep modularity. now with those new features i would want to argue: you get another kind of modularity which could be quite nice...

@gregsn very interesting concept, i never know about this functionality. I think nobody is using this feature is just because it's not documented. Or i missed something?

wow, very beautiful!

@all: thanks a lot, we really are pleased by your responce.

@gregsn: i know there're quite a lot of connections and patch is kind of messy already with simple scene.
That's why i'm working on a new version with more modules and s/r nodes.
Hope to find a more confortable setting.
thanks again for your appreciation :)

@sur: mmm...strange your DOF doesn't work... did you tried with a clean beta27 with addonpack? what's your graphic card?
If you find the pdf cryptical, you could search for some tutorial on basic hlsl shaders, to better understand their structure. there's plenty of them, just google it.
As i said in the pdf, the only difference between common shaders and MRE ones is the MultiRenderTarget (MRT) part. search also for it ;)
let me know if you want to know more specific things...

ciao

NOTE FOR EVERYONE:
MRE NEEDS ADDONPACK IN ORDER TO WORK CORRECTLY IN EACH PART
let me add this to the contrib description...

@gregsn somehow missed it, thx for pointing.

@dottore: played around to just make a proof of concept with two light sources and two "rooms". just to be sure if it all makes sense.

i think for some future version it would be nice to have a separation between the light subpatch that controls the specific light and a light module, that has input pins light "Light Position" (...), does some calculations and then sends on the right channels. I also sketched how to separate between subpatches that render something and do that by using a module that does the magic s/r business.

That way users dont have to know of the channels themselves. But they do have to know how modules connect to each other. Got that wrong in my first attempts... it seems to be important that the VSM part is placed near each light, since it is light specific. So if you have a room with an own light you also need that VSM module at that spot. Maybe those two could be combined into one?

Well. Just wanted to show you what i tried... Thanks again!! Wonderful stuff! Ah and playing with the colors of boxes (extreme oversaturation or extreme lightness) is really cool. Its like adding a light source. So nice.

http://www.datafilehost.com/download-9fbf9852.html

Written in the doc (Front pass section) : Transparency is not allowed :)

If need more explanations feel free.

It depends what you want to do really, two cases (simple and less simple):

1/You want to use several textures for a solid object and blend them

• Option 1 : use textureFX blend (or do your own blend) on the textures in a previous pass and send the resulting texture as input to yout front pass shader.
• Option 2 : Copy the front shader and add extra texture pins, then blend inside (you can still use the alpha channel to mix colors like lerp(coltex1.rgb,coltex2.rgb,coltex2.a), alpha will still be ignored at the end)

2/You want to render alpha objects as well as solid objects (like an alpha sphere on top of a solid scene

That's more complicated, since alpha objects will also mess up some effects if you use them in the front pass, so normally they should be drawn on top of the scene after the depth of field).
So process should be like:

• Render solid objects (like now)
• SSAO->DOF
• Render transparent objects on top
• Tonemap and the rest.

Please note to render transparent objects you will also need to use the position texture to implement your own depth test (since if a transparent object if behind a solid object you should not see it).
So transparent object pixel should be drawn like this:

• Get transparent depth (view space)
• If transparent depth >= position texture depth -> do not blend pixel
• If transparent depth < position texture depth -> mix you transparent object color with the one from the scene.

Hope that helps :)

@VUX Thanks for reply I'll work on it and post results ASAP !

lovvvvely!