Is anyone able to get this ? All the examples i see on youtube are cartoonish blobby renders…a poor advert for RS !! Arnold seems to be able to keep the definition of the original shapes and details but as with RS i have only tried demos. Arnold can pick up shader settings from the TFD render settings, RS seems totally independent…very blobby
To create sharp contours with any volume renderer, cut off the low end of the emission mapping and create a steep increase to a high value color. In Redshift that’s the Emission Remap Ramp gradient.
Note that the 2nd knot from the left has a value of zero, cutting off the low end of the (density) input values.
The volume shaders of the different renderers all basically work the same and thus are capable of the same looks. It’s mostly the UIs that are different and potentially make it less obvious how to get to a certain result. IMHO C4D’s gradient editor, as used by the RS shader UI, isn’t as direct as an fcurve editor for this type of shading setup.
1 Like
Thanks…I am so used to the TFD settings but the render hit with AR or Phys render is an issue, not so much for raw TFD but when you add it to a scene…and blurry reflections are a no no !! I have been working on a scene for testing and will put up some results here and on other forums and see how people approach this with different renderers. So far the sweetest look I get is the default TFD shader settings but that is just a case of getting the hang of things. RShift is fast…until you want quality then it can really bog down…but the noise removal tools can allow for lower settings, not sure how they would animate though. I think I will have to get a handle on RS as it will be the Maxon renderer of choice. I see RS has a step size feature, how well does it handle ver large bcf files ? With a 12 GB Titan will it be able to handle say 400 million voxels at 0.3 step size to match TFD container resolution ?
You’ll have to test the exact limits with current RS versions on your setup. There can be a difference in terms of memory footprint between the render engines. Comparing Arnold GPU, Redshift and Octane in this regard would be interesting.
Arnold is far more comfortable to work with. RS seems to have features added just for the sake of showing off the massive intelligence of the designers…no…I jest…but it makes VRay look simple. Everyone is leaping up and down hailing RS…but I remember the same with FinalRender…and of course that was to be the ultimate plugin…kids today will not have heard of FR !! God I am old…I was using C4D R5 and that seems like yesterday… Still a newbie though
Octane bails out when out of GPU RAM I believe
Redshift and Vray are both biased render engines, which means they employ a catalog of techniques that deviate from the ideal render model in favor of speed. These techniques come with their set of parameters that need tweaking by the user.
OTOH, Arnold, Maxwell and Octane are unbiased engines that take a more brute force approach to implementing the ideal render model. This results in much less exposed parameters at the cost of render speed and some control.
The actual difference in render speed depends on the specific scene, such that you’ll have to compare actual render speeds on a case-by-case basis. Volume rendering with multiple scattering has been an area with few practial biased shortcuts, making the render speeds in both camps more similar than for other types of renders.
There is out-of-core support for some of the render engines. That is, they could keep rendering when exceeding GPU memory. If that works for volumes and how much of a performance drop it entails i don’t know, but should be straight forward to test.
1 Like
Hey Paul, that Step size in RS…don’t bother with it. It’s SUPER touchy and doesn’t give any real visual gain to the final render. It just gobbles all your ram and render times. You’re better off refining the min/max values and channel ramps for detail/sharpness.
I’ve also found using a decent HDR with and additional key light can help get that Arnold out of the box look. It does take a little work as was mentioned by Jascha due to the unbiased nature of RS. RS has been moving slow with their volume developments, but they have made significant improvements from the beginning though.
I use dual Titan X 12GB (maxwell) cards and have pushed a 280-300+ MV container before and it takes a beat to load in RS. Pro and con. The load times of each frame actually helped my card to cool down between rendering the frames. So it took longer (I’ve hit 6-8 minutes a frame before) but kept the cards from heat throttling.
1 Like
For better results with Redshift and TFD use exported VDBs.
I don’t see how this would affect the render results at all. Could you elaborate, please? Do you have an example that shows the differences?
There are huge differences and it nagged me a lot. So i just tried the VDB-export. Et voila, more fine and sharper details.
Same setup for both images. Except the first uses the cache out of the TFD-container and the second uses the VDB export from the same TFD-container.
Compare for yourselves:
1 Like
I can see differences on the contour of the fire when A/B-comparing the images. This is a bug either in bcf2vdb or Redshift.
Could you send this scene or a reduced version of it to support@jawset.com? I don’t need the rocket, just the sim setup with the emitters, etc.
Thank you.
It might look like more detail in some cases, but it’s most likely loss of data in the VDB case leading to a sharper falloff at sparse block boundaries.
With chaotic complex shapes as such fluid sims, actual processing errors can sometimes look interesting. This can make them tricky to spot.
It’s not a good idea to try to exploit such a bug to achieve any specific effect. The outcome will usually be arbitrary and impossible to control.
I get a similar issue when testing. Vdb is blazingly fast to render vs bcf 50 secs vs 2 min 31 But the stepping is strong. 
Of course there is the time taken to do the bcf to vdb conversion which may offset the extra time used when RS does all the internal data loading and conversion. BUT the conversion is a one off job where as loading geometry and RS inline conversion will happen at every render.
Sadly I did not sim with velocity cached as I could have then added MB to the TFD…which of course it should have and I would think that would solve that issue !!
Well testing was not so good ! A 40min sim with velocity took 4 1/2 hours to convert to vdb…now I am not looking forward to the motion blur render hit using a Volume object in Redshift. Just a note to get the velocity data converted into the 3 channels RS needs you add the -s switch to the bcf exe converter
Not too bad…default MB of 1 renders at 47secs but is too weak…MB set at 10 only raises the render to 1.17. Note the MB for the TFD is set separately from the overall MB. Note the fire seems to have gained detail. I am still gingerly feeling my way around RS… l will try a full render and see how it comes out. I really need to get a handle on how to render out the TFD and beauty as AOV’s and composite. This is easy i AR but I find AOVs rather daunting
1 Like
Please send a minimal scene file that demonstrates the contour issue as well as the slower render times to support@jawset.com. I will work this out with the Redshift developers.
Thank you.
1 Like
Get that to you tonight
ok you should have the file in your mail. For a AR render you will need to render out burn not temperature…sorry was fiddling with the file !!