sebkaine Posted March 17, 2015 Author Share Posted March 17, 2015 well it doesn't work ! https://www.dropbox.com/s/y711p9disd03a4r/bake_pbr_02.rar?dl=0 i think i know how i can solve this: - i will take @N - i will take v@E = negate(normalize(@I)) - i will create v@D = mix(dot(@I,@N),v@E,@N) and i will bake v@D instead of @N in the prepass. and read v@D in the lens shader for the bind I. i'm quite sure i will be close to a working solution. let test this later .... Quote Link to comment Share on other sites More sharing options...
sebkaine Posted March 18, 2015 Author Share Posted March 18, 2015 Well it's a Bingo ! Thanks to you eetu i will make the economy of V-ray license You were absolutely right about the use of the normal vector in fact V-Ray do exactly the same. I also suceed to Bake exactly what i see from a cam perspective but like you said. all face outside the view area are not shaded and you can't invent what doesn't exist .. I have fail to make a good enough blend cheat to make the bake in camera view work ! The only way to make it work correctly like you said would be - computation of diffuse with negate(N) as View Angle. - computation of specular with negate(I) as view Angle. I will attach my scene test just in case ! Quote Link to comment Share on other sites More sharing options...
sebkaine Posted March 18, 2015 Author Share Posted March 18, 2015 (edited) The final scene just in case it can be useful ! Thanks again for your magic eetu ! bake_pbr.hip Edited March 18, 2015 by sebkaine 1 Quote Link to comment Share on other sites More sharing options...
MENOZ Posted March 19, 2015 Share Posted March 19, 2015 i didn't followed latest 4 posts, and apparently you've already fixed all that. i didn't see mentioned the "enable hiding" proprety in mantra, maybe it could be useful? I think I've used it in the past to bake uv, not 100% sure tho. Enable hiding Houdini name vm_hidden IFD name renderer:hidden Perform hidden surface removal. When hidden surface removal is disabled, all surfaces in the camera’s frustum will be rendered, regardless of whether they are occluded. This can impact render time significantly. 1 Quote Link to comment Share on other sites More sharing options...
sebkaine Posted March 19, 2015 Author Share Posted March 19, 2015 Thanks Andrea that's good to know that this option to render backface element exist. But in the case of specular elements i don't think it can render anything because reflection are linked to the viewer position. I think eetu is correct when he say that the best way to bake reflection is to use negate(normalize(N)) as incident ray. Exactly like V-Ray do for his bake. Quote Link to comment Share on other sites More sharing options...
eetu Posted March 19, 2015 Share Posted March 19, 2015 the best way to bake reflection is to use negate(normalize(N)) as incident ray. Yep, and with this rendering scheme that's the reflection direction the shaders will automatically have - so no need to modify any materials. Andrea: Yep, I had hiding disabled on the ROPs here, but I don't think it matters in this case anyway. Quote Link to comment Share on other sites More sharing options...
sebkaine Posted March 19, 2015 Author Share Posted March 19, 2015 (edited) Well eetu i was wondering now that we have texture bake working in H. Would you have any idea on how to achieve vertex bake. I am quite new to mantra so i haven't a precise idea on what you can / can't do. Basically what i need to do is : - get Cf / Of shaded result - store this result in the object closest point How about - writing a .ptc that is just a representation of the point of the geo - write the result of calculation in this .ptc - read the .ptc and retransfer the Cf/Of data stored in the initial geo. Of course - writing directly Cf/Of in the geo would be the most elegant i guess Well at least do you think it can be done ? or is it impossible at the moment to do such thing ? Edited March 19, 2015 by sebkaine Quote Link to comment Share on other sites More sharing options...
eetu Posted March 19, 2015 Share Posted March 19, 2015 Ok, here we go! 1) In a lens shader, determine the sequential number of the pixel we are in, think of it as a point number, and fetch the P and N of that point in your geo. 2) As before, use those to fire a ray back at the surface from a millimeter up 3) After rendering, in a vopsop, do the inverse operation of 1) and calculate u and v coordinates for the N'th pixel, where N is the current point number. Fetch the color in that pixel and set point Cd attribute to that. Step 2 is prone to fail with polygon edges, as the ray might or might not hit the surface when fired from/at an edge vertex. One could fire 4 rays and pick the shortest one or something like to fix it. There is a very weird flipping going on, as you can see, the color of the blue light is on the wrong side. Looks as if z is flipped somewhere, but I can't figure out where. One could probably trace rays "by hand" from the points, but I suppose the only way to get all the sampling goodness out of mantra is to render actual pixels. bake_pbr_vertices.hip Quote Link to comment Share on other sites More sharing options...
Skybar Posted March 19, 2015 Share Posted March 19, 2015 (edited) Cool stuff eetu! About the flipping stuff, it couldn't be that mantra is right-handed(or left.. can't remember) as opposed to SOPs? If you simply scale the geometry -1 in Z it fits (or a Mirror SOP, same thing). So I guess you'd need to reverse the point numbers at some point in this setup in the Z-axis to make it work. This is fine because we have a symmetric shape here, however I don't know how it'd be with an asymmetric one.. This just came to mind, I hope it helps! edit: Well I just inverted P and N in your lens shader and it works. Still I don't know how it'll turn out with an asymmetric object. It'll probably work though. Edited March 19, 2015 by Skybar Quote Link to comment Share on other sites More sharing options...
sebkaine Posted March 19, 2015 Author Share Posted March 19, 2015 (edited) eetu you are a jedi ! thanks a lot for your help guys ! again i will need some time to digest all this ! but i'm quite sure it will works perfectly. there is one thing that bother me in mantra it's the fact that it seems that you don't have any equivalent to prman bake3D() rsl function. https://renderman.pixar.com/resources/RPS_17/baking3d.html basically it would be more convenient to - open the point cloud - write in the point cloud the channel you want to store directly in the shader All this point / volume baking workflow is totally non existent in Mantra ? this logic of baking is kinda old school but i'm quite sure it could allow us to enter in the dimension of 5 minutes per frame in 1080P for static set in PBR. And after further test i still think Photon map suck in a way - weird color behavior in certain area that look unnatural - corner effect problem that force you to augment the thershold for PBR computation - artefact in certain area => too much incertitude / risk of bug enter in the game and you lost time to setup / tweak / correct problems. this is not a reliable process, better keep full PBR or Occlusion Lighting. There are imo better idea to store data than pmap ... I'm still in need of this idea of computing a brute force GI with AAAA quality and then read it in animation with only a read in Cd and a rendertime around 2 minutes per frame ! Edited March 19, 2015 by sebkaine Quote Link to comment Share on other sites More sharing options...
edward Posted March 20, 2015 Share Posted March 20, 2015 basically it would be more convenient to - open the point cloud - write in the point cloud the channel you want to store directly in the shader http://www.sidefx.com/docs/houdini14.0/vex/functions/pcwrite ? Quote Link to comment Share on other sites More sharing options...
sebkaine Posted March 20, 2015 Author Share Posted March 20, 2015 (edited) Thanks edward ! each time i said something is not possible in H someone come with a solution. the thing is that i need to test if we can : - call a geometry itself inside H (link to a SOP object) and not a .ptc on disk - write directly the data inside a new attribute. i'm gonna dig that ! Edited March 20, 2015 by sebkaine Quote Link to comment Share on other sites More sharing options...
edward Posted March 21, 2015 Share Posted March 21, 2015 From Mantra? How would that work since it's a separate process. Quote Link to comment Share on other sites More sharing options...
sebkaine Posted March 21, 2015 Author Share Posted March 21, 2015 Thanks for your answer Edward ! Again i am new to mantra so i have absolutely no idea on what is possible and what is not ! From what you said Edward - a SOP object is Houdini related only - when a shader is executed it's a Mantra only process - thus when you use the pcwrite command you can only acces a .PTC on disk ? => is that correct ? => in other word accessing SOP geo point directly with pcwrite is not possible. So do you think a 2 step process would be possible. For exemple take a Polygon scene. - this scene is compose of few SOP object - those few sop object are represented by 100.000 points - first i simply write a .ptc compose of the point of the geo only (100.000 points) and i write 1 emply channel Cs for exemple - i render those object and i store the result of indirect diffuse in Cs with pcwrite - then i load my ptc and i transfer Cs to my SOP object - and thus i have my GI bake in vertex => Does it sound like a realistic plan ? or does it looks stupid ? Thanks for your help ! Quote Link to comment Share on other sites More sharing options...
edward Posted March 22, 2015 Share Posted March 22, 2015 => in other word accessing SOP geo point directly with pcwrite is not possible. Correct. So do you think a 2 step process would be possible. Yes. Quote Link to comment Share on other sites More sharing options...
sebkaine Posted March 22, 2015 Author Share Posted March 22, 2015 (edited) Thanks ! i'm gonna try that then ! Imagine that instead of storing indirect diffuse inside the vertex i would prefer a volume approach How could i sort of mimick the brickmap workflow in prman. This could be done i guess - write the .pc with empty Cs channel in GI.pc - pcwrite indirect diffuse in Cs channel - then convert GI.pc to a volumetric format. What would be for you the most convenient format in Houdini to achieve volume bake ? - .i3d looks to be the closest format to .bkm from what i see in the doc - .vdb would be my second choice i guess. So i would be very interested to know what you would advise beetween .vdb and .i3d for - fastest access to the data - best blurring / filtering / postprocessing of the bake data - level-of-detail representation - clever adaptation of data density - fastest direct access of the bake data inside a shader Thanks again for your help ! Edited March 22, 2015 by sebkaine Quote Link to comment Share on other sites More sharing options...
edward Posted March 23, 2015 Share Posted March 23, 2015 I'm not sure. Testing might be needed. .i3d is fairly dense compared to .vdb so .vdb might be a better choice if you have lots of empty space. Quote Link to comment Share on other sites More sharing options...
sebkaine Posted March 23, 2015 Author Share Posted March 23, 2015 (edited) Thanks for you help Edward ! so to sum up : - pcwrite indirect diffuse in GI.pc - then load GI.pc and transfer it to vertex in geo sop in @Cs or convert it to GI.vdb - then read data store in in @Cs or in GI.vdb in the shader => would work in theory. I would have maybe one last question for you Edward ... How would you read .vdb bake data inside the shader ? Is there any equivalent to Texture3D() RSL function in Mantra that can read .vdb cache ? Thanks again for your help ! Edited March 23, 2015 by sebkaine Quote Link to comment Share on other sites More sharing options...
edward Posted March 24, 2015 Share Posted March 24, 2015 I'm think you should be asking someone else. I /think/ texture3d() in VEX might only support .i3d ( Old topic: http://forums.odforce.net/topic/8974-how-can-i-convert-pc-to-i3d/ ). Quote Link to comment Share on other sites More sharing options...
sebkaine Posted March 24, 2015 Author Share Posted March 24, 2015 Thanks Edward ! It looks that .pc and .i3d are good enough to try cloning .ptc and .bkm The texure3D() in VEX is a very good starting point. The fact that there is a tool to convert .i3d to .bkm also work in favor of it instead of .vdb I would still be very curious to know if someone has try to read a .vdb grid inside a shader. I would also very interested to know where we can find function that allow read/write in .vdb at shader level. VDB search in VEX function doesn't give any outpout in the help at the moment ! 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.