And I learnt in Russia they don’t change the hour like we absurdly do.
Yeah, using Maxwell for animation is like pulling teeth. Admittedly the animations made with it are gorgeous, but it’s definitely not a hobbyist tool.
Amen, silliest remnant from the past that I can think of. My favorite are the people who think it somehow actually makes the day longer/shorter. No, genius, your watch/clock/phone just says something different on it. We, as humans, did not magically change the flow of time. You just got to sleep for an hour less one night.
This seems like an odd thread to start a debate, and over a rather strange topic… but as individuals who are aware of the effects of optics as well as consumers of technology, I find it odd to throw DST out the window as nothing more than an annoyance. As someone who lives in a northern country, the benefits of offsetting my schedule by a minimal duration is hardly an inconvenience when considering the various benefits. Lesser power consumption, fewer hours of transportation in the dark, less psychological effects brought on by lack of natural day light, etc. Most clocks are synced digitally these days anyways, just sit back and keep on cruising along.
Okay, sorry about that, my apologies. Back to SSS, As you were.
So hey how about that subsurface scattering, huh?
A quick question to make sure I’m understanding things right.
For the “skin shader” that won’t be coming out for a while, it will more than likely be able to be accomplished with a node group in the mean time… why isn’t the forthcoming skin shader a skin shader node group? I understand only the basics, but even if there’s some custom math functions to be preformed, would it not be easier to create a node for that function, that can then be reused in the future(maybe in a volume shader)?
This would allow quick plug and play for the basic user, or for a quick test render, but would also allow fine grain control (or complete repurposing) for the more advanced user.
I know I for one reuse materials like there is no tomorrow, most I don’t have to tab into as I have the key values already available. I’m not sure why blender doesn’t ship with a bunch of node groups preinstalled. Would help the beginners (myself still included) a lot
Not 100% sure on this but there could be optimisations that can be made by the coder and the compiler specifically for a hard-coded skin shader which wouldn’t work with nodes generally. Or something. Basically the less general any piece of code is, the quicker it goes.
Take for instance mixing. In a hardcoded skin shader, mix data would be a couple of variables being put specifically into a mix function to get a result. In the Blender binary, from one node to another those same variables have further to travel, and they end up in a much bigger and more general structure that can mix, add, subtract, calculate difference, etc, and because it’s more general, a mix in Blender’s node system will be anywhere from slightly to much slower than something hardcoded.
The skin shader doesn’t need the flexibility of nodes because it already knows what methods to mix its variables with, so because it’s a set of fixed calculations it can bypass general cases for specific ones and save some computing time to boot, thus making skin shading quicker.
Probably.
That it does, but damn does it look good! 
And it is 100 % accurate and easy to setup, to me at least!
The skin shader doesn’t need the flexibility of nodes because it already knows what methods to mix its variables with, so because it’s a set of fixed calculations it can bypass general cases for specific ones and save some computing time to boot, thus making skin shading quicker.
I guess it’s a trade off between flexibility and speed (speed for both the developer and the end user). I worked on a large scale implementation of an off the shelf software which required customization. Through both contractual obligation and by issuing of change requests (aka pay them to) we had input in both the software they delivered and their core product. By presenting our requests in a way that benefited us and also provided things they could leverage with other clients, well that’s how we got the best results the fastest.
When we dealt straight with the business analysts, they wrote very specific requirements documents that would only suit our specific needs at that time. This was also probably the quickest way to code it. However; we would review and return with our recommendations, which would both future proof a little and provide a product that could be configured for a variety of users.
I’m always in that mindset now. If you are doing work that can be leveraged down the road, take the extra time. The people that support the development of blender are the end users (not the bosses of the end users) which is a huge advantage. I know how project management coupled with contractual project deadlines can effect the final product. At work I accepted it as the world we live in. I don’t think an open source, crowd funded program needs to be like that.
I also believe people like Brecht are not your ordinary coders. I think he mixes both requirements gathering with coding, which is a great bonus. We all appreciate the work he does, but there is no way he can think of it all. I’m at the point of rambling (just worked a night shift) but really my point is, kept it customizable. There are blender users out there that will play with it for weeks on end and find some unintended use, but also package it for new users so that the blender community can grow… wow, do we ask for a lot.
@yeobe1, I don’t have the email link handy. i think i saw the a post about it somewhere but Brecht said that the skin shader is a possibility for the 2.68 release while he is doing ui and small features but he didn’t want to make any promises.
The Arnold skin shader can be completely recreated with nodes now that mix factors of 0 or 1 are optimized. It would still be nicer with true boolean switches, but I should be able to have a full working skin shader with documentation up within a day of the SSS release.
Great! Thanks for your work on that.
thanks for the update m9,waiting for a build,really excited.hopefully the bump map issue will be resolved in these coming weeks.
not too bothered about gpu,as i’ll probably be using cycles hair too.
thanks brecht!!!
Skin Shader incoming as soon as my VC2008 finished installing, or I can get my hands on a build.
sss it’s here, now waiting for a win build 
windows 64 build is available now on buildbot.
edit: lol,blender crashes when I add sss node to anything.anyone else?
Well it is an initial commit (and one that took a tremendous amount of work to pull off, look at all of the code files that are affected, and this isn’t even the refactor committed before it that was also required).
So do make sure that you report any and all SSS issues so we can enjoy a robust implementation for the final release.
windows 64 build is available now on buildbot.
I’m more in the vein of waiting for the next MingW build, a lot of my scenes render at nearly double the speed compared to the generic MSVC 2008 builds.
MingW is unstable by itself, it will be quite the effort to get SSS going as well.
Crashes everytime, doh