MRE - Multipass Render Engine
| Author: | dottore |
| Date: | 28 Jan, 2012 |
| Category: | misc |
| Credits: | dottore, vux, m4d and unc |
Download
64bit
Modularized and sperimental Point Shadows
Description
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.
Comments
Comments are no longer accepted.Please create a new topic in the vvvv beta forum to discuss this contribution.
SBAAAAAAAAAAAAM
wow.
thats some professional contribution. amazing output and well documented.
thanks for keeping me up all night.
lovely!
FXAA_layerOut.fx is missing so module FXAA_layerOut.v4p is red in "MRE - Multipass Render Engine 1.0.v4p"
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)
@u7angel: from here it looks like you have to tweak shadow bias a bit. ;)
@fibo: the fxaa module doesn't have a proper fxaa effect, it uses the one in the addonpack. make sure you have it there.
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
wonderful!
amazing job/contrib!
uber nice
grandissimo =)
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.
@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).
i've actually wondered for quite some time if this is just some flaw in vvvv or the default dx9 primitive behaviour..
fixed with cinema4D
thanks again for this amazing contribution
NICE and thx again for well documentation
thx guys running perfectly on beta 26
look at the size of that patch !!
work with beta26 but has problems (red nodes) with beta27... but really great contribution!!! Thank you guys!
great thank you so much
BIG UPS
really great work! thank you dottore!
im feeling the force!
thanks :D
@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...
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!
@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?
@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":
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...
wow, very beautiful!
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!
@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...
Thanks Dottore - I'll try with a clean beta27+addons Then 3 coffees and HLSL docs... :)
@gregsn somehow missed it, thx for pointing.
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?
@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
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 ? ...
Written in the doc (Front pass section) : Transparency is not allowed :)
If need more explanations feel free.
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 .
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
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:
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:
Hope that helps :)
@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
@VUX Thanks for reply I'll work on it and post results ASAP !
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.
lovvvvely!
Wow! This is so amazing! THX!