We have sorted a work flow in Nuke that matches the beauty render exactly from VRay but gives us full flexibility of the raw elements within comp:
As you can see we have to extract our own rawLight, diffuse and reflectionFilter. If we don’t, and use these elements as output by VRay we end up with serious fringing issues.
Is it possible to get all the information/elements we need out of the render elements without doing this?
eg. - I would presume that the lighting is just the raw Lighting multiplied with the diffuse… But dividing the lighting by our diffuse gives a different looking raw lighting…
Also we get our diffuse out of the Gi by dividing it by the raw Gi - this looks different (less filtered) than the Diffuse render element.
I think the correct thing to do is to derive your raw passes form the other ones (e.g. GI/diffuse=rawGI) - we are working on doing this internally in V-Ray.
Well, people have found that deriving the raw channel from the filter and the full channel usually works somewhat better, be it for lighting, GI, reflections or refractions.
Have there been any developments with regards to extracting the RawLight from the Diffuse and Lighting (Similarly for RawGI)
If I use the raw light straight from Vray I have halo-in/fringing issues, and if I extract the RawLight from VrayLighting and Diffuse I get other fringing issues (please see attachments in link above
In our studio we regularly need to adjust diffuse without affecting lighting or GI as we are often asked to produce variations of colours without wanting to re-render
Any help you could offer would be much appreciated, I felt so close to having these edge issues sorted but it seems to be 1 step forward and 2 steps back now
I realize this thread hasn’t been touched in a while, but I haven’t seen this mentioned anywhere else, so I thought I would add it here.
We are successfully using calculatedRawGI = GI/Diffuse etc and it works great in MOST cases. However when diffuse element has pure 0.0 in any channel (r,b, or g) you get incorrect results for your calculated raw element since you are dividing by zero. For example if you diffuse element has a pure blue pixel rgb(0,0,Y) the calculateRawGI will have rgb(0, 0, X) (pure blue) which is not correct. This can cause issues when working with products that have very specific branding colors that need to match ‘exactly’. I realize one solution is make sure you don’t have any pure 0.0 values anywhere in your diffuse, but it would be really nice if we just a got a usable raw elements in the first place so we don’t have any information lost in multiplication. If internally you use the same solution to generate a ‘correct’ raw lighting from GI/diffuse you would end up with the same problem whenever you have a pure 0.0 channel in a pixel.
Has there been any update on this issue since the last post in this thread?
If you have diffuse 0, it doesn’t matter what raw GI you are using. This is the practical meaning of this division by 0 - your choices are “infinite”. However the software must be made in such a way, not to actually do this division, otherwise you will get something strange called “not a number” :). “Any number” can suit your job, except this “not a number” :). So this seems to me that is implementation issue, not an issue of the method itself.
The problem is really that we need a usable rawGI directly out of render elements in the first place. That is what we are trying to re-create with the Diffuse / GI hack and that is what gives rise to the / by 0 issue which is unavoidable when any given channel’s diffuse is 0 (Keep in mind I’m talking about only 1 or 2 of the RGB channels being 0, and other channel(s) having an actual value, like pure red (1, 0 0)). The problem is that information is being discarded that we need and cannot be recovered just form the GI/Diffuse hence they division by 0. This is information that was discarded lives in the rawGI pass, since rawGI * Diffuse = GI. We have to do this division hack because the existing rawGI pass does not line up properly with the other elements. The existing rawGI pass does NOT have this problem with pure color channels and would be exactly what everyone wants, if it lined up properly. Given that the existing rawGI handles zero’s in color channels, I assume you have enough information in the rendering process to get the rawGI information without having to do a Diffuse/GI divide by 0 or at least it seems that way. If not maybe you can explain in a little more detail why this is not possible or why the rawGI pass does not line up properly?
