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 ;)
+1 for enabling anti-aliasing ;) looks ace!
that is soo dope.
will it be user friendly this time round ?
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
i mean patcher-friendly (compared to emeshe)
would be a big plus i feel
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.
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.
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
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
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.
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.
@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.
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:
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.
it's amazing what conversation a shader teaser can spawn :D
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?
well nothing stops you making vpack files doing exactly that ;)
Ok, then I need to figure out how to make vpack files :)
this reminds me of an idea i started a while ago but never had the time to finish:
anonymous user login