Awesome! We can finally stop undoing the radial gradient texture with - 0.5 and * 2PI to get the same thing, because it is already implemented with atan2.
Now we just need native floor and ceil since the only thing they give us is round which is actually implemented with floor with + 0.5 on the input… that I have to undo with - 0.5 on my floor node input.
There are many others. Would have been better to just copy the operations available in an existing standard like GLSL, etc. or at least expose all the native operations already used by cycles. After all, we need the offerings of a complete shading language due to the lack of built-in procedurals, effects, and utilities that are often included with other renderers by default.
??? Putting it into master would just mean that it is part of the nightly builds, and nightly builds generally aren’t something you’d want to use in production either.
Besides, the 2.8 branch will be moved into master very soon, so there honestly was no point in doing so. If you absolutely must use it in nightly builds now, you can just apply one of the earlier versions of the patch.
Currently, we are in a very long stretch without stable releases. That was known for years in advance and it’s extremely important for Blender’s development in the long term. Complaining that you’ll have to use a very unreliable branch instead of a somewhat unreliable branch because you don’t want to wait a few months or build your own version is, well, “professionally amateurish” I guess.
And regarding technical writing (I’m replying to this since I wrote the comment you refer to): Look, I’m doing this for fun in my free time. I’m also doing Cycles coding as a job, and if the IES patch was part of that, I’d write documentation if needed. However, it’s not, it’s something I’m doing for fun in my free time on top of a coding job and university. This results in two things. First of all, I have to allocate my time. Sure, I could spend three hours on detailed documentation, but I could also spend them on another feature. And on the other hand - writing code is fun, writing docs isn’t. Again, if this was a job, this wouldn’t matter, but if I’m giving up a rather large part of my free time for this, it absolutely does matter.
i would definitively like to see this IES lamp added in normal blender
right now have to use other renderer like Yafaray or Lux to get a more realist
fixture light in architectural models
hope it comes as soon as possible
would it be possible to add it in 2.79 daily built may be
Just to add to this: The documentation team is always open to contributions. So @Marc_Driftmeyer, if you find the documentation is deficient and you have a more thorough explanation that more people will understand, I’m sure that documentation team would be more than happy to accept your updates.
Blender development is more than just code and it’s more than just developers who can be a part of the process. If the documentation is bad, its all of our fault.
I’m thinking an expression node would be nice, too. Instead of having to chain dozens of math nodes together, a node with an elastic number of inputs and a text field would be cool.
Lukas, Any chance you can update the networking patch to Master? If can great and appreciated, If not no worries, maybe the patch will hit master in 1-3 years like most other really helpful patch’s
Not right now, networking needs a lot of work and I just don’t have the time for it. It will happen eventually, but I can’t guarantee any date for now.
I hope Lukas has enough time this Summer to polish up and commit most of the patches he started, but has not been able to finish (like the dithered Sobol sampling).
Sadly, since this commit I can no longer successfully compile master on Linux Mint 18.3 (although I’m not 100% sure it’s related to this commit since I can still compile 2.80 with IES included).
Any chance we could finally see AO map (not material) to create procedural wear like dust in corners and scrached convex edges? All it would really need is a simple map outputs which grayscale color, and has options to define AO radius distance and toggle between shooting the rays on the inside or outside of the normal (to switch between raytracing convex vs concave corners).
Inputs would be input for black AO color, input for white AO color, and input to drive AO distance parameter with a map.
Brecht has already said he plans to do it, but it’s been quite a while since, and still nothing happened
Brecht is one of the developers brought to the Institute as part of the Code Quest, so all of his recent work is on functionality related to 2.8 targets.
Lukas Stockner though might have time this summer to look at something like this.
I hope so. Cycles can already do AO, and AO shader even. So we just need it as a map that has distance unrelated to global AO radius and a few more properties. Shouldn’t take that much time
This is very different, though. The AO shader works by tracing one ray and returning one or zero, over time with enough samples the result averages out to the correct value.
For an AO node it’s not that easy. Why? Well, you could implement it just like that - output one or zero every sample. That would work for simple applications like mixing two closures together, but if you e.g. use the AO node to control the roughness of a Glossy BSDF, you’d end up with a mix of perfectly sharp BSDF (due to the node returning zero) and a perfectly diffuse BSDF (due to the node returning one) instead of a somewhat glossy BSDF.
To be a bit more precise, the random one-sample approach works if the shader output is linear w.r.t. the AO value. For BSDF mixing this is guaranteed (since the only two operations on them are Add and Mix), but for color outputs it’s not.
So, how can it be done? Well, you can trace multiple ray per bounce and average those, and if you use enough the difference to the theoretical result becomes small enough to be acceptable. That’s what the bevel node also does, btw. The downside is that it’s extremely slow.
Side note because I know that this will be brought up eventually: This also is why Eevee can have a BSDF to Color node, but Cycles can’t - Eevee evaluates everything in one pass, while Cycles works randomly.
TL;DR: An AO node is possible, but it definitely is much harder that “just” copy-pasting the AO BSDF. I mean, this has been one of the most-requested features for like 5 years, do you really think it would still be unsupported if it was that easy?
Edit: If you want to generate textures based on AO, I’m fairly sure that it will be faster to bake AO and use the result as an image texture in Cycles (especially once baking denoising is finished).
I never knew Cycles AO was done in the 1 or 0 boolean matter. I always assumed that max distance defines white color, 0 distance defines black, and distance in between 0 and max distance returns shade of the gray color depending on the distance, then anything beyond max distance just returns white.
And yes, I’d assume such node would natively use ray branching.
I did not assume that AO map node would be a copy/paste kind of scenario, but I did assume that some of the Cycles current AO could be scavenged to build it.
I do realize the performance penalty, the reason I want it is that in certain applications, like rapid set dressing and rapid concept art, it saves a LOT more time than it wastes in terms of rendertime, for one simple reason: You can generate procedural weathering effect without any UVs! You can afford to box map or triplanar map entire model, no matter how complex it is, and still generate very convincing detail using this method.
This is a godsend for applications like 3D concept art, where you just want to push out some good results as fast as possible, while having generated a concept art grade high poly mesh that would be borderline impossible to unwrap without some retopo. With the baking approach you are suggesting, I would not be able to do these design nearly as rapidly, because Unwrapping process would likely take longer than modeling itself.
AO based wear and tear is the bread and butter of my workflow and one of the very few last reasons I can not render my stuff in Blender.
Here is an example: https://www.artstation.com/artwork/x2EnX
This is a work of my that doesn’t have a single unwrapped piece! There is just one box map thrown at the each of the parts, and all the detailing is just AO maps. Yes, it does render slower, but it doesn’t render nearly as slow enough to not be usable, even in production.
Ah, okay, sorry for the rant - I’ve explained this so often by now, so I just assumed this was another “it looks similar so it must be similar” case.
Yeah, the point about not requiring UVs makes a lot of sense, I didn’t even think of that to be honest.
Regarding how AO is calculated: AO technically is the fraction of projected solid angle that is not occluded by any geometry, to tracing random rays and checking how many hit something is the obvious way to compute it.
