You can eliminate/reduce flickering.
The problem is that you are using a different point cloud for each frame. This causes flickering.
To fix the problem, generate the point cloud on frame 1 and then use the same point cloud for the entire animation. This may sound strange given that the object is deforming but the point cloud doesn't store point positions – it stores parametric surface coordinates. These coordinates are re-mapped onto the surface before each frame. Houdini's SSS was specifically designed to handle deforming meshes.
To summarize:
1) Go to frame 1.
2) Set the point cloud file to “$HIP/points.pc” (note that there is no “$F”).
3) Set the point cloud mode to “Write to File”.
4) Render the first frame.
5) Change the point cloud mode to “Read from File”.
6) Render your animation.
I attached my results. Good luck!
Found 29 posts.
Search results Show results as topic list.
Technical Discussion » SSS flickering (mantrasurface)
- ikerr
- 168 posts
- Offline
Houdini Indie and Apprentice » Render View different than image rendered to disk
- ikerr
- 168 posts
- Offline
Hi John,
I would use a random primitive attribute as an offset. To the offset, add the frame number ($F) to get the image number. In other words, we want something like this: “MyPic_($F + offset).pic”. I threw together a quick example hip file based on your own. It's messy, but hopefully is along the lines of what you're after.
I would use a random primitive attribute as an offset. To the offset, add the frame number ($F) to get the image number. In other words, we want something like this: “MyPic_($F + offset).pic”. I threw together a quick example hip file based on your own. It's messy, but hopefully is along the lines of what you're after.
Houdini Indie and Apprentice » Render View different than image rendered to disk
- ikerr
- 168 posts
- Offline
Hi John,
I had a look at your file and the problem is related to ray-tracing vs. micropolygon rendering. In particular, in micropolygon mode, the parametric surface coordinate “s” being fed into your Texture VOP is always 0, so your texture map lookups occur only along the edge of your texture. To get consistent results between the ray-tracer and micropolygon renderer, enable “Shade Curves as Surfaces” on your object (Render / Dicing tab).
Also, note that you can see the results of the micropolygon render in the Render Viewer when the Render Viewer's “Preview” toggle is off.
Hope that helps.
Kind regards,
–Ian
I had a look at your file and the problem is related to ray-tracing vs. micropolygon rendering. In particular, in micropolygon mode, the parametric surface coordinate “s” being fed into your Texture VOP is always 0, so your texture map lookups occur only along the edge of your texture. To get consistent results between the ray-tracer and micropolygon renderer, enable “Shade Curves as Surfaces” on your object (Render / Dicing tab).
Also, note that you can see the results of the micropolygon render in the Render Viewer when the Render Viewer's “Preview” toggle is off.
Hope that helps.
Kind regards,
–Ian
Houdini Indie and Apprentice » Render View different than image rendered to disk
- ikerr
- 168 posts
- Offline
Hi John,
Do you have a hip file that you can post? One potential difference between the Render View and rendering to an image is that the Render View always uses the ray-tracer. I don't see why this would cause the difference that you're seeing though.
Thanks,
–Ian
Do you have a hip file that you can post? One potential difference between the Render View and rendering to an image is that the Render View always uses the ray-tracer. I don't see why this would cause the difference that you're seeing though.
Thanks,
–Ian
Technical Discussion » A "dead" function in physicalsss.h
- ikerr
- 168 posts
- Offline
Hello,
It is true that vop_sss_multi_brdf() is not currently used by the SSS shader. It is provided mainly for completeness and debugging/comparison purposes. vop_sss_multi_brdf() has fewer options than getLocalMultiRadiance(). For example, you cannot specify a local radius of integration or a depth value. Hope that helps.
–Ian
It is true that vop_sss_multi_brdf() is not currently used by the SSS shader. It is provided mainly for completeness and debugging/comparison purposes. vop_sss_multi_brdf() has fewer options than getLocalMultiRadiance(). For example, you cannot specify a local radius of integration or a depth value. Hope that helps.
–Ian
Houdini Lounge » Houdini in the video game industry... ?
- ikerr
- 168 posts
- Offline
Houdini Lounge » physical sss buzzing
- ikerr
- 168 posts
- Offline
Hi Jason,
Yes, light sampling quality is still very much important with PBR. Depending on your scene, some lights will require more samples than others to achieve low noise levels. Finding sampling qualities that are neither too high nor too low goes a long way towards establishing a good balance between image quality and render speed. Good luck!
–Ian
Yes, light sampling quality is still very much important with PBR. Depending on your scene, some lights will require more samples than others to achieve low noise levels. Finding sampling qualities that are neither too high nor too low goes a long way towards establishing a good balance between image quality and render speed. Good luck!
–Ian
Houdini Lounge » physical sss buzzing
- ikerr
- 168 posts
- Offline
Hi Jason,
The problem in this case is that the irradiance calculation (per-point) is not stable from frame to frame. The complex geometry of the leaves requires a higher number of samples to properly resolve shadows. You can fix this by increasing the sampling quality on your lights, but likely the best approach is to increase the “Global Light Quality” setting on the Physical SSS Vop. This may also mean that you can reduce your point cloud size. You might also try using the “Local and Global” multi-scattering model as this typically gives the best image vs. performance cost trade-off.
For future reference, I'll mention how I determined the cause of the problem, as it may help others debug similar problems. I first tried enabling caching of positions/normals/areas to test whether the point positions were changing from frame to frame (this would be bad). The problem did not go away, so I then tried enabling caching of irradiance, and this worked, since the irradiance was now constant from frame to frame. This led to the idea of increasing the global light quality to stabilize the irradiance calculation.
Hope this helps! Please let me know if you run into any other issues.
Cheers,
–Ian
The problem in this case is that the irradiance calculation (per-point) is not stable from frame to frame. The complex geometry of the leaves requires a higher number of samples to properly resolve shadows. You can fix this by increasing the sampling quality on your lights, but likely the best approach is to increase the “Global Light Quality” setting on the Physical SSS Vop. This may also mean that you can reduce your point cloud size. You might also try using the “Local and Global” multi-scattering model as this typically gives the best image vs. performance cost trade-off.
For future reference, I'll mention how I determined the cause of the problem, as it may help others debug similar problems. I first tried enabling caching of positions/normals/areas to test whether the point positions were changing from frame to frame (this would be bad). The problem did not go away, so I then tried enabling caching of irradiance, and this worked, since the irradiance was now constant from frame to frame. This led to the idea of increasing the global light quality to stabilize the irradiance calculation.
Hope this helps! Please let me know if you run into any other issues.
Cheers,
–Ian
Technical Discussion » Issues with SSS + Glass + PBR
- ikerr
- 168 posts
- Offline
I've attached a second stab at the problem. The key here is that I've enabled “Faux Caustics” on the Mantra Surface used to render the glass. The reason you weren't seeing scattering is because when the SSS traced a ray from the label to the light, the glass surface was encountered and had an opacity of 1. You could do something similar in a custom shader by using the “isshadowray” VOP, setting some opacity less than 1 in this case.
Houdini Lounge » physical sss buzzing
- ikerr
- 168 posts
- Offline
Hi Jason,
Any chance you can post a simplified hip file? There should be absolutely no buzzing related to multi scattering for a static scene *if* each rendered frame is using the same point cloud. Likely I can help out with this if you can get me a hip. Thanks!
Any chance you can post a simplified hip file? There should be absolutely no buzzing related to multi scattering for a static scene *if* each rendered frame is using the same point cloud. Likely I can help out with this if you can get me a hip. Thanks!
Technical Discussion » Issues with SSS + Glass + PBR
- ikerr
- 168 posts
- Offline
Hi there,
I downloaded your scene and made a few tweaks in an attempt to speed it up and resolve some of the issues you were seeing. It is attached below. The main changes I made were the following:
I downloaded your scene and made a few tweaks in an attempt to speed it up and resolve some of the issues you were seeing. It is attached below. The main changes I made were the following:
- Reset the ROP's Reflect Limit, Refract Limit, and Diffuse Limit to reduce render times.
- Reset the ROP's Pixel Samples to 3x3. You may want to increase this for improved quality.
- Reset each object's Shading Quality and Ray Shading Quality to reduce render times.
- Disabled each object's pre-dicing.
- Turned off Optimize Secondary Rays (more on this below).
- Replaced your glass shader with a Mantra surface based glass shader.
Secondary ray optimization is much more useful for surfaces that are nearly opaque (marble comes to mind). This feature replaces the usual SSS calculation (which involves ray-tracing) with a simple BRDF.
I replaced the glass shader with one based off of the Mantra surface in order to reduce noise that I was seeing on the glass. This seemed to work well. Also, if you suspect that the SSS is too noisy, try increasing the Samples parameter (Single Scattering tab) on the Physical SSS Vop rather than increasing a global setting such as the Pixel Samples or Shading Quality. This should help keep your render times sane.
Anyways, give this scene a try and see if it is a step in the right direction. Let me know if I can be of any further help!
Cheers,
–Ian
P.S. I haven't gotten around to tasting Houdini 11 flavoured wine yet. How is it?
Technical Discussion » Cannot render in Apprentice.
- ikerr
- 168 posts
- Offline
Are you using a hip file that was saved using an older version of Houdini? Try putting down a new Mantra ROP and rendering with that.
Technical Discussion » Compiling 3delight shaders in 11
- ikerr
- 168 posts
- Offline
Greetings,
In H11 we introduced an “active renderer” setting. Please make sure that you have 3Delight enabled in Edit > Preferences > Rendering.
–Ian
In H11 we introduced an “active renderer” setting. Please make sure that you have 3Delight enabled in Edit > Preferences > Rendering.
–Ian
Houdini Indie and Apprentice » Marble in H11 gives "no image"
- ikerr
- 168 posts
- Offline
I've attached a hip file with a marble shader I was messing around with a while ago. It needs a bunch of work but it might get you started. I haven't promoted any of the parameters from the VOPs so you'll have to do that yourself or adjust the parameters on the VOPs themselves. As well, you'll need to use the kr output of the Physical SSS VOP to do something with the light reflected at the surface. If you find it useful and are able to tweak it to make it more complete/usable, perhaps we can replace the gallery entry with it.
Houdini Lounge » pcunshaded in SOP context
- ikerr
- 168 posts
- Offline
Hi Mate,
You're correct that you shouldn't assume anything about the order in which points are shaded. It may very well be the case that they *are* shaded in order, but we make no guarantees about this and so this could change. In addition, if you are shading with multiple threads, you will almost certainly run into problems if you assume a certain ordering. Hope that helps. Cheers!
You're correct that you shouldn't assume anything about the order in which points are shaded. It may very well be the case that they *are* shaded in order, but we make no guarantees about this and so this could change. In addition, if you are shading with multiple threads, you will almost certainly run into problems if you assume a certain ordering. Hope that helps. Cheers!
Houdini Lounge » pcunshaded in SOP context
- ikerr
- 168 posts
- Offline
Hi Mate,
Not to worry, I had many a puzzling day working on sub-surface scattering and point clouds The pc functions are quite powerful but take some time to get used to. I find that you need to think slightly differently…
Anyhow, good luck!
–Ian
Not to worry, I had many a puzzling day working on sub-surface scattering and point clouds The pc functions are quite powerful but take some time to get used to. I find that you need to think slightly differently…
Anyhow, good luck!
–Ian
Houdini Lounge » pcunshaded in SOP context
- ikerr
- 168 posts
- Offline
Hi Mate,
You might want to have a look at the Physical SSS shader (hfs/houdini/vex/include/physicalsss.h: createPointCloud()). It uses a dart throwing algorithm to distribute points evenly over a surface. In H11, pcexport() takes an additional radius parameter that indicates the minimum separation distance between the point being exported and every other point in the point cloud. If the test fails, the point will not be exported. The idea is that the pcunshaded() loop continues until all points have been shaded and satisfy the distance requirement.
You might want to have a look at the Physical SSS shader (hfs/houdini/vex/include/physicalsss.h: createPointCloud()). It uses a dart throwing algorithm to distribute points evenly over a surface. In H11, pcexport() takes an additional radius parameter that indicates the minimum separation distance between the point being exported and every other point in the point cloud. If the test fails, the point will not be exported. The idea is that the pcunshaded() loop continues until all points have been shaded and satisfy the distance requirement.
Houdini Lounge » pcunshaded in SOP context
- ikerr
- 168 posts
- Offline
Hi Mate,
pcunshaded() is designed to shade all the points returned by a query (pcopen(), pcopenlod(), etc). Typically, you'll do your query, shade the un-shaded points returned by the query, and then iterate over the points:
int handle = pcopen(…);
while (pcunshaded(handle, “MyChannel”))
{
rval = pcexport(…); // save channel data
}
while (pciterate(handle))
{
rval = pcimport(…); // import channel data
}
The advantage of this approach is that you only shade points returned by your queries, which may be less than the total number of points in the point cloud. If you don't pcexport() a value for each point in your point cloud, those points will essentially have undefined values (unless we guarantee they are initialized to zero, I forget). So my question to you is, why do you wish to do this? Can you just pcexport() a value of zero?
Thanks,
–Ian
pcunshaded() is designed to shade all the points returned by a query (pcopen(), pcopenlod(), etc). Typically, you'll do your query, shade the un-shaded points returned by the query, and then iterate over the points:
int handle = pcopen(…);
while (pcunshaded(handle, “MyChannel”))
{
rval = pcexport(…); // save channel data
}
while (pciterate(handle))
{
rval = pcimport(…); // import channel data
}
The advantage of this approach is that you only shade points returned by your queries, which may be less than the total number of points in the point cloud. If you don't pcexport() a value for each point in your point cloud, those points will essentially have undefined values (unless we guarantee they are initialized to zero, I forget). So my question to you is, why do you wish to do this? Can you just pcexport() a value of zero?
Thanks,
–Ian
Houdini Lounge » pcunshaded in SOP context
- ikerr
- 168 posts
- Offline
Hi Mate,
Loops of pcunshaded() should not loop forever in H11 as long as you are shading each point with pcexport(). If you don't shade each point, the loop will continue returning the unshaded points. pcunshaded() is supported in both SOPs and SHOPs. Can you post a simplified hip file that demonstrates the infinite looping? Is this a hip file that worked in H10 but does not work in H11?
Thanks,
–Ian
Loops of pcunshaded() should not loop forever in H11 as long as you are shading each point with pcexport(). If you don't shade each point, the loop will continue returning the unshaded points. pcunshaded() is supported in both SOPs and SHOPs. Can you post a simplified hip file that demonstrates the infinite looping? Is this a hip file that worked in H10 but does not work in H11?
Thanks,
–Ian
Technical Discussion » Shader View?
- ikerr
- 168 posts
- Offline
Greetings,
The next build of Houdini has some fixes for the Shader View. Try out that build and let me know if you run into any other issues. Note that not everything will work in the Shader View. Sub-surface scattering is one example.
With that said, I'd highly recommend using IPR for previewing your materials as it will give you a much higher quality preview. Setting it up isn't quite as convenient, I agree, but I think the benefits far outweigh the set up time.
Thanks!
–Ian
The next build of Houdini has some fixes for the Shader View. Try out that build and let me know if you run into any other issues. Note that not everything will work in the Shader View. Sub-surface scattering is one example.
With that said, I'd highly recommend using IPR for previewing your materials as it will give you a much higher quality preview. Setting it up isn't quite as convenient, I agree, but I think the benefits far outweigh the set up time.
Thanks!
–Ian
-
- Quick Links