Testing liquid in glass approaches

cycles

(David Rutten) #1

Trying four different approaches to rendering a glass container filled with liquid.

  1. Liquid and glass shapes have been unioned into a single shape. This is obviously only a solution for when the container and the contents have the same material. In the case of water and glass at least the index of refraction is different, so even though this looks rather good, it is not technically correct and does not scale to more complicated scenes.
  2. The glass and the liquid are both separate, closed polysurfaces that fit into each other exactly. This is the naive approach which yields problems because the surface meshes are coincident.
  3. Same as (2), except the liquid shape is scaled up by 1%. As a result the shape of the water intersects the shape of the glass, fixing the coincidence problem but resulting in other weird side effects.
  4. Three separate surfaces all with their own material. IOR values picked to represent Air→Glass, Air→Water, and Glass→Water.

Long story short; use (1) if you can get away with it, (3) if you’re gunning for ‘good enough’ or (4) if you aim to impress.

IOR tests (no environment).3dm (8.2 MB)


#2

@DavidRutten, thanks a lot for the tutorial and file. Do you remember how many samples this image was rendered with and how long did it take ?

@nathanletwory, while trying to find a hdr image on my system which roughly matches David’s result, i had to chose 20 different ones. After that i looked at my taskmanager and found that Rhino uses 10 Gigabytes of RAM. Is this expected ? btw. i am test rendering using GPU only.

c.


(Nathan 'jesterKing' Letwory) #3

@clement it is a known bug: http://mcneel.myjetbrains.com/youtrack/issue/RH-34882


#4

@DavidRutten (3) is the way like Vray works, intersecting objects. Could be nice if Cycles could show the correct result here and so render engines could be easy switched.


(David Rutten) #5

It was slower than most renderings I did lately, maybe because I cranked up the meshing quality. Maybe because glass with a lot of internal reflection is just slow to resolve. I also wanted to get rid of a lot of noise, so I think in the end I went to 500 samples per pixel and it took maybe 30/45 minutes? Do note I’m using my CPU for this because if I use my AMD card with OpenCL too many other apps start to suffer. If I were rendering overnight I would absolutely use the card though.


(Nathan 'jesterKing' Letwory) #6

Note that 12 days ago I significantly bumped bounce counts for especially transparent materials:

This will result in longer render times for final quality rendering, which will be more obvious on CPU devices. But this change should give much better results with the 2000 samples in scenes with lots of glass, gem and transparent plastic materials. Your Crystals scene for instance will have far less noise in the internal reflected areas.

/Nathan


#7

Thanks David.I think the speed you get form your CPU is impressive compared to my AMD GPU using OpenCL. If i render your scene using the same settings and a small hdr image for the sky i get 400 samples in 12 min, but the image is only 1/4 the size compared to yours. Either there is room for a lot of optimisations in regards to OpenCL or my card is just too old to use cycles in Rhino. I have the feeling that under blender everything runs much faster.

c.


#8

Christ on a crutch, now i have to start rendering Air.
-seriously though is the is the air a boolean object?


(David Rutten) #9

The speed of light in air is close enough to the speed of light in a vacuum. Unless you wish to replicate atmospheric effects (temperature gradient shimmers, fog, volumetric light, mirages, physical sky domes, Bose-Einstein condensates) you can ignore the air.