i wonder if this is true for poser also?  

"Subsurface scattering varies depending on the size of the objects to which it is applied"

It is.

Global Illumination: any lighting that involves more than just the surface being shaded. The strict interpolation already counts shadows as a global illumination effect, since that requires the interaction of other objects in the scene. Depending on who you ask and what software you use, global illumination may or may not include diffuse<->diffuse, specular<->diffuse or specular<->specular light transports.

Indirect diffuse light was the description we chose in FireFly to make sure it's an accurate description of what it does without raising unrealistic expectations. It calculates diffuse<->diffuse light transport through path tracing and irradiance caching (which can be turned off), but does not calculate caustic light paths which would require light transport through specular paths.

You can play with the falloff settings of the light. Inverse linear or inverse square mode should make the effect close to the light source much stronger.

There is support for the new Kinect for Windows in Poser Pro 2014 Game Dev [b]SR5[/b]. Be aware though that Microsoft's SDK for the new Kinect is not finalized yet.

This is what I suspect a driver problem. A workaround for this is in the works and will hopefully be included in a future Poser release or updater. To my knowledge, this will be fixed once OS X Yosemite is released. Until then, turning off shadow maps in the OpenGL preview should fix it.

Quote - This is a problem if we're looking to emulate a photograph using Firefly. Camera's have very limited exposure ranges so they have to reduce the contrast by elevating the lower range with artifical lighting or use HDR. I don't know what Poser's Firefly engine effective EV range but it must have one.

Check "HDRI optimized output", save the image as .HDR or .EXR and the dynamic range is, for all pracitcal purposes, unlimited. You can then take that .HDR/.EXR into a capable image editing program and adjust the exposure to how you like, it, apply tone curves, compress highlights, or treat it like you would treat an HDR created by a digital camera and multiple exposures.

(edit: http://http.developer.nvidia.com/GPUGems/gpugems_ch26.html says "A range of one-million to one is 20 stops in photographic terms." and that OpenEXR's floating point representation "is a dynamic range of a trillion to one.").

No cones, no cube. This is just Andy, the ground plane and one spotlight.

You can plug 3d textures into the Atmosphere node's density input for all kinds of effects.

Pixel samples do much ore than just Antialiasing. I can't post images right now (I'm at siggraph), but if you try any scene with depth of field at different settings for pixel samples, you should see the difference right away. 

Motion blur is important for movie renders too and is a "must have" feature for any render engine in the movie industry. Film and video cameras in real life also show motion blur, so movie renderers try to match that look.

When you render with strong depth of field or motion blur, those high sampling numbers may become necessary - if you're not using those features, then high numbers are certainly not required.

Since FireFly is decoupling shading and visibiilty*, antialiasing comes in comparably cheap and in doubling the number of samples will not automatically double the render time, as opposed to a ray tracer it does not need to do any extra shading.

*exception: progressive mode, then FireFly runs as a 100% ray tracer.

Quote - As far as I understand, this is the AntiAlias setting. 1 means 1x1 AA, 4 means 2x2 AA and the ultimate 36 means 6x6 AA.

Actually, setting pixel samples to 36 results in 36*36 = 1296 AA samples. It's not obvious from the dialog, the number you type is the number of sample steps on the x and on the y axis.

Quote - Do you find the progressive render options use a fair amount more resources?

It will use less memory, but in most cases more time/CPU. It's doing everything by brute force ray tracing, so there is no irradiance or occlusion cache, no dicing into micropolygon grids, no shadow maps, etc. Hence there are no options for those features, as they're not needed. IDL is calculated with naive path tracing, so the quality of IDL depends directly on the number of primary rays (= pixel samples * pixel samples).

Half - given that the vast majority of textures used are 8bit/channel anyway, this already more precision than most people need. Do you have a case where you would need 32bit/channel float?