» MRE - Multipass Render Engine
This site relies heavily on Javascript. You should enable it if you want the full experience. Learn more.

MRE - Multipass Render Engine

misc
Credits: dottore, vux, m4d and unc

about

Hello evvvverybody! It’s dottore here,I’m back after some months of silence.
I’m happy to introduce you to this Multipass Render Engine, which is the result of the collaboration between me, m4d, vux and unc.

In the folder you can find a small pdf introduction to the engine.

NOTE:
MRE NEEDS ADDONPACK IN ORDER TO WORK CORRECTLY.
YOU CAN DOWNLOAD IT IN THE DOWNLOADS SECTION OF THIS SITE.

download

MRE - Multipass Render Engine 1.0.zip
29.01.12 [00:48 UTC] by dottore | 2908 downloads
Show 1 older revisions

Older Revisions

MRE - Multipass Render Engine 1.1.zip
06.02.12 [03:55 UTC] by dottore | 2197 downloads
Modularized and sperimental Point Shadows

Noir 29/01/2012 - 03:42

SBAAAAAAAAAAAAM

everyoneishappy 29/01/2012 - 03:54

wow.

u7angel 29/01/2012 - 04:17

thats some professional contribution. amazing output and well documented.

guest 29/01/2012 - 06:54

thanks for keeping me up all night.

lasal 29/01/2012 - 16:55

lovely!

fibo 29/01/2012 - 19:47

FXAA_layerOut.fx is missing so module FXAA_layerOut.v4p is red in "MRE - Multipass Render Engine 1.0.v4p"

u7angel 29/01/2012 - 19:58
polygon VSM problem

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)

m4d 29/01/2012 - 20:38

@u7angel: from here it looks like you have to tweak shadow bias a bit. ;)

dottore 29/01/2012 - 21:06

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

u7angel 29/01/2012 - 21:42

i have to correct myself, Wrap0 = U; doesnt do anything. texture mapping on spheres are broken. any idea why ?

i tried globalstate + address and set Cycle U to 1 but this breaks the shadow, but fixes the texture.

the picture is pretty much the demo patch, just floor with a sphere instead of a grid

katzenfresser 30/01/2012 - 12:29

wonderful!

Desaxismundi 30/01/2012 - 13:16

amazing job/contrib!

robe 30/01/2012 - 13:37

uber nice

Giovanni Ghisleni 30/01/2012 - 14:29

grandissimo =)

dottore 30/01/2012 - 15:31

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.

u7angel 30/01/2012 - 16:10

@dottore. yeah i know the cause and referring to the forum its a known problem. the usual fix was adding Wrap0 = U; to the shader. which in case of your shader doesnt work. i'll try to make a sphere in cinema4D.

maybe this goes to the devs to fix the UV coordinates of sphere(ex9 geometry).

m4d 30/01/2012 - 16:59
u7angel said
maybe this goes to the devs to fix the UV coordinates of sphere(ex9 geometry).

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

u7angel 30/01/2012 - 17:17

fixed with cinema4D

thanks again for this amazing contribution

CeeYaa 30/01/2012 - 18:05

NICE and thx again for well documentation

urbandrone 30/01/2012 - 18:44

thx guys running perfectly on beta 26

manuel 30/01/2012 - 23:57

look at the size of that patch !!

dagi 31/01/2012 - 17:33

work with beta26 but has problems (red nodes) with beta27... but really great contribution!!! Thank you guys!

hrovac 31/01/2012 - 17:58

great thank you so much

Lightmare 02/02/2012 - 00:03

BIG UPS

gregsn 02/02/2012 - 04:22

really great work! thank you dottore!

tekcor 02/02/2012 - 17:24

im feeling the force!

thanks :D

gregsn 02/02/2012 - 19:40

@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...

sapo 02/02/2012 - 20:08

thumbs up! first thing i tried was to make it as a module so i can just plug objects colors transorms textures to it with some controls on the light etc, that way it would act as a single shader node! still a treath as is! thanks guys!

alg 02/02/2012 - 22:34

@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?

gregsn 02/02/2012 - 23:27

@alg: we are indeed bad in documenting all features. and sometimes i hear of a keyboard shortcut or some other feature i never heard of. however this typically shouldn't be the case and we try hard to at least put everything you should know about into our detailed Change-log. i can imagine that this is a hard read. vvvvery. but it is worth reading. you should develop some workflow how to get through that document. print it and mark interesting ideas or copy and paste it into a textfile, read some lines each day, delete them and come back.

so look under beta26 "changed nodes":

  • s/r nodes: more than one sender can send values on a certain channel. receivers connect to the nearest in terms of the patch hierarchy

whenever something is too cryptic start a thread. we will be happy to get into the details.

ah, and while reading that bastard:
whenever you discover a feature or a way of working that isn't documented but works well for you tell us on the forum or suggest a wiki page. the forum isn't a bug forum only ;)

@dottore: sorry for occupying your thread...

ft 03/02/2012 - 16:20

wow, very beautiful!

sur 05/02/2012 - 02:20

this is great!
working well with beta27, except DOF (no red nodes, just all blurry/nothing in focus)
do you think you can put up an expanded tutorial
on porting material shaders to work with MRE and shadows?
i read the pdf but still a little advanced for me....

thnx!

dottore 05/02/2012 - 15:02

@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...

sur 06/02/2012 - 01:27

Thanks Dottore - I'll try with a clean beta27+addons
Then 3 coffees and HLSL docs... :)

alg 06/02/2012 - 21:59

@gregsn somehow missed it, thx for pointing.

mrboni 07/02/2012 - 19:26

Can someone explain the usage of the dofEqWeapon XY and dofEqFar XYZ in the DOF module?

Can I use them to set the focal plane to a particular distance, and adjust the range of DOF?

gregsn 07/02/2012 - 22:08

@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

I_am_from_Chile 08/02/2012 - 16:30

Hi , Playing around with it ifound dificult to work with alpha channeled textures , Phong_MRT_VSM is the only way to get FX's in to it ??? blend modes and render states are completly ignored in it ? ...

vux 08/02/2012 - 21:42

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

If need more explanations feel free.

I_am_from_Chile 09/02/2012 - 11:45

Ha ha , Yes I should have read the Docs. first ,very weel done guy's thanks!

Just one more question; Before I jump in something too complicated ,is still posible to sort out a alpha texture before the front pass ,another shader to do the necesary calculations would be possible right ? or I should forget about alpha channels alltoghether....?
Thanks once again .

vux 09/02/2012 - 12:49

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 :)

dottore 09/02/2012 - 16:11

@gregsn:
The main requirement of this approach is that no geometry is lighted by multiple lights. Rooms are really separated (at lighting level at least; they could anyway share the same space).
So, if we happy with this, we definitively can organize the modules into lighting spaces.
LightingSpace module will contain:

  • object modules
  • light module (unified with vsm module)

One consideration:
The environment module must not be placed into each Room(lightingSpace) because it's not light dependent and is also unique (in your version there are 2 overlapping backgrounds, you can see if zoom out with the camera).
It Should be a Environment moudule near the lightingspace modules, in the root patch.

Agree on light patch cleanup (separation between position menagement and the rest...)

...future improvements in multi-lights management will require a completely different approach, called deferred shading http://en.wikipedia.org/wiki/Deferred_shading

I_am_from_Chile 09/02/2012 - 20:17

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

ksp 20/02/2012 - 22:53

i had problems getting this to work. it was fixed by changing the 3 DX9Texture formats to "A16B15G15R16F"

(..this sorted everything except the Glare, which makes the render flash on/off/on/off/etc.)

very nice ....still need to buy a new computer to run it properly though.

Martin Zrcek 05/05/2012 - 11:28

lovvvvely!

roman_g 19/11/2014 - 16:09

Wow! This is so amazing! THX!

anonymous user login

Shoutbox

~4d ago

~7d ago

joreg: The Winter Season of vvvv workshops is now over but all recordings are still available for purchase: https://thenodeinstitute.org/ws23-vvvv-intermediates/

~14d ago

schlonzo: Love the new drag and drop functionality for links in latest previews!

~22d ago

joreg: Workshop on 29 02: Create Sequencers and Precise Clock Based Tools. Signup here: https://thenodeinstitute.org/courses/ws23-vvvv-08-create-sequencers-and-precise-clock-based-tools-in-vvvv-gamma/

~29d ago

joreg: Workshop on 22 02: Unlocking Shader Artistry: A Journey through ‘The Book of Shaders’ with FUSE. Signup here: https://thenodeinstitute.org/courses/ws23-vvvv-12-book-of-shaders/

~1mth ago

joreg: Talk and Workshop on February 15 & 16 in Frankfurt: https://visualprogramming.net/blog/vvvv-at-node-code-frankfurt/

~1mth ago

woei: @Joanie_AntiVJ: think so, looks doable

~1mth ago

xd_nitro: Anyone remember who increased projector brightness by removing some components that product the color?

~1mth ago

Joanie_AntiVJ: This looks super interesting (vectors over network) would anyone here know how to implement this in beta? https://github.com/madmappersoftware/Ponk