pax Posted August 13, 2015 Share Posted August 13, 2015 (edited) Hi, I know this topic has been broached many times before, and I did read all the posts, but I haven’t found a solution to the following problem yet: I want to bake light into the UV’s of a mesh. For that I’m using a point light and the UV render object option in the Mantra node. Basically, rendering it that way works, however, I have trouble with my camera. As soon as the camera’s perspective is only slightly altered, I get a different result, which (to me at least) makes no sense, because both the objects and the light stay the same, so the areas that receive light should also remain the same. Even those objects the camera can’t see have light baked onto them, but if I turn the camera towards them, the result is suddenly drastically different. The attached pictures show the difference: In pic 1, the camera is pointing towards the objects; in pic 2 it’s pointing away. I’ve also attached a test scene. Is there a way to render the entire 360° of the light, so the result always remains the same, the position of the camera notwithstanding? Unfortunately, Enable Hiding in the Mantra node didn’t solve this problem. I’ve also tried with the toNDC function and a rest position, but I didn’t get that to work either. I’d be very grateful if someone could help Cheers, Pascal projectionProblem.hip Edited August 13, 2015 by pax Quote Link to comment Share on other sites More sharing options...
Atom Posted August 13, 2015 Share Posted August 13, 2015 (edited) Hmm... I thought baking was supposed to be done with an orthographic camera? The goal of baking is to produce a map that you then apply to the object to avoid having to light it, correct? So you need two scenes. One for baking and one for rendering. After you bake the map in scene #1 open up scene #2 and apply the map to the object and then you can freely move the perspective camera. It seems like you are trying to both tasks in one scene. Edited August 13, 2015 by Atom Quote Link to comment Share on other sites More sharing options...
davpe Posted August 13, 2015 Share Posted August 13, 2015 I think what Pax is trying to do is unfortunately not easily possible in H14. and I agree that it makes baking unusable in many cases. it works in H13 with custom tool that is available for free on Orbolt. but this tool has not been updated for H14. however, I have read somewhere that there is coming improved baking thing with H15 that should be able to do it (please correct me if it is not true as I can't remember a source of that information). D. Quote Link to comment Share on other sites More sharing options...
fathom Posted August 13, 2015 Share Posted August 13, 2015 weird. seems to be a problem with the lighting calculation -- an emit parm seems to eval properly everywhere. also, if you turn off shadows, you get clearly funky "shading" on the "edge" polys... if you really had to get this working, you could prolly roll your own illuminance loop and see if that gets around the problem. Quote Link to comment Share on other sites More sharing options...
pax Posted August 13, 2015 Author Share Posted August 13, 2015 Hey, thanks for your replies. @Atom That’s exactly the workflow I’m aiming for. The problem is that I have to use a point light that emits light in 360°. When I bake my light onto UVs the camera is unable capture the whole 360°, so the light on the objects behind my camera doesn’t get rendered properly (or rather differently from when the camera is pointed at said objects). Using those rendered textures then for a new rendering in a second scene doesn’t work out because the baking process in the first scene was already messed up. @David I tried the texture baker from Orbolt. Doesn’t work in H14 either… But I have to get it done in 14, I don’t have a choice… @Miles Unfortunately I have no idea how to do this. :-) Can you give me a hint? Quote Link to comment Share on other sites More sharing options...
fathom Posted August 15, 2015 Share Posted August 15, 2015 so plop down an illuminance loop node in an empty shop. plug a constant color (0,0,0) into the "Next" plug at the bottom. go into the illuminance loop node. drop an inline node. plug the "_Value" and "_N" from the subnet inputs into your inline node. add a vector output called "c" to your inline node (put "c" in both name boxes). for your inline code: $c = $_Value + dot(normalize(L),$_N) * Cl; connect your "c" output to the "_Value" slot on the subnet out go back up to your main shop level now plug that "_Value" out of the illuminance loop sop into the Cf on your output node. that's a very basic diffuse lighting calculation. you can multiply that by a color to or texture or whatever you want. should handle multiple lights with colors and falloff and stuff. prolly won't do shadows without some additional code. Quote Link to comment Share on other sites More sharing options...
pax Posted August 15, 2015 Author Share Posted August 15, 2015 (edited) Hey, thank you so much. That’s exactly what I’m looking for! Only Problem: The UV-seems don’t render properly. Don’t know why yet but I think it’s not an issue with the loop. Or did you come across something like this before? Thanks again :-) Edited August 15, 2015 by pax Quote Link to comment Share on other sites More sharing options...
davpe Posted August 15, 2015 Share Posted August 15, 2015 fantom: +1 for you, man. although cumbersome, at least it brings a solution. so what is the difference between your formula and a regular surface model lighting calculation? why it doesn't work right away? pax: regarding seams, there were multiple threads how to solve it. try search in google, it's gonna be one of the first results. Quote Link to comment Share on other sites More sharing options...
fathom Posted August 17, 2015 Share Posted August 17, 2015 yeah, i dunno why an illuminance loop solves the problem. you'd think if the problem was related to lights not realizing they need to be called for parts of the geo, it'd show up in a manual illuminance loop. in terms of what the difference is, i don't think illuminance loops are currently used in mantra. everything gets done via bsdf's and for non-pbr, the bsdf gets evaluated in the shader and converted to Cf (compute_lighting node). maybe an investigation into the pbr lighting code would shed some light (no pun intended). Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.