Sub surface scattering again...

[Hannes]

Beer head! That sounds good. Thank you, Otakar.
One last beer!!
I improved the textures for the beer head and gave it a slightly warmer colour.
Enough beer.
For now...

However, as I wrote in the first beer post, rendering the beer body inside the glass makes it black. So I unchecked "visible to other rays". So far so good, the beer renders correctly. But somehow it looks different. Plus when I put the glass onto a reflective surface, everything is reflected but the glass, which is weird. Is there any other way to render this correctly without unchecking the "visible..."-thing? Remember, I tried all combinations of object/shader doublesided on or off plus cast shadows on or off for each object.
You can render thin single sided objects inside other thin single sided objects when they both have a glass shader assigned to, the TG native sphere for example, but once the objects have solid walls, it doesn't work anymore. So, any ideas, or is it just impossible at the moment?

[Hannes]

Too much alcohol...
Here's something healthy. This time I used a water shader with a warm white colour in the Volume 1 colour tab instead of a fake SSS shader.
I'm a bit confused that I could render a solid body of milk inside a solid glass this time. There are some faces that are darker, which seems to be an intersection issue. So I tried to make the milk body slightly smaller, but then the milk got darker and darker. Unchecking "Visible to other rays" of the glass object makes the milk bright again, but then the glass is black!

Think I'll cry a bit now...

[bobbystahr]

Great milk and interesting problem. Dunno why that'd happen.

[j meyer]

Mind sharing the glass and milk objects so we can
try with the same or at least showing the wireframes?
Do the objects intersect?

[Hannes]

Ok, I guess it shouldn't be a problem to share the glass. It's a free object from here:
http://archive3d.net/?a=download&id=bfab47f8#
Credits go to the maker, whoever he or she is. It's uploaded by Katrin Wagner, so if it's been her, thanks a lot!

I then created the milk body by adding a cylinder and a boolean subtraction operation. The upper surface of the milk is modified so that the rim is slightly higher than the rest.

I tried to subdivide the glass and created a new milk body, thinking that it might work better when it's more detailed, but it was even worse, so here is the original file. It works except those few faces that are kind of dark.

Btw I posted the problem in the Glass shader thread, that Matt had started.

[j meyer]

As for the transparency thing I've no idea so far,but the
artefacts you get might be due to bad geometry.
At the bottom and around the top rim of the milk there is some
really nasty geometry.Maybe caused by that boolean operation
you mentioned.Overlapping faces and edges.

[Hannes]

I can't stop. 
Cartoon cheese.
I know the holes are a bit faceted, the spheres I used for the boolean operation weren't high res enough. It's just a quick shot for fun.

[j meyer]

Played with your tgd last night and what I saw reminds me
of some transparency peculiarities that came up when I tested
the render layers/elements.
http://www.planetside.co.uk/forums/index.php/topic,18176.msg176267.html#msg176267
I assume these are related,but I might be totally wrong.

Keep experimenting!

[bobbystahr]

I can't stop. 
Cartoon cheese.
I know the holes are a bit faceted, the spheres I used for the boolean operation weren't high res enough. It's just a quick shot for fun.

Hee hee hee, cool image tho

[Matt]

Why in all that is holy would Terragen assume anything is in a arcane format like SRGB for CRT monitors? lol It should only use Native RGB/CMYK for plasma/lcd now. You'd think CMYK would work best considering the whole gamut is a natural tone set from the 'real world' and would probably work best for shading such a 'real world' image.

Because most 8-bit images, from most sources, are intended to be interpreted as sRGB. Although it's true that most monitors do a bad job of approximating sRGB.

What is "Native RGB?" Something that is system-dependent?

There is no reason to invoke CMYK when interpreting an image that is encoded with RGB channels, so I don't know what you mean there.

Also sRGB incorperates both linear, and non-linear gamma corrections leaving you with a adjustment o 2.3 at the end, not 2.2.

Gamma 2.2 is only an approximation to sRGB; I know that it's not exactly the same. However, for most rendering needs it doesn't need to be exactly right. If the final render is gamma corrected by 2.2 and the incoming texture map is corrected by 1/2.2 then the result will be the same, assuming constant lighting and no atmosphere. The same would be true if you used sRGB for both the input and output instead of gamma 2.2, and the lighting would be closer to a true linear workflow (assuming an sRGB source and output display of course), but it's not a big difference in most cases. I think the subtle difference usually gets lost quickly in any colour correction you might want to do to the final image. But I would like to experiment with this some day to really understand how big the difference is.

In the image map shader you can change the gamma correction, but in the Default Shader it (currently) assumes the default of 2.2. If you need more control you can use an image map shader in place of the default shader's built-in image handling.

Could explain a lot of the anomalies in TG with it.

Since we're being very specific here, what anomalies are you referring to?

Matt

[Seth]

That's an awesome Thread !!!

[inkydigit]

I echo Seth.... Awesome thread, beer and cheese! Outstanding stuff here!
))
J

[bobbystahr]

I echo Seth.... Awesome thread, beer and cheese! Outstanding stuff here!
))
J

Don't forget the milk...never forget the milk....hee hee hee