This site relies heavily on Javascript. You should enable it if you want the full experience. Learn more.

dynamiclight-forward-Renderer

I am from Disney BRDF implemented in forward rendering with naive multiple pointlights and a sun light, SSS and Clearcoat. X is roughness Y is metallic. Anisotropy direction can be rotated and texture mapped (spindled metal look). Deferred implementation with culled multiple lights is coming ;)

microdee, Monday, May 22nd 2017 Digg | Tweet | Delicious 20 comments

tonfilm 22/05/2017 - 17:34

+1 for enabling anti-aliasing ;) looks ace!

m4d 22/05/2017 - 17:40

yum

teem 22/05/2017 - 19:10

that is soo dope.

ggml 24/05/2017 - 17:51

will it be user friendly this time round ?

microdee 24/05/2017 - 20:14

well yes. Right now it's just an fx file similar to superphong. But if you want user friendly stuff while maintaining performance and advanced features go to a proper game engine, or notch :P

ggml 24/05/2017 - 23:27

i mean patcher-friendly (compared to emeshe)
would be a big plus i feel

microdee 26/05/2017 - 14:34

now this is available in mp.dx, search for DisneyForwardSimpleNaive.fx and look at dynamiclights-forward.v4p in girlpower. Don't forget to overwrite everything with vpm as new features may rely on updates in dependencies.

u7angel 27/05/2017 - 17:43

would it be thinkable to make contributions not dependent from your vast collection of packs ? some of us tend to have as little as possible in the packs folder.

cheers !

microdee 28/05/2017 - 08:23

I'm afraid it isn't going to happen. I have plans to create proper and thorough html documentation about my entire ecosystem so people can have clearer view about what's in there because the entire stuff is quite huge ;) that's why it is separated already into smaller packs which might have different dependencies. mp.essentials and mp.dx would be ridiculously large amount of single nodes if I would break each into its own pack. and those nodes are usually highly codependent so there's not too much point separating it

guest 28/05/2017 - 13:55

Just checked out the mp.dx with vvvv_50beta35.5_x64.
Installed mp.dx with its dependencies via vpm.
Installed mp.voocam separetly, since its not among the dependencies but
also requiered by some mp.dx patches (at least in girlpower)
Also tried installing vaudio, but it fails.

What i see is, barely one of the girlpower examples is working out of the box :(
Mainly there is assets missing but sometimes also nodes..

dynamiclight-forward.v4p - mising testobject.obj

ForcedDX9ToDX11.v4p - missing Treemap pack

IBLPBR.v4p - missing tonemapping (pointing to emesehe pack)

ShaderFactory.v4p - missing fxh files (pointing to /users/mcro.de/appdata/local/..goes one..)

SkeletalMesh.v4p - missing c:\assets\RobotAlator\robotalator.fbx

SkeletalSingleMesh.v4p - missing ..\packs\mups\assets\runningwolf-lores.dae and message nodes red, enums broken

VideoViewer.v4p - PlayerDX11texture.dll missing, pointing to \packs\miscs\nodes\plugins\... , vaudio nodes missing since broken vpm install

microdee 28/05/2017 - 18:39

yeah I need to write a note that girlpower is very sloppy, doesn't cover entire pack and they are rather test patches yet. for missing assets right now use your own stuff. I have to test vaudio. a long time ago messages had a breaking change renaming Create (Message.Keep) to ConfigKeep. That might have caused the problem I need to fix that, videoviewer is just a patch for me to scrub and framestep videos there's a badly named DX9 version.
As I said earlier I'm planning to make a big epic docs overhaul with help patches and HTML pages but that will take months or a year probably.

u7angel 29/05/2017 - 12:02

bringing back the idea of standalone contributions. i have the same experience like guest. it's a big hassle to get your things working sometimes. i tried skeleton as well and it took me 2 days to find the right asset and fix your dependencies.

while it is very very nice of you to share all your work, it takes unnecessary work to get little bits and pieces working. due to the spiderweb of dependencies, which aren't 100% working.

waiting a year for fixes renders your contributions kinda pointless.

microdee 29/05/2017 - 12:53

@u7angel: most of my stuff is under MIT license: you do whatever you want with it as long as you can figure it out how to make it work. I can't guarantee though that my stuff won't break due to edge cases with third-party dependencies or me making a change somewhere and forgeting about it's possible side effects due to a super unrealistic deadline during a project. Using VPM on empty new vvvv should take care of dependencies. I'm using that much dependencies because I don't want to reinvent the wheel. If a problem is solved in an other pack I don't want to reimplement it or hard copy it into my own.
On the other hand making that thorough documentation will take approx 1 year. Not actual fixes. Fixes and improvements are organically developed and pushed to my github repos when I have time and need for them. They are all open source packs as well so whenever you find an error like that and you are able to fix it feel free to fork and send a pull request about it. Also making the docs is a long, tedious and repetitive job while actually the yield of my packs doesn't improve. You can see why I don't have too much motivation on that part while I also have to make my living developing for different projects.

joreg 29/05/2017 - 14:39

i totally get both sides of the argument and would be interested in finding out how instead of being stuck here, what would be needed to improve the status quo.
so we have:

microdee who can hardly be blamed for releasing all his amazing stuff as opensource
users who can hardly use all this amazing stuff as is

i think this is a standard-situation that many opensource-projects face where we then realize that opensource is not a sole savior but a necessary first step. but then there are more steps needed to make those contributions accessible for end-users and i'm afraid i think those additional steps can not realistically be asked from the same original coders but would ideally be handled by a community that builds around the coders, as we see happen in successful opensource projects. so instead of having opensource-contributor -> enduser there need to be more positions added to that equation, like: maintainers, documenters, testers,...

so i imagine we'd need to find someone tech-savvy among our community who is interested in microdees contributions and would be willing to invest some time to take over the role of maintaining a subset for end-users. i guess it would need some research to investigate which parts would be the most interesting for users, which of those could be extracted and work as standalone contributions. i'd suggest to start with smaller independent parts to get a proof of concept...

anyway..those just quick thoughts and obviously not a solution but posing even more potential problems..NODE17 should offer good moments to talk about such things and see if we find people interested to work on improving that situation.

microdee 29/05/2017 - 15:04

it's amazing what conversation a shader teaser can spawn :D

sunep 29/05/2017 - 17:54

thinking out loud here:

how about having purpose compiled vvvv installations. so you can have a zipped vvvv where the image pack has already been installed or a minimal versions with relevant parts of the md eco system etc.

this way it would be easier to have an installation where everything works.

or is that problematic in relation to licenses?

microdee 29/05/2017 - 19:45

well nothing stops you making vpack files doing exactly that ;)

sunep 29/05/2017 - 20:50

Ok, then I need to figure out how to make vpack files :)

microdee 29/05/2017 - 22:53

https://github.com/vvvvpm/vpm/blob/master/README.md

tonfilm 30/05/2017 - 16:32

this reminds me of an idea i started a while ago but never had the time to finish:

https://discourse.vvvv.org/t/community-coding-the-new-vvvv-standard-shader/15188

dynamiclight-forward-Renderer

Shoutbox