Quote - > Quote - I have no idea why I'm getting that ring on the floor

Is the floor one huge polygon or many small ones?

It's just the regular ground prop from Poser odf :o).

Laurie

Just checking if it could have anything to do with bad normals. Probably not if it's the ground prop.

I've seen similar rings with converted point lights. My guess would be that it's not an exporter problem, but some kind of computational artifact within Lux.

Rendered 50 minutes, 2500 samples.

Sun+Sky light only.

small pic but great job so far, bb :)

Beautiful location shot.

Quote - ]not if they will look at the gallery on the official site from Luxrender.

if 90% posts are about realism and if someone ask if he can render stylized renders then he needs a slap.

Poser's firefly render engine is good enough for stylized renders. for realism we will use Lux.

People will still complain even after looking at that gallery & failing miserably to get anything like those results by loading it up with the default settings & hitting render.

It happens every time we get a new version of Poser too, the testers post wonderful pictures that are so far advanced that your average user has no hope of getting the same results straight out of the box & the complaints flood in.

I have to get round to reading some of the info posted around here as I have no idea how to set up the sun & sky light.

here's a sunsky snippet you can try.  i forget who posted it first but thank you whoever you are.

start lights

start light "Light 1"

AttributeBegin
LightSource "sunsky" "integer nsamples" [1]
        "vector sundir" [0.70000 0.400000 0.800000]
        "color L" [1.000000 1.000000 1.000000]
        "float turbidity" [2.000000]
        "float aconst" [0.500000] "float bconst" [0.500000] "float cconst" [1.000000] "float dconst" [1.000000] "float econst" [1.000000]
        "float relsize" [2.000000]
AttributeEnd

end light "Light 1"

end lights

Thanks, I'm off to Windows now for a test. :D

Quote - Ok, here is my favorite nekkid standin (yet again...sorry ;o)).

The particulars are on the image.

I have no idea why I'm getting that ring on the floor and there are still a few blank pixels, but overall, I'm satisfied with the skin. At least she's not shiny...lol.

This particular skin does have a bunch of burned in highlights, but I only have two and it's the lesser of two evils. The Daz texture is horrible ;o).

Laurie

Laurie,

Excellent image.

Thanks for the LuxRender settings you used. If you still have the scene could you please post your Poser light settings prior to export?

Until we get some 'official' test secenes I am trying to recreate this image and it would greatly help me get a handle on how the exporter treats Poser lights.

Many thanks.

The front point light was scaled to 500% in size. The brightness on the front light is 200%. For the rear light (which is exactly opposite to the front in coordinates) it's the same size in scale (500%) but it's only at 5% brightness. I just wanted to fill in the shadow so that it wasn't so dark.

That's pretty much it :o).

Laurie

Quote - here's a sunsky snippet you can try.  i forget who posted it first but thank you whoever you are.

start lights

start light "Light 1"

AttributeBegin
LightSource "sunsky" "integer nsamples" [1]
        "vector sundir" [0.70000 0.400000 0.800000]
        "color L" [1.000000 1.000000 1.000000]
        "float turbidity" [2.000000]
        "float aconst" [0.500000] "float bconst" [0.500000] "float cconst" [1.000000] "float dconst" [1.000000] "float econst" [1.000000]
        "float relsize" [2.000000]
AttributeEnd

end light "Light 1"

end lights

This will transition the sun (X,Y,Z)"vector sundir" [0.70000 0.400000 0.800000]
Note: Z is UpDown and Y is PanZoom

This link to LuxRender shopuld help explain these settings a little better for you.
http://www.luxrender.net/v/manual_lighting
Scroll Down to  "Environment lights","Physical Sun Light" and "Physical Sky Light".

Quote - I just wanted to fill in the shadow so that it wasn't so dark.

Aahh, still thinking like a Poser user :)
Create a box instead so the light can bounce around.

Quote - > Quote - I just wanted to fill in the shadow so that it wasn't so dark.

Aahh, still thinking like a Poser user :)
Create a box instead so the light can bounce around.

Well, since photographers use fill lights and special reflectors all the time, it can't be that Poser-specific, huh? :laugh:

 :lol:

Quote - > Quote - I just wanted to fill in the shadow so that it wasn't so dark.

Aahh, still thinking like a Poser user :)
Create a box instead so the light can bounce around.

Probably. I've been using Poser for about 12 years and Luxrender for about 3 weeks.

Laurie

Quote - Well, since photographers use fill lights and special reflectors all the time, it can't be that Poser-specific, huh? :laugh:

If you're thinking you will get the same results in Poser, then good luck with that!

RE:Additional parameters called aconst, bconst, cconst, dconst, econst allow you to fine tune the color of the sky to simulate various atmospheric conditions.

Does anyone have and insight on what these relate to colorwise?
i.e RGB etc etc...................?
I could try numerous combinations to come up with conclusions.
Just seems easier for all, if someone has sorted this out.

Thanks
 

Quote - The front point light was scaled to 500% in size. The brightness on the front light is 200%. For the rear light (which is exactly opposite to the front in coordinates) it's the same size in scale (500%) but it's only at 5% brightness. I just wanted to fill in the shadow so that it wasn't so dark.

That's pretty much it :o).

Laurie

Thanks, time to experiment a bit more :)

Quote - RE:Additional parameters called aconst, bconst, cconst, dconst, econst allow you to fine tune the color of the sky to simulate various atmospheric conditions.

Does anyone have and insight on what these relate to colorwise?
i.e RGB etc etc...................?
I could try numerous combinations to come up with conclusions.
Just seems easier for all, if someone has sorted this out.

Thanks
 

I can only find really abstract info on this. It is an implementation of the "Perez All-Weather Sky Model". This model is not actually based on physics, but is an empirical model. Empirical means "we are able to imitate a real phenomenon to a pretty good degree even though the math we're using has nothing whatsoever to do with how the phenomenon actually happens."

I don't know why Lux, which is in all other ways physically based, uses this empirical model instead of a physical one. It is old - was published in 1993.

As with many empirical models, there are a bunch of constants that have very little to do with any sort of intuitive understanding of what to do with them. We have six; a, b, c, d, e, and turbidity. Of these, only turbidity has any sort of intuitive value. The others are used as follows:

sky pixel luminance = [1 + a * exp(b / cos theta)] * [1 + c * exp(d * gamma) + e cos^2 gamma]

where theta is the zenith angle of the sky pixel being rendered and gamma is the angle between the sky pixel and the sun.

Does this help? Not even me. And it doesn't even begin to explain how colors are produced - it only talks about luminance.

When I have time, I will experiment with these coefficients and supply a bunch of named presets. Eventually I may come to understand what they actually do instead of randomly trying them and construct some simpler UI in front of these six values. Something that would let you use buttons like "more/less blue, red, or yellow", "more/less hazy", "more/less variation from straight up to horizon", etc.

The sun-sky system is similiar to the one in Yafaray, so you can use that as a guide.

aconst: Horizon brightness
bconst: Luminance of gradient near the horizon
cconst: Sun brightness
dconst: Sun size
econst: Backscattered light

http://www.yafaray.org/documentation/userguide/backgrounds#sunsky

Here's another of my quick test renders, this time I used the Daz Troll, the RDNA IBL Cove & a Single Point light, I left it to soak for 3hrs & 48 mins.

No Postwork whatsoever as it's against my religion.

ps I forgot to take down any of the settings that I used & how many s/px it got to.

If you want to have several projects on the go at once here is what I rename to keep order.

Open the .lxs file in the text editor of your choice.

Rename "poserscene_alphax.xx" in "string filename" ["poserscene_alphax.xx"] to "your file name" . This changes the name of the output png.

Scroll to the bottom and change -  Include "poserscene_alpha x.xx.lxm"  to Include "your file name.lxm"
Repeat for Include .lxo and .lxl.
Save the file.

Now change the name of all 4 files in the toLux folder to your file name.

Choose your file from LuxRender by name and render away.

Attached is a copy of the files in my toLux folder with two projects on the go.

Does everyone know how to save the 'flm' file so you can open it again and resume rendering or will I be teaching people to suck eggs here?

I do know how to save .flm files, but I don't know how to suck eggs.  Might be interesting.  :lol:

 I really wish I knew what I was doing wrong.... I get rid of all of the relative paths in the lxm file and make them constants. I make sure that all the paths are correct to images... I try to run it in LuxRender and it crashes... I live all the relative paths, I get errors in LuxRender but it still runs and renders fine on one machine, even though from what I am told it should have problems rendering correctly. I seem to be the only one having this problem. I'm running Windows 7, Poser 8, LuxPose 1.14, and LuxRender v0.7... It doesn't crash if I comment out the lxm file, but then of course everything is a nice shade of gray.

I do get errors like this in the LuxRender Log window:

[2010-09-02 14:01:43 Error: 14] Static loading of color texture 'default' failed.
[2010-09-02 14:01:43 Error: 41] Couldn't find color texture named 'Color_Round'

[2010-09-02 14:01:43 Error: 41] Couldn't find float texture named 'Color_Mul_74'

and the last thing it says before crashing is:

[2010-09-02 14:03:21 Warning: 0] Parameter 'from' not used

[2010-09-02 14:03:21 Warning: 0] Parameter 'to' not used

Then I get a popup window saying:

Runtime Error!

Program: C:Program Files LuxRenderluxrender.exe

This application has requested the Runtime to terminate it in an unusual way. Please Contact the application's support team for more information. 

I have tried running the sample that comes with Luxrender and that goes through fine without any trouble. So I don't know what I am doing wrong that is causing so much trouble. I have been in contact with a couple of the people working on  this project and the LuxRender Devs, and both have told me that it is a problem with relative paths vs constant paths, but that doesn't make sense since I have taken out all of the relative paths. And it is not just one scene that I have tried, it's all the of the scenes I have made and tried to move over to LuxRender.

Quote - I do know how to save .flm files, but I don't know how to suck eggs.  Might be interesting.  :lol:

I tell you what - give it a go, take a picture and post it. Now that would be interesting  :lol:

Apologies if I was covering old ground with my post above.

Quote - We have six; a, b, c, d, e, and turbidity. Of these, only turbidity has any sort of intuitive value. The others are used as follows:

sky pixel luminance = [1 + a * exp(b / cos theta)] * [1 + c * exp(d * gamma) + e cos^2 gamma]

where theta is the zenith angle of the sky pixel being rendered and gamma is the angle between the sky pixel and the sun.

Does this help? Not even me. And it doesn't even begin to explain how colors are produced - it only talks about luminance.

The code in the Lux file Sky.cpp has this model applied three times in SkyLight::SkyLight to calculate zenith_x, zenith_y, and zenith_z.
As the turbidity is involved along with a bunch of unexplained constants*, could these be the colour component values ?

• Which match those given in the appendix of this paper -> http://www.cs.utah.edu/~shirley/papers/sunsky/sunsky.pdf

Quote - > Quote - I do know how to save .flm files, but I don't know how to suck eggs.  Might be interesting.  :lol:

I tell you what - give it a go, take a picture and post it. Now that would be interesting  :lol:

Apologies if I was covering old ground with my post above.

No apologies needed,  I was just fooling around.   To answer the other part, I had not seen that posted before, so it is helpful and most welcomed.

Quote -  I really wish I knew what I was doing wrong.... I get rid of all of the relative paths in the lxm file and make them constants. I make sure that all the paths are correct to images... I try to run it in LuxRender and it crashes... I live all the relative paths, I get errors in LuxRender but it still runs and renders fine on one machine, even though from what I am told it should have problems rendering correctly. I seem to be the only one having this problem. I'm running Windows 7, Poser 8, LuxPose 1.14, and LuxRender v0.7... It doesn't crash if I comment out the lxm file, but then of course everything is a nice shade of gray.

I do get errors like this in the LuxRender Log window:

[2010-09-02 14:01:43 Error: 14] Static loading of color texture 'default' failed.
[2010-09-02 14:01:43 Error: 41] Couldn't find color texture named 'Color_Round'[2010-09-02 14:01:43 Error: 41] Couldn't find float texture named 'Color_Mul_74'

and the last thing it says before crashing is:

[2010-09-02 14:03:21 Warning: 0] Parameter 'from' not used

 

[2010-09-02 14:03:21 Warning: 0] Parameter 'to' not used

Then I get a popup window saying:

Runtime Error!

Program: C:Program Files LuxRenderluxrender.exe

This application has requested the Runtime to terminate it in an unusual way. Please Contact the application's support team for more information. 

I have tried running the sample that comes with Luxrender and that goes through fine without any trouble. So I don't know what I am doing wrong that is causing so much trouble. I have been in contact with a couple of the people working on  this project and the LuxRender Devs, and both have told me that it is a problem with relative paths vs constant paths, but that doesn't make sense since I have taken out all of the relative paths. And it is not just one scene that I have tried, it's all the of the scenes I have made and tried to move over to LuxRender.

The errors about 'from' and 'to' seem to be normal.  Though it does not seem to prevent luxrender from working.

OTOH, the other errors make me think you are using Poser Materials, which do not work with LuxPose yet.  I don't know if that has anything to do with the 'Runtime error', though I would think not. 

This is a very beginning work-in-progress, and as such does not have the ability to convert much more than Poser 4 textures.  That is changing, and probably will change rapidly soon.

Don't give up, it's only getting better!  In other words, try a simple scene with just image-based textures and see what happens.

Quote -
If you want to have several projects on the go at once here is what I rename to keep order.

  It's easier to add the following code to PoserLuxExporter.py, to get asked to choose the filename:

search for globalparm["filename"] = filename = "poserscene_%s" % version

Add the following two lines after that (make sure the blanks before the text are the same number as the line before): dlg=poser.DialogTextEntry(None, "Enter filename (without extension, cancel for default)") if dlg.Show(): filename=dlg.Text()

Quote -
I do get errors like this in the LuxRender Log window:

[2010-09-02 14:01:43 Error: 14] Static loading of color texture 'default' failed.
[2010-09-02 14:01:43 Error: 41] Couldn't find color texture named 'Color_Round' [2010-09-02 14:01:43 Error: 41] Couldn't find float texture named 'Color_Mul_74'

this is "normal". These are textures that couldn't be exported at the moment (texture here does not mean: "image", but a shader-setup).

Quote -
and the last thing it says before crashing is:

[2010-09-02 14:03:21 Warning: 0] Parameter 'from' not used  

[2010-09-02 14:03:21 Warning: 0] Parameter 'to' not used

This parameters are from light. with certain lighttypes "from" and "to" is not required. So the log message it's just a hint.

Quote -
Then I get a popup window saying:
 Runtime Error!

Program: C:Program Files LuxRenderluxrender.exe

This application has requested the Runtime to terminate it in an unusual way. Please Contact the application's support team for more information. 

I have tried running the sample that comes with Luxrender and that goes through fine without any trouble. So I don't know what I am doing wrong that is causing so much trouble. I have been in contact with a couple of the people working on  this project and the LuxRender Devs, and both have told me that it is a problem with relative paths vs constant paths, but that doesn't make sense since I have taken out all of the relative paths. And it is not just one scene that I have tried, it's all the of the scenes I have made and tried to move over to LuxRender.
 

Do you use IBL for your scenes? If yes, check the images used. You problably  have to convert them to OFX-format. I also had some crashes for this reason. Some seems to work in Lux, other may need conversion.
For the first test I would check a scene and turn off all IBL light. Or, just to be sure, switch all light off but one. Make this a pointlight, move it high above your scene, raise the size of the light to 500% and intensity to 100%. Raising the size of a pointlight makes no sense in Poser; but the converter makes it an arealight and the size of the pointlight is the size of the resulting "light-source" in Lux. If this exports and renders fine, just the light/IBL is the reason for your crashes.

Another possiblility is you have the wrong Lux Version for your processor type. Or try one of the weekly builds. The latest seems to have a few fixes.

Quote - > Quote -

If you want to have several projects on the go at once here is what I rename to keep order.

  It's easier to add the following code to PoserLuxExporter.py, to get asked to choose the filename:

search for globalparm["filename"] = filename = "poserscene_%s" % version

Add the following two lines after that (make sure the blanks before the text are the same number as the line before): dlg=poser.DialogTextEntry(None, "Enter filename (without extension, cancel for default)") if dlg.Show(): filename=dlg.Text()

I am sure all this will become redundant as the GUI gets released but for now I thank you for this, most useful.

Quote - RE:Additional parameters called aconst, bconst, cconst, dconst, econst allow you to fine tune the color of the sky to simulate various atmospheric conditions.

Does anyone have and insight on what these relate to colorwise?
i.e RGB etc etc...................?
I could try numerous combinations to come up with conclusions.
Just seems easier for all, if someone has sorted this out.

Didn't try it yet, but a part from the wiki says:

rgb

When using an rgb colour as input, LuxRender will generate a physically plausible spectrum based on the desired colour. The implementation is based on a paper by Brian Smits.

Quote - Runtime Error!

Program: C:Program Files LuxRenderluxrender.exe

This application has requested the Runtime to terminate it in an unusual way. Please Contact the application's support team for more information. 

As ADP001 said, check for IBL in the scene. The only time I have ever had that error was due to IBL. I just deleted it from the .lxl file to save having to re-export everything.

Disco balls! :o) That looks groovy, man...lol.

Laurie

My mother has a snow globe very much like that.  Smooth is not always better.

Can pleases someone download the updated version and check for any errors?
I have added some more to the GUI. A filename can now be set here, also a "projectpath".

Additionally I check each Image if it really exist. If not, the script tries to add the Applicationpath (poserpath) to the filename and checks this too. This does not work with external libraries.

Poser 8/2010: At the very start Poser is asked to "resolve pending textures".

All this costs some seconds (the script shows time needed for different parts of the script). Please tell me if I should discard the image testing.

ADP, I tried the output path you added to the GUI in version 13 or 14 and that works perfectly for me, it's exactly what I'm looking for.

Personally I don't need an image check at the start, I just put a soft to my Runtime in the LuxPose folder, that works perfectly, it finds all the textures, even if they've got a relative path.

It is working for me also on Poser Pro 2010.

What i do wish for in Luxrender, is a way to easily see what rendering algorthm is actually being used.  I may have got that confused with something else, but I see that Luxrender defaults to Metropolis, though it supports other methods.  I chose a different method in the Luxpose GUI, exported, and did a render.  I didn't see anything different.  Is there something i am missing?

You can confirm the algorithm being used by looking in the .lxs file.

Quote - It is working for me also on Poser Pro 2010.

What i do wish for in Luxrender, is a way to easily see what rendering algorthm is actually being used.  I may have got that confused with something else, but I see that Luxrender defaults to Metropolis, though it supports other methods.  I chose a different method in the Luxpose GUI, exported, and did a render.  I didn't see anything different.  Is there something i am missing?

The Sampler (Metropolis) has less impact than the Integrator (Bidirectional, etc.).

In theory, all of these should produce the same or very similar final outcome, except for the "Direct Lighting" integrator which doesn't do global illumination (bounced light). They differ in how fast they will converge to the "correct" image in different situations.

adp, what's the best way, to tell you about bugs? I see the bugs I posted (with fixes) not fixed version after version... So I guess you miss them...

 The texture resolving code does not work, as it is "poser.Scene().ResolvePendingTextures()" and not "poser..ResolvePendingTextures()".

Would be nice, if you had a look at my texture resolving code, as it works for Poser 6 (with a little trick), too. (See here.)

And could you please include the code for the camera fov? :-)

lines 683 of PoserLuxExporter_workers.py uses "p.get" instead of "gp.get"

workersPoserLuxExporter_workers.py", line 244, in getImage
if node.Type() != poser.kNodeTypeCodeIMAGEMAP : return None
AttributeError: 'NoneType' object has no attribute 'Type'

Please change the line to "if not node or node.Type() != poser.kNodeTypeCodeIMAGEMAP : return None".

Quote - You can confirm the algorithm being used by looking in the .lxs file.

Yea, I know.  I guess it was something that I wish the Luxrender GUI showed, that so I wouldn't have to view the file separately.  I am new to unbiased rendering, so also new to Lux and did not know if there was supposed to be different options based on what choice you made.  I see now that there isn't any different options.  I did figure that each should end up at the same destination, just that they would take a different route.

Hrm... here's a side-project for somebody, someday...  As is typical of Poser's dynamic hair, it doesn't convert to .obj format correctly - the lines become planes:

 ---> 
 (Don't mind the camera and mats being off, I changed both after I made the Poser render.  Also, the Lux render was only an hour in the making, hence the noise)

 Blender supports hair, LuxBlend will export it, and Lux will render it.  I've had reasonable success before, hand-editing .objs and .hr2's to get dynamic hair both out of and into Poser from Lightwave (the latter is pretty unstable, I've never shared the idea with anyone because it's really unpredictable on a case-by-case basis, whether it'll work, grow weird, or just crash Poser), so I've wrangled with it between programs before.  Perhaps you/I/we/somebody should take a look at what Lux does with hair.

   I found a hair tutorial for Blender, and managed to grow some on a cube.  This is the Lux export output:

ObjectBegin "Cube:PSys:luxHairPrimitive:joint"<br></br>
NamedMaterial "Material.001"<br></br>
Shape "sphere" "float radius" 0.000798<br></br>
ObjectEnd # Cube:PSys:luxHairPrimitive:joint<br></br><br></br>
ObjectBegin "Cube:PSys:luxHairPrimitive:leg"<br></br>
NamedMaterial "Material.001"<br></br>
Shape "cylinder" "float radius" 0.000798
"float zmin" 0.0 "float zmax" 1.0<br></br>
ObjectEnd # Cube:PSys:luxHairPrimitive:leg<br></br><br></br><br></br>

The "sphere" and "cylinder" are the actual geometries of the joints and the segments of each hair, I think?  Continuing:

<br></br>
AttributeBegin #
Cube:PSys:luxHairPrimitive:joint_strand0_segment0<br></br>
Transform [1.0 0.0 0.0 0.0 0.0 1.0 0.0 0.0 0.0 0.0 1.0 0.0
0.397011786699295040 0.031038329005241394 -1.000000119209289600
1.0]<br></br>
ObjectInstance "Cube:PSys:luxHairPrimitive:joint"<br></br>
AttributeEnd<br></br><br></br>
AttributeBegin #
Cube:PSys:luxHairPrimitive:leg_strand0_segment1<br></br>
Transform [1.0 0.0 0.0 0.0 0.0 -1.0 0.0 0.0 0.0 0.0
-0.036066532135009766 0.0 0.397011786699295040 0.031038329005241394
-1.000000119209289600 1.0]<br></br>
ObjectInstance "Cube:PSys:luxHairPrimitive:leg"<br></br>
AttributeEnd<br></br><br></br>
AttributeBegin #
Cube:PSys:luxHairPrimitive:joint_strand0_segment2<br></br>
Transform [1.0 0.0 0.0 0.0 0.0 1.0 0.0 0.0 0.0 0.0 1.0 0.0
0.397011786699295040 0.031038329005241394 -1.036066651344299300
1.0]<br></br>
ObjectInstance "Cube:PSys:luxHairPrimitive:joint"<br></br>
AttributeEnd<br></br><br></br>
AttributeBegin #
Cube:PSys:luxHairPrimitive:leg_strand0_segment3<br></br>
Transform [1.0 0.0 0.0 0.0 0.0 -1.0 0.0 0.0 0.0 0.0
-0.026456236839294434 0.0 0.397011786699295040 0.031038329005241394
-1.036066651344299300 1.0]<br></br>
ObjectInstance "Cube:PSys:luxHairPrimitive:leg"<br></br>
 AttributeEnd<br></br><br></br>

And so on, continuing to the end of that one hair (this one has 16 segments).  Then it goes on to joint_strand1_segment1.  I'm not sure if these are guide hairs, or individual hairs.  That aside, any hair reference would have to be divided up between each point, and listed one at a time.  This looks like it could get... huge.  o.0  Is this even feasible?

Meanwhile, I'm gonna see if there's documentation for hair...

Quote - Trying to make a snowglobe, looks like the dome does not have enough polygons for a smooth surface. Interesting effect though. ;)

I don't know if it's has been discussed, but according to what I read and tested, glass geometry must have real thickness, let's say in you picture, create the geometry for the glass dome with thickness, then create another inner dome geometry, this one solid, for the water, with it's corresponding IOR each one, for water doesn't work the usual plane, an scaled cube works better, for glass in windows, cars and glasses the geomtry must have correct thickness. You guys with way better systems than me should confirm this :-)

you dont need to do that

Updated 1.15a

I left the code for checking images out. In folder "utilities" dizies script is contained for folks who have a need. This should be changed in the wiki.

If someone wants to send me fixes or extensions, change the file in question and mark the changes. Then send this via mail to luxpose@poserprofis.de (Attention: rigorous working SPAM-filter in action. So please use a non-anonymus mailprovider).

@dizzi:
What did I miss about the fov?

Quote - > Quote - Trying to make a snowglobe, looks like the dome does not have enough polygons for a smooth surface. Interesting effect though. ;)

I don't know if it's has been discussed, but according to what I read and tested, glass geometry must have real thickness, let's say in you picture, create the geometry for the glass dome with thickness, then create another inner dome geometry, this one solid, for the water, with it's corresponding IOR each one, for water doesn't work the usual plane, an scaled cube works better, for glass in windows, cars and glasses the geomtry must have correct thickness. You guys with way better systems than me should confirm this :-)

Just set the "architectual" flag if your glass has no thickness. Not so good, but useable.

Here is a statement from the Lux-Forum:

PowStudios3 wrote:ps. If you can answer: what is the effect of using a single-surface mesh with that glass at the moment?

You'll get slightly too much light coming through, and you won't have reflections on the side opposite to the normal. So if the normal is pointing towards you it should not be a big deal.

Jeanphi

And here is a discussion about the newer "glass2":

http://www.luxrender.net/forum/viewtopic.php?f=36&t=3767

Quote -
And so on, continuing to the end of that one hair (this one has 16 segments).  Then it goes on to joint_strand1_segment1.  I'm not sure if these are guide hairs, or individual hairs.  That aside, any hair reference would have to be divided up between each point, and listed one at a time.  This looks like it could get... huge.  o.0  Is this even feasible?

Meanwhile, I'm gonna see if there's documentation for hair...

Didn't somebody say with the right setting in Poser dynamic hair get exported? (sorry, I don't use dyn Hair with Poser).