So I finally tried the Envirodome a while back and liked the early results it gave.  I tried various panoramic images with a single infinite light as was recommended and planned to experiment further.

The thing I don't understand is how to determine the position (height/direction) of the sun so that it corresponds with the light source in the texture map.  Is there a formula to determine the angles for the infinite light based on the X/Y position of the light in the texture, or is this something I just have to eyeball to get right?

http://www.renderosity.com/mod/forumpro/showthread.php?message_id=3442417&ebot_calc_page#message_3442417

Note - the linked instructions talk about adjusting your lighting. My EnvSphere is now always self lit and IDL makes it part of the lighting, so ignore those things.

Thank you so much!  That is precisely the info I was looking for!

I habitually call the Environment Sphere the "Envirodome".  I don't know if that is another prop I have seen or used, but I'm unable to change the thread title. 

Will repeat the words "Environment Sphere" as I try to sleep tonight, maybe I will get it right in the future.

OT:  BB, what do you know offhand about about using lightmapped objects in Poser?  I was looking at Cartography Shop, Giles, IrrEdit a few years ago for creating environments for use in Unity or UE.  I thought lightmapped environments might have some use in Poser, but wasn't sure how to mix the environments' precalculated shadows with the figured' dynamic shadows.  My concern is that two shadows form the same light should have the same apparent effect, I wouldn't want the figure's shadow to be darker than the precalcualted shadow.  I wondered if there was some trick to blending the two I had not thought of...  I could just keep the figure out of the shadow and avoid the problem altogether...  Can't recall if I've seen light mapped environments used in Poser before, or if they would even work with more advanced lighting types such as would be used with the Environment Sphere.

I've never heard of any of those tools - light mapping is not something I've ever looked at.

So I just Googled a bit and, if I understand correctly, a light map is a baked solution of any general lighting model against a fixed, unchanging collection of props. I assume they are images constructed by doing a (simple or complex) 3D lighting solution for numerous points in the scene, and recording the offered light at each point in an image map, according to the objects UV mapping (inversed). The way you use them is to multiply the offered light (recorded in the light map) with the color of the object's color map.

This is trivial to do in Poser. You'd load a color map into an Image_Map, and the object's light map into another Image_Map. Then you'd combine these with a Color_Math:Multiply node, and run that straight into the shader's Alternate_Diffuse channel in the Poser Surface root node. You would then turn off the built-in Diffuse_Value so that Poser would not try to take into account its own lighting solution for the diffuse reflection of that object. (Alternate_Diffuse doesn't do any lighting calculation- it simply spits out whatever you plug into it. It's primary purpose is to let you select alternative implementations of diffuse light calculation (such as Clay or Scatter) and the Color_Math:Multiply with a pre-calculated light map is another example of an alternative to doing the calculations in the render.)

I can see how this would make games very fast, but, as you are mentioning, shadows cast from animated objects (or any object you added after the light maps were made) would not be included in the light map, and would in fact have no influence on the scene.

Remember, the point of the light map is to know what color every part of the light-mapped collection of props would be regardless of any lights in the scene. Based on that premise, the animated figure's shadow would not only not match, but would not appear at all.

Suppose, for example, you light-mapped a floor prop, and then you can dynamically decide what the floor covering is (wood, stone, whatever) by replacing the color map, and the Color_Math:Multiply would combine the color with the light level. This is entirely determined without running any calculations of a Poser light. Therefore, a figure standing on that floor has no influence on the appearance of the floor. If you wanted it to, you'd have to actually involve the Poser Diffuse node in the calculation, and at that point, the light map would be messed up because now you're using the rendering calculation of Firefly lighting to decide how bright the floor is. So - I don't see much point to it.

If you're just wanting to pre-calculate the lighting of an entire scene (everything), save that in light maps, and then make further artistic choices about colors and patterns without suffering another 2-hour render, that would be possible.

However, if the lighting solution involved bounced light (which you'd want to do if you're looking for realism) then any drastic changes in object colors would actually create flaws in the light map. The light map solution is only as good as the information you feed it, and if you're making a significant change in the luminance of things like walls and floors and ceilings, then the light map would be significantly wrong.

Still, recognizing that the ability to make limited post-light-mapped changes and re-render quickly has some imaginable value, I can say with some confidence that Poser can do it. And the most obvious use case would be a walk-through or fly-through of the camera in an animation, where the props don't move, but your viewpoint is constantly changing. Recalculating the lighting for each frame of an animation could be avoided by using light maps. You'd get a much faster result that way, and the results would be as good as you can make it with an arbitrarily complex calculation, but doing it with near zero cost at render time per frame.

I was thinking of a static environment with the figures in the middle, for example an old-west ghost town with the gunfighters in the center of the street (where their shadows would only be cast on the ground beneath them).  I had the idea that the objects could be light mapped, but of course would want the figures (not part of the light mapping calculation) to cast shadows.  I wondered if there could maybe be a shadow catching plane just above the light mapped ground plane to catch the figures' shadows...

Thanks for that info, if I do ever experiment with this it will come in handy.  The original idea was based around using game assets within Poser to render game cinematics, and wondering if light mapping would speed up the rendering in Poser as it is used for that in a game engine.

I think the UVs would be the main issue... As the UVs on most of my props overlap they are only suited for cast shadows.  Baked shadows would require non-overlapping UVs or multiple UV spaces (which may be what those are often used for, I don't really know).

https://sites.google.com/site/bagginsbill/free-stuff/shadow-catcher

http://www.renderosity.com/mod/forumpro/showthread.php?message_id=3881689&ebot_calc_page#message_3881689

http://www.renderosity.com/mod/forumpro/showthread.php?message_id=3847338&ebot_calc_page#message_3847338

http://www.renderosity.com/mod/forumpro/showthread.php?message_id=3282590&ebot_calc_page#message_3282590

http://www.renderosity.com/mod/forumpro/showthread.php?thread_id=2746233&page=4#message_3442423