one thing I've noticed about the exporter (and it may just be the settings I have).. it doesn't take the viewport position into account  like if I zoom in closer on things, when I render in lux, it's zoomed out again

Are you using the main camera in Poser?  That is the camera captured by the exporter.  Also, check your render dimensions in Poser, the exporter will pick that up as well.

yes, I am, and the dimensions in poser and the dimensions in lux are identical.. but lux is "zoomed out" and poser is "zoomed in"

Poser View
Lux View

(BTW, that's only like 2 mins of rendering time)

just out of curiosity, what S/px are you guys getting when the render is "done"

Quote - just out of curiosity, what S/px are you guys getting when the render is "done"

for me, I'm averaging like 12-35s/px  I've seen it as high as 305, and I've seen it as low as 2

Quote - yes, I am, and the dimensions in poser and the dimensions in lux are identical.. but lux is "zoomed out" and poser is "zoomed in"

Poser View
Lux View

(BTW, that's only like 2 mins of rendering time)

Same here.

Laurie

so basically, it seems like while it's using the "main camera" it's setting the main camera to it's default position and not taking into account the viewport..  one way to partially get around this is to adjust the focal/perspective of the camera to zoom in (like I set it to 75mm rather than 35mm and it's alot closer on the export)

Quote - rty - I may be not reading your correctly, but it seems like you're giving instructions in what is desired, when I'm trying to explain that I already did that.

No, I know you have this sorted out. Actually I was (kind of) answering to odf, and even more to all people who still try to think in Poser categories; Those categories don't apply here.

Quote - Also, I found this tidbit in the lux thread you linked to. Thanks for the link.

Quote - Also note that if you set the power or the efficiency to 0, then the normalization is disabled and the light intensity per unit surface area will be the same whatever the size of the object.

Yes, that's why I insisted you people read it. It makes additional a "fix" unnecessary.

Quote - Is there a way to set the sun's brilliance?

Well, in real life there isn't, but in Lux you can always change the gain in the Lightgroup tab.

Alternatively, and that's the best (most realistic) solution, I'd suggest to use Linear, and play with the settings of sensibility, aperture and shutter speed, till you get something you like.

(Note the histogram which helps; The brightest parts of the picture should touch the right line.)

Quote - Are you using the main camera in Poser?  That is the camera captured by the exporter.  Also, check your render dimensions in Poser, the exporter will pick that up as well.

Actuallyu no.
Qualify that: Not in my case.

I have an image where the top part is lopped off in the LuxRender.
In another image I posted on my Deviant Art page,  Poser's Main Camera was at 95mm and the LuxRender came out at 75mm.

This is straight set scene in Poser, run the Export Script and the LuxRender.

 S/px depends on how long you let it go, my current render is at 40 S/px after 30 minutes.

And I've got the same problem as Laurie and LuckDragon, the view in Luxrender is zoomed out from what I've got in my Poser viewport.
I just zoom in my Poser view by about 20% and then it looks like I want it in Luxrender, but it's annoying, it's a bit of trial and error to get it just right.

speaking of lightgroups, you should modify the exporter so that it creates a lightgroup for each light so you can adjust them individually in lux..

like:
(original)

start light "Light 8"

AttributeBegin
LightSource "spot"
 "color L" [0.960753798485 0.839215695858 0.752925932407 ]
 "float gain" [0.449999988079]
 "point from" [0.0 0.739000022411 0.622799992561 ]
 "point to" [0.0 0.739000022411 -0.377200007439 ]
 "float coneangle" [70.0]
 "float conedeltaangle" [70.0]
AttributeEnd

(proposed)

start light "Light 8"

AttributeBegin
LightGroup "Light 8"
LightSource "spot"
 "color L" [0.960753798485 0.839215695858 0.752925932407 ]
 "float gain" [0.449999988079]
 "point from" [0.0 0.739000022411 0.622799992561 ]
 "point to" [0.0 0.739000022411 -0.377200007439 ]
 "float coneangle" [70.0]
 "float conedeltaangle" [70.0]
AttributeEnd

Quote - ok, I "slapped something together".. let me know what you think :)

I don't have much information about this yet (haven't read through the forum, just found out about it yesterday)

Possible Site Layout

Thanks, the layout looks pretty good for something 'slapped together'. :)

Here is one of the test scenes, first as rendered in Poser (2 point lights, one textured plane and two black spheres, one with reflection, both with specular).

Problems:

1. Camera angle is off (already mentioned).
   2. Texture was resized, this setting didn't follow (guess it's on the todo list)
2. The little highlight has transformed in to a highly glossy setting (notice the reflection). In this case it doesn't matter, but we need a way to control this, lest lightly shiny clothes (silk) transform into vinyl and polished latex...
3. Missing material nodes (yes, I know, they're on the todo list).

Some other problems I noticed (won't post all the pics):

1. Should displacement work? Apparently it doesn't.
2. We need to be able to plug something into Blinn. I use it all the time, for hair and stuff, and in Lux this transforms hair into car paint...  :-D
   Okay, I admit this isn't a top priority, but I'd consider it as important nevertheless.

(BTW, disregard the strange ring under the point lights, that's just maxwell I forgot to change to gaussian).

Quote - ok, I "slapped something together".. let me know what you think :)

I don't have much information about this yet (haven't read through the forum, just found out about it yesterday)

Possible Site Layout

Looks good, but the problem will rather be to keep it updated, hosted and relevant, not so much to find a nice look.
People will hesitate to go to yet another site, especially if the latest news, tips and tricks are to be found here, in the forums. If there isn't somebody who keeps this updated at least daily, it will be just a waste of electrons.

(And no, I don't volunteer, I don't have the time)

Quote -  S/px depends on how long you let it go, my current render is at 40 S/px after 30 minutes.

And I've got the same problem as Laurie and LuckDragon, the view in Luxrender is zoomed out from what I've got in my Poser viewport.
I just zoom in my Poser view by about 20% and then it looks like I want it in Luxrender, but it's annoying, it's a bit of trial and error to get it just right.

Just a quick question.  Does this happen even if you use LuxPose and tell it to use the same setting?  I just tried a quick test, and it seems if I set the fov to the same as Poser, it seems to work.  Otherwise it gets set to 75. 

Quote - > Quote -  S/px depends on how long you let it go, my current render is at 40 S/px after 30 minutes.

And I've got the same problem as Laurie and LuckDragon, the view in Luxrender is zoomed out from what I've got in my Poser viewport.
I just zoom in my Poser view by about 20% and then it looks like I want it in Luxrender, but it's annoying, it's a bit of trial and error to get it just right.

Just a quick question.  Does this happen even if you use LuxPose and tell it to use the same setting?  I just tried a quick test, and it seems if I set the fov to the same as Poser, it seems to work.  Otherwise it gets set to 75. 

I tried that though and it didn't work for me :(

Laurie

Quote - > Quote - ok, I "slapped something together".. let me know what you think :)

I don't have much information about this yet (haven't read through the forum, just found out about it yesterday)

Possible Site Layout

Looks good, but the problem will rather be to keep it updated, hosted and relevant, not so much to find a nice look.
People will hesitate to go to yet another site, especially if the latest news, tips and tricks are to be found here, in the forums. If there isn't somebody who keeps this updated at least daily, it will be just a waste of electrons.

(And no, I don't volunteer, I don't have the time)

like I said.. it's what I do for a living :P  I have 5 servers, so hosting it wouldn't be an issue :)

Quote - > Quote - just out of curiosity, what S/px are you guys getting when the render is "done"

for me, I'm averaging like 12-35s/px  I've seen it as high as 305, and I've seen it as low as 2

There are several pieces of information given in the status bar: To the left you have the current render speed (in samples/second) and the average speed, then you have the resolution reached (in Samples/Pixel), and on the right you have two composite values: Efficiency being the efficiency of the raytracing (low efficiency means you probably should change settings), and the last one (EV) is Exposure Value, a value useful for photographers.

I guess the OP meant the definition (in Samples/Pixel, which is the values which tells how much information each pixel has accumulated) of the picture you tend to consider to be "finished", and I guess you meant the speed (Samples/second): At 2 Samples/Pixel your picture would still be a crude mosaic with most pixels still black (since they didn't get any valid sample yet).
But even then, that value seems extremely low: I render right now at 13300 Samples/Second, and that's on an old Athlon XP.
What did you mean?

BTW, to answer to the OP, I start considering stopping a render when it reaches over 200 S/px (the more, the merrier). What I do, is zoom in (you all know Lux has a zoom feature, don't you) and check for noise and spots which need some more cooking; If there aren't any, I stop it.

Lux Render - was having some issues with the lighting, I'll end up redoing this one -
45 minutes

Poser - Firefly

Quote - like I said.. it's what I do for a living :P  I have 5 servers, so hosting it wouldn't be an issue :)

Hosting is not the problem; I'm pretty sure 90% of people here can host it. The problem is updating it daily. Like, adding endless lists of tips and tricks, compiling buglists and to-do lists, making sure all information on the site is still valid...
I understood you do this for a living, but given you won't make a living from doing this, do you have that kind of free time and the commitment to keep it going, week after week after month after year?

the original question wasn't is someone willing to keep the site updated.. it was is someone ready to put up a site... there's a big difference in those statements.. it can be setup as a community type of site, using xoops, or joomla or wordpress, etc... and then anyone/everyone can keep it updated without requiring a commitment from 1 specific person

also, I mentioned the hosting because you mentioned in your post that part of the problem would be getting it hosted.. so I removed that part of the scenario

Quote - speaking of lightgroups, you should modify the exporter so that it creates a lightgroup for each light so you can adjust them individually in lux..

like:
(original)

start light "Light 8"

AttributeBegin
LightSource "spot"
 "color L" [0.960753798485 0.839215695858 0.752925932407 ]
 "float gain" [0.449999988079]
 "point from" [0.0 0.739000022411 0.622799992561 ]
 "point to" [0.0 0.739000022411 -0.377200007439 ]
 "float coneangle" [70.0]
 "float conedeltaangle" [70.0]
AttributeEnd

(proposed)

start light "Light 8"

AttributeBegin
LightGroup "Light 8"
LightSource "spot"
 "color L" [0.960753798485 0.839215695858 0.752925932407 ]
 "float gain" [0.449999988079]
 "point from" [0.0 0.739000022411 0.622799992561 ]
 "point to" [0.0 0.739000022411 -0.377200007439 ]
 "float coneangle" [70.0]
 "float conedeltaangle" [70.0]
AttributeEnd

I think you're running some old code. I already gave adp the code to do the camera position correctly and to export light groups. You don't seem to have that.

You set the light group by naming the light. For example, if you change Light 1 to Front:Light 1 then it will be in the light group called Front.

I have 1-10e that I just downloaded this morning. The camera position isn't fixed in it. Maybe an oversight? ;o).

Laurie

Quote -
I think you're running some old code. I already gave adp the code to do the camera position correctly and to export light groups. You don't seem to have that.

You set the light group by naming the light. For example, if you change Light 1 to Front:Light 1 then it will be in the light group called Front.

if I'm running old code then it's old code as of this morning..

also, the way I was suggesting to do it doesn't require users to do anything.. I don't know about most of the people here, but personally, I don't rename lights once they get inserted into a scene, unless I specifically create a pointlight or something that's supposed to act as the lightbulb of a lamp or something similar.  I was just suggesting that rather than having people rename their lights like your code currently does, that it just creates an individual light group for each light that it exports.. I mean, you're talking about 1 extra line of code in the output, right?

Quote - the original question wasn't is someone willing to keep the site updated.. it was is someone ready to put up a site...

Yes, and that's why I expressed some skepticism, as IMHO it will be easy to put it up, but hard to keep it useful. You misunderstood what I meant, and I misunderstood what you answered... :-D

Quote - > Quote -

I think you're running some old code. I already gave adp the code to do the camera position correctly and to export light groups. You don't seem to have that.

You set the light group by naming the light. For example, if you change Light 1 to Front:Light 1 then it will be in the light group called Front.

if I'm running old code then it's old code as of this morning..

also, the way I was suggesting to do it doesn't require users to do anything.. I don't know about most of the people here, but personally, I don't rename lights once they get inserted into a scene, unless I specifically create a pointlight or something that's supposed to act as the lightbulb of a lamp or something similar.  I was just suggesting that rather than having people rename their lights like your code currently does, that it just creates an individual light group for each light that it exports.. I mean, you're talking about 1 extra line of code in the output, right?

Unless someone wants a group of more than 1 light in the group.  For example, if I set up headlights in a car, I want both headlights as part of a single group so that any change affects both equally.

On this focal length business, check what is being written into dataOut.bbml. If it is the right value, then go look at the camexport.py file.

adp rewrote my code to use his parameters, and I think there is a mistake there:

       print >> file, 'Camera "%s"' % camtype
        print >> file, ' "float fov" [%s]' % fov
        if gp.get("overrideFocalLength", "false") != "false" :
            print >> file, ' "float focaldistance" [%s]' % gp.get("focaldistance", gp.get("focallength", 50)) 
 
Notice that it doesn't override the fov - instead it writes a focaldistance into the lux file. That isn't the field of view. So with his exporter you probably can't get the correct field of view by overriding.

Also he changed the code I had in there to set up the LookAt configuration line. I have no idea what is going on.

I know my exporter produces 100% accurate camera position.

I just have a little more packaging to do and it will be ready.

I'm putting everything in a runtime structure so you have nothing to install, nothing to configure. Just unzip and go.

Quote - > Quote -

I think you're running some old code. I already gave adp the code to do the camera position correctly and to export light groups. You don't seem to have that.

You set the light group by naming the light. For example, if you change Light 1 to Front:Light 1 then it will be in the light group called Front.

if I'm running old code then it's old code as of this morning..

also, the way I was suggesting to do it doesn't require users to do anything.. I don't know about most of the people here, but personally, I don't rename lights once they get inserted into a scene, unless I specifically create a pointlight or something that's supposed to act as the lightbulb of a lamp or something similar.  I was just suggesting that rather than having people rename their lights like your code currently does, that it just creates an individual light group for each light that it exports.. I mean, you're talking about 1 extra line of code in the output, right?

Oh. In the next GUI I will let you arrange the lights into groups yourself (drag and drop), or use one checkbox to put each in its own group.

Quote - On this focal length business, check what is being written into dataOut.bbml. If it is the right value, then go look at the camexport.py file.

adp rewrote my code to use his parameters, and I think there is a mistake there:

       print >> file, 'Camera "%s"' % camtype
        print >> file, ' "float fov" [%s]' % fov
        if gp.get("overrideFocalLength", "false") != "false" :
            print >> file, ' "float focaldistance" [%s]' % gp.get("focaldistance", gp.get("focallength", 50)) 
 
Notice that it doesn't override the fov - instead it writes a focaldistance into the lux file. That isn't the field of view. So with his exporter you probably can't get the correct field of view by overriding.

Also he changed the code I had in there to set up the LookAt configuration line. I have no idea what is going on.

I know my exporter produces 100% accurate camera position.

I just have a little more packaging to do and it will be ready.

I'm putting everything in a runtime structure so you have nothing to install, nothing to configure. Just unzip and go.

 

Good to know ;o). I thought I was doing something wrong...again....lol.

Laurie

Quote -

P8 Old Mike 4 exported to LuxRender with ver 10e.
2 Hrs into the render.

a cross between hannibal lector and "The Rock"? :P

Quote - ok, I "slapped something together".. let me know what you think :)

I don't have much information about this yet (haven't read through the forum, just found out about it yesterday)

Possible Site Layout

Nice! Seems we found somebody ;)

Do it lke you think. Will be usefull anyway.

Quote - > Quote - the original question wasn't is someone willing to keep the site updated.. it was is someone ready to put up a site...

Yes, and that's why I expressed some skepticism, as IMHO it will be easy to put it up, but hard to keep it useful. You misunderstood what I meant, and I misunderstood what you answered... :-D

Why didn't you let it go first? Remembers me on: "No chance to do an exporter because Python is to slow".

Quote - Why didn't you let it go first? Remembers me on: "No chance to do an exporter because Python is to slow".

Well, I actually did hope that after my negative post someone would feel challenged to do it...
evil smirk

Quote - I thought after I published the camera code that you guys would apply the same logic to spotlights.

I haven't yet had time to re-factor all this stuff. So if you're anxious to fit the spotlight code what you have, here it is.

I plan to completely rewrite this so don't spend too much time evolving it.

I'm sorry, but this program is just too wordy - too many lines of code that don't do anything. Scrolling past 200 lines of stuff that emits only a few lines in the Lux scene is making me nutty.

I'm writing new add-ons to BBML that are making the generation of Lux scene properties really trivial.

I'm hoping they stay trivial as I also implement the same for Kerkythea or whatever else we want.

Sorry, in between my "playversion" of camexporter made it into the zip.
Restored to the old version.

About the renderwindow:

Python windows has just one function to get a render-size. This function delivers no correct values if the renderwindow is docked. You have to set the size under Menu->Render->Render Dimension.

Quote - About the renderwindow:

Python windows has just one function to get a render-size. This function delivers no correct values if the renderwindow is docked. You have to set the size under Menu->Render->Render Dimension.

That one works pretty well on the exporter's side; It's just tedious on the Poser side, as we all are used to have preview = render size. I guess it will get easier when the GUI reminds you about the render size.

The problem is with the camera setting. Check my renders further up. I used v.10e, straight (no GUI), and expected to find the same focal length (around 100mm, IIRC); Apparently it differed a little. Now I don't know if it is because 100mm in Poser and 100mm in Lux mean different things (most likely), or if there was an export hiccup. Sorry, exporter files being always overwritten, i don't have them anymore, and I didn't think to check at that moment.

Quote - > Quote - I thought after I published the camera code that you guys would apply the same logic to spotlights.

I haven't yet had time to re-factor all this stuff. So if you're anxious to fit the spotlight code what you have, here it is.

I plan to completely rewrite this so don't spend too much time evolving it.

I'm sorry, but this program is just too wordy - too many lines of code that don't do anything. Scrolling past 200 lines of stuff that emits only a few lines in the Lux scene is making me nutty.

I'm writing new add-ons to BBML that are making the generation of Lux scene properties really trivial.

I'm hoping they stay trivial as I also implement the same for Kerkythea or whatever else we want.

Sorry, in between my "playversion" of camexporter made it into the zip.
Restored to the old version.

About the renderwindow:

Python windows has just one function to get a render-size. This function delivers no correct values if the renderwindow is docked. You have to set the size under Menu->Render->Render Dimension.

Do you have to do that before every export?

Laurie

Exporter bug, this one probably for bagginsbill:

  File
"L:PoserPoserPro2010RuntimePythonposerscriptsLuxPosePoserLuxExporter_alpha_1-10eluxmaticmatcore.py",
line 404, in __init__<br></br>
    self.importFromShaderNode(v)<br></br>
  File
"L:PoserPoserPro2010RuntimePythonposerscriptsLuxPosePoserLuxExporter_alpha_1-10eluxmaticmatcore.py",
line 487, in importFromShaderNode<br></br>
    setattr(self, inp.name,
inp.importFromShaderNode(snode))<br></br>
  File
"L:PoserPoserPro2010RuntimePythonposerscriptsLuxPosePoserLuxExporter_alpha_1-10eluxmaticmatcore.py",
line 215, in importFromShaderNode<br></br>
    v = inp.Value()<br></br>
AttributeError: 'NoneType' object has no attribute
'Value'

After which the script dies.
Nothing happens anymore, CPU is idle.
I waited about 5 minutes and closed the window.

Scene was one M4 and one V4 (clothed, haired) inside Faveral's "Hacienda" setting, a biggish outdoor setting with lots of textures, but AFAIK no complicated materials.

Quote - Do you have to do that before every export?

Yes!...
That's one of the regressions of Poser 8/Pro 2010. If you make a new scene and don't set the render size, it will be rendered in the default size of 500x490 or some such.
In Posers before 8 the preview size was automatically the render size, unless set otherwise;
In Poser 8, because of the docked window, the render size has to be set. Every time, for every scene.

But that will be fixed by the GUI, since it will allow to override easily whatever size Poser exports. Even better, since it will (AFAIK) allow to have setting presets, you can just load a preset.

Quote - > Quote - About the renderwindow:

Python windows has just one function to get a render-size. This function delivers no correct values if the renderwindow is docked. You have to set the size under Menu->Render->Render Dimension.

That one works pretty well on the exporter's side; It's just tedious on the Poser side, as we all are used to have preview = render size. I guess it will get easier when the GUI reminds you about the render size.

The problem is with the camera setting. Check my renders further up. I used v.10e, straight (no GUI), and expected to find the same focal length (around 100mm, IIRC); Apparently it differed a little. Now I don't know if it is because 100mm in Poser and 100mm in Lux mean different things (most likely), or if there was an export hiccup. Sorry, exporter files being always overwritten, i don't have them anymore, and I didn't think to check at that moment.

Note, the current version now is v0.11.1.  adp had posted that he accidentally included the wrong camera exporter, and the new version has the correct one.

It's possible to get the size of the view port in Poser 8/Pro 2010, no matter if it's docked or undocked, if that's the problem. I can post some code that does just that.

Quote - Note, the current version now is v0.11.1.  adp had posted that he accidentally included the wrong camera exporter, and the new version has the correct one.

Okay, thanks. So it's the 10e which had the wrong exporter?

Quote - It's possible to get the size of the view port in Poser 8/Pro 2010, no matter if it's docked or undocked, if that's the problem. I can post some code that does just that.

No, the problem (for the exporter) is that it takes into account the render size (the sensible choice), but that many Poser users (me included) forget to specify it, because we're used to years and years where it was silently inherited and didn't need an explicit setting.
So it's more a Poser than an exporter problem.

Since we can't fix Poser, then why not use the code to fix it in the exporter?  Maybe a checkbox to use viewport size as render size.

I am also one who forgets to change it; hough recently I am finding myself remembering a whole lot of times!  LOL.

and yes, it was 10e that had the wrong exporter.

Well, Poser 8/Pro 2010 give the following information:
Do you want to render to the specified resolution or do you want to render to the viewport size.
It just always returns the setting for the specified resolution. But the resolution of the viewport can be achieved through some tricks...
So it's possible to get the setting the user wants...

Quote - > Quote - Do you have to do that before every export?

Yes!...
That's one of the regressions of Poser 8/Pro 2010. If you make a new scene and don't set the render size, it will be rendered in the default size of 500x490 or some such.
In Posers before 8 the preview size was automatically the render size, unless set otherwise;
In Poser 8, because of the docked window, the render size has to be set. Every time, for every scene.

But that will be fixed by the GUI, since it will allow to override easily whatever size Poser exports. Even better, since it will (AFAIK) allow to have setting presets, you can just load a preset.

The actual GUI shows "Poser Dimension". Below this is a checkbox "overwrite". If you click this you are able to set a fixed rendersize. 

Quote - It's possible to get the size of the view port in Poser 8/Pro 2010, no matter if it's docked or undocked, if that's the problem. I can post some code that does just that.

Yes please.