Quote - > Quote - > Quote -

the problem is that noone from blender knows how to make a good skin shader since they dont have any cheats in lux and since they dont have SSS.

i guess the skin shader would be a combination of matte+ glossy +bump+ some cheat.

we will have to whait until we are able to render scenes from poser.

I heard the Lux programers are working on SSS.  In the meantime a modified Matte Translucent shader may help. But I didn't try it yet.

See  http://www.luxrender.net/wiki/index.php?title=Scene_file_format#MatteTranslucent

i think its all BS. everyone who doesnt have SSS is saying that they are working on SSS for years yet its never inside. the ones who want SSS in their  render already have SSS.
for christ sake its 2010. the code for doing SSS is simple to the guys who know how to code. SSS is out already for 8 years.

Yafaray also doesnt have SSS. but they at least showed some tests from teh SSS that they are working.

Lux ,yafaray,Indigo are renders who are meant to be for cars,room,buildings,......

this is my opinion based on oen week of searching free renders.

Check out fryrender - if you have the cash - it has a couple flavors of SSS.

http://randomcontrol.com/fryrender-tech-specs

And Octane Render has SSS down the road on their feature list, but you can already do some neat stuff (like leaves) with translucent materials in it.

it would be great if poser would have an render engine that is seperated. but at same time connected with the material room.
that way they could have glossy reflectiosn and SSS without changing firefly.

of course fryrender would not be an option since its 790$

Actually 795 euros which at today's exchange rate is $1,010US. And a bigger app  is needed to use it with Poser figures (C4D works best so far), unless you convert them to .3ds and use SketchUp which is problematic in more than a few ways..

Here's the page with PoserMan that Stefan was talking about in an earlier post. Maybe someone could do as he suggested and figure out how to make it work with Pixie.

http://www.keindesign.de/stefan/poser/poserman.html

Kevin

Just another dumb question concerning Lux and Poser Point lights.

Does Lux treat point lights correctly?  At least as far as the point lights exported from Poser.  I put a point light just above the camera, and very slightly behind; but it only seems to light up the ceiling and not the floor.  And I did check the .lxo file, and it is listed as a point light there.

Just curious.

. Just posting so I can get notifications :)  This is very interesting!

Quote - Just another dumb question concerning Lux and Poser Point lights.

Does Lux treat point lights correctly?  At least as far as the point lights exported from Poser.  I put a point light just above the camera, and very slightly behind; but it only seems to light up the ceiling and not the floor.  And I did check the .lxo file, and it is listed as a point light there.

Just curious.

Point light in Lux works different than in Poser and should be avoided (at least at the moment). Bagginsbill talked about it a few pages before. The plan is to replace point light with area light. The light then will have a geometry and is visible in the scene.

Quote -  ADP, I'm getting an error with the latest version of the exporter, alpha1-9:

 

Sorry. Missed to update one file in the zip.

Fixed. Please re-download.

 Thank you, working now. :)

Where is it getting the Linear settings from? Sensitivity, Exposure, F/Stop? I thought from dataout.bbml, but it's not using the values I define in there.

its very important that the normal is in the right direction. i could use a cube. but luxrender renders every face like a seperate light source so this means that it would be like i would have 4 are arealights. since its not visible i just used one face.

p.s.:
on the outside i make a cube where the normals are inside.you think that we need to have this? i have been reading somewhere that its better to have ''walls'' so that rays know where to stop bouncing.

the hightlights on the skin are now physical correct. look at hes foot. with the blinn node this would not look like that. because the shape of the light source is square and not round.

Quote -  Thank you, working now. :)

Where is it getting the Linear settings from? Sensitivity, Exposure, F/Stop? I thought from dataout.bbml, but it's not using the values I define in there.

I use the original-names (see Lux docs) as key to get parameters stored in the GUI-written output.
I have to see if I had a typo. Or if the parameternames differ in the GUI.

Quote - the hightlights on the skin are now physical correct. look at hes foot. with the blinn node this would not look like that. because the shape of the light source is square and not round.

Interesting. Thanks!

Next "feature" shoud be a possibility to declare an area light in Poser. Any ideas how to do?

Poser users have to learn some things (mostly light) and a possiblity to turn this into something using Poser.

In the Lux manual I found something about Point-Light:

Point light Point lights are infinitely small light sources that emit light in all directions. Although point lights are widely used in modelling programs, their use is discouraged because infinitely small light sources don't exist in nature and will yield unrealistic results in the form of too sharp shadows.

However point lights are able to make use of IES diagrams available from lighting fixture manufacturers. Those are able to precisely describe light intensity in every direction allowing you to better simulate real lighting conditions.

simplest method would be usage of a simple plane with a declared hard-coded material name prefix - example AL (for Area Light), then the lights name as set by default / user. so that would be AL-Windowlight.

the code can then see that AL is area light and set that as a light emitter in the scene for Lux.

you pick the object that you want ot use as a ligh. and then in luxblend you make it a light.

Quote - > Quote -  Thank you, working now. :)

Where is it getting the Linear settings from? Sensitivity, Exposure, F/Stop? I thought from dataout.bbml, but it's not using the values I define in there.

I use the original-names (see Lux docs) as key to get parameters stored in the GUI-written output.
I have to see if I had a typo. Or if the parameternames differ in the GUI.

Sorry, was a mistake I made while exporting the tonemapper part. 

Fixed. Please re-download.

Quote - this is how it looks in luxblend.

you pick the object that you want ot use as a ligh. and then in luxblend you make it a light.

Yes, I know. But things are a bit different with LuxPose. We decided to have an independent GUI. Simply because there are lots of P5/P6 users and so mutch differences between the versions.

Identifying an arealight-geometry (and other things too) is possible if we use a name-prefix for Lux-specific props/actors and materials. The geometry-/material-exporter part should handle objects with this name prefix as an exception.

Moreover, it's possible to pre-define some special Lux-lights as Poser lightsets ((LT2 files) or props (not sure if a prop is able to carry a light beside of a geometry). 

Lights and geometries defined in Poser used for Lux may also have special "dials".

Quote - Identifying an arealight-geometry (and other things too) is possible if we use a name-prefix for Lux-specific props/actors and materials.

What's wrong with handling it the same way as all other materials? Translate Poser's ambient setting to Lux? That sounds easier than to have to use the grouping tool to make material zones with the proper name ;-)

I mean things Poser don't know nothing about. Something like arealight.

Attached is an example prop to show what I mean.

Internal name of a value-parameter is the name Lux knows (e.g. "LUX_nsamples") . The name displayed can be something other.

If a Poser-Light is attached to this prop a Firefly testrender may show similar shadows/light intensity as Lux will do (ok, not mutch similar :) ).

Using a prop insteed of adding parameters to a poserlight allows any geometry you like as a lightsource. This may be new to Poser uses, but maybe you can imagine what is possible with something like that. 

Lux is great and i"m glad Reality is coming to DS.

Quote - Using a prop insteed of adding parameters to a poserlight allows any geometry you like as a lightsource. This may be new to Poser uses, but maybe you can imagine what is possible with something like that. 

Err... Poser 8 does just that with IDL turned on and an ambient setting (former versions just had the object glow without emmiting light)... So the question is: why reinvent the wheel (and add corners)?

While adding some dials to actors we can finetune parts of the exported geometry.

Because odf made it possible to Catmul-Clark subdivide a geometry even low-polygon models may be rendered high-res with smooth curves ...

INCLUDE_PROPS = True
INCLUDE_LIGHT = False
FORCE_DEFAULT = True

parameters2add = dict( 
    LUXGEOM_subdivide=("Subdivide", 0, 5, 0),
    LUXGEOM_catmulclarc=("Catmul-Clark", 0, 5, 0),
    LUXGEOM_usequad=("Force Quad", 0, 1, 0)
)

import poser
scene=poser.Scene()

def setparams(param, name, min, max, value):
    param.SetName(name)
    param.SetMinValue(min)
    param.SetMaxValue(max)
    param.SetValue(value)
    param.ApplyLimits()
    
for ac in scene.Actors() :
    if not (ac.IsProp() or ac.IsLight() or ac.IsBodyPart()) : continue
    if ac.IsProp() and (not INCLUDE_PROPS) : continue
    if ac.IsLight() and (not INCLUDE_LIGHT) : continue
    
    for internalname, params in parameters2add.iteritems():
        try:
            ac.CreateValueParameter(internalname) 
        except: 
            p=ac.ValueParameter(internalname)
            if FORCE_DEFAULT:
                setparams(p, *params)
            p.ApplyLimits()
        else:
            setparams(ac.ValueParameter(internalname), *params)

print "Lux parameter dials added"

I read all 36 pages last night and decided to try this out, I loaded a simple character with dress shoes and hair, added a spotlight and one point light. I then run the exporter script, opened lux render and brought in the file, it says it is rendering but all I see is black. Did it not bring in the lights? Or is there another script I need to export the lights? Sorry for the questions, but I'm not sure what page here in the forums to go back to, to find out if the lights have to be added to the file by hand. If they do, I have no idea how to do that! Thanks

Quote - > Quote - Using a prop insteed of adding parameters to a poserlight allows any geometry you like as a lightsource. This may be new to Poser uses, but maybe you can imagine what is possible with something like that. 

Err... Poser 8 does just that with IDL turned on and an ambient setting (former versions just had the object glow without emmiting light)... So the question is: why reinvent the wheel (and add corners)?

At least we need a chance to set parameters like "importance" and "nsamples" for each defined arealight?

Maybe it's not easy to decide if a geometry with ambient != 0 is an arealight or not. 

On the other side: Why not both? An automatic decission and a possibility for "advanced users" to define things exactly? 

Same for other lightsources with lots of special parameters hardly to guess (see  http://www.luxrender.net/wiki/index.php?title=Scene_file_format#Light).

Or is it really not required? What do other think about this?

Ok I moved my lights further above the character, and now I can see it is working :)

Quote - I read all 36 pages last night

Wow!

Quote -
and decided to try this out, I loaded a simple character with dress shoes and hair, added a spotlight and one point light. I then run the exporter script, opened lux render and brought in the file, it says it is rendering but all I see is black. Did it not bring in the lights? Or is there another script I need to export the lights? Sorry for the questions, but I'm not sure what page here in the forums to go back to, to find out if the lights have to be added to the file by hand. If they do, I have no idea how to do that! Thanks

I think not. To be sure, please download the last version (see my footer).

Lux needs a few seconds (depends on how fast your machine is) to pre-compute some things. This can last up to a half minute until you see something.

As you may have read this project is in an early stage. The material exporter may decide to interrupt the script because of some material-nodes he is not able to convert yet. So have a look for someting that looks like an error message after the exporter is started.

Ups, crossposted ... 

Everything exported fine, and the render is now working, I guess I forgot that someone mentioned the light had to be moved up higher for them to work. ( Or something like that) So all is good now. Thanks

Quote -
At least we need a chance to set parameters like "importance" and "nsamples" for each defined arealight?

  Maybe it's not easy to decide if a geometry with ambient != 0 is an arealight or not. 

I'd guess that BB already put some thoughts into that for his material converter.

Anyway, for me it would make more sense to add parameters to the material and not to a prop.
That'll probably look odd, as it would need to be done via additional (unconnected) nodes (probably distinguished by unique names).
Otherwise you'd have parameters in the prop's properties (probably multiplied by the number of material zones) and material settings per material. So you need to check materials in the properties palette and in the material room... And you cannot just save material settings to the library and reuse those materials because the setting are in the prop's parameters...

But that's just my two cents :-)

Just a quick request.  A few pages back rty posted a sunsky for Lux.  It works great.  Would there be a way to incorporate that without having to edit the file everytime?  Maybe as a checkbox if we want to use it. 

Here is the post that shows it.

Looks great; But for more realistic light try a real Lux "sun" light instead of the pointlight:
Edit the .lxo file in notepad and delete the light (on top, pretty obvious, it's well commented), then open the .lxs file and insert after WorldBegin:

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

Insert empty lines if you want to separate the rest.
As you might have guessed, "vector sundir" determines where the sun is in the sky. The "float" parts control haze, but you won't see any in your scene anyway.

Import the edited file to Lux like usual and let it render. It adds a real "sun" and a "sky" light, I'm absolutely in love with this feature...

"

Could somebody assemble a wish list, broken down by material, light, etc.

I'm working on the exporter but can't keep track of all the requests at the moment.

If how to solve a request is in doubt, it would be good to note alternatives in the wish.

Automatically assuming that any material with some ambient in it is a light source is bad. In Lux, a material that is a light source is only a light source and not anything else, and if it has a lot of polygons it is a very expensive light source.

i have been also reading this. that if you make it a light that every face is a light source. so for example if you would make the whole M4 figure a lightsource it would be insane slow.

its not so simple anymore like in Poser. Lux is making everything physical correct.

but i think an easy way to make materials into lights in the GUI is pretty necessary for most scene props, especially complex ones.   it seems silly to change a bunch of materials by hand rather than just check them off in a list.

A simple Python script can be used to load/unload special Lux-props  and materials  (props with a name prefix). 

For merchants this is a possibility to sell special lightsets simply as a set of props.

@BB and odf:

Can we assume the name prefix LUX_ has a special meaning? Means a library/script recognizing such a name and don't know how to handle it should simply ignore the object in question.  Does this make sense to you?

Quote - Using a prop insteed of adding parameters to a poserlight allows any geometry you like as a lightsource. This may be new to Poser uses, but maybe you can imagine what is possible with something like that. 

That sounds great to me, you can have light bulbs emitting light, windows or screen doors acting as area lights.

imho, that doesn't make sense to do.  i mean, if you're going to automate loading, why not allow selection of materials and props rather than relying on developers to add some specific naming convention?  that's not a very extensible answer.  what happens when there's a Yafaray exporter, or some new free renderer comes along that's better and needs completely different treatment?  then props and materials need renaming just to fit the new system, and can only work for one renderer.  not to mention the literally thousands of props that already exist without any of that information.    why would it be so hard to implement something that just gives people the choice of what to add and how to handle things?

edited to add: ooops, x-post.  i was responding to the prefix idea.

Quote - Here is a quick render, it hasn't finished, but this is what it looks like so far. Just wanted to see if I could get it to work :)

That looks pretty good already for a 1st test. :)

The issue with spotlights at the moment is that where the light points to is not exported yet, so every spotlight will point to coordinate (0, 0, 0).
The easiest workaround at the moment is to move the spotlight farther away so they cover a larger area.
Or if you feel adventurous you can edit the .lxo file, the lights are at the start of that file, you can add "point to [x, y, z]" to the light definition, it will take a bit of guessing to get the correct coordinates.

That explains a problem i was having earlier!  I couldn't figure out why the corner of a room was not lit, even though in Poser i had pointed a light right at it.  I may have to try to edit the .lxo file, as There isn't enough headroom to move the spots any higher than they already are.

Actually, I remember BB mentioning this, but i thought he had said he had fixed it.  Maybe he just said he knew what the fix was.

Stopped after about 2 hours then flipped the glare switch.

 As a guideline to converting coordinates from Poser to Luxrender I found that dividing the number of meters in Poser by 2.63... gives the coordinate to use in Luxrender.

Example:
a spot in Poser pointing to coordinate (5, 2, 1) translates in Luxrender as "point to" [1.9 0.76 0.38]

This is just an estimate, but it should get you in the right direction.

Quote - imho, that doesn't make sense to do.  i mean, if you're going to automate loading, why not allow selection of materials and props rather than relying on developers to add some specific naming convention?  that's not a very extensible answer.  what happens when there's a Yafaray exporter, or some new free renderer comes along that's better and needs completely different treatment? 

Seems that any render engine has some special things. No other engine I know of has a light that acts like a "skyglob" including a light for example.

Ok, we could assume any IBL should be replaced by a sunsky. But what if somebody is using a real skyglobe and addtionally IBL?

I don't talk about what can be examined from a Poser scene to standards used by any other engine. But I think material conversion for render-engine xyz is also not possible without doing something. Except render-engines do use the same material handling (rib, for example). This is the reason why bagginsbill thought of adding a standard-material handling for Lux as a Lux-extension (probably this has to be done for other renders, too).

The reason you talked about (a programer has to add something for other render engines) is why I mean it's best to write the code as abstract and "easy to read" as possible to make sure somebody is able to extend the code later (or to use it as a framework).

As far as I can see, to address the standard Poser user the material export is the most important part (some specialists may not need a complete conversion). Moreover, guessing what a nodeset inside a material may be good for is the hard part (skin or not for example, or x-nodes just to get a "realistic" reflection/glaseffect). Most of the tricks done to get a nice material in Poser aren't useful for other render engines. Discarding such nodes may not only speed up rendering but also may come out better.

I'm sure this part is true for any other render-engine but Firefly (the common part). So if it is possible to translate pure Poser materials to something like "Meta-Materials" (beside of the conversion to Lux matarials), the hardest work is done for any other render engine.

But all this has nothing to do with all the nice features a new render-engine may have and could be used by the user - if he had a "handle" (simply a special prop to fill the gap; with a name prefix to not disturb what is defined for another render-engine and not accidently rendered). 

This leads me to the need of having an editable list of "Prefixes to ignore" :)
Or to call a function with each name in question ...

My conclusion: If props/actors/ligths with a prefix are ignored, the material-exporter isn't involved anyway. All this objects could be disabled before the exporter touchs them (with automatic re-activation later). Materialnames are still untouched.

At the end: What I'm talking about is nothing you HAVE to use. But you CAN if you want. If it is properly ignored by parts who don't know to handle objects with the prefix in question.

Starting a Wishlist:

  Materials:
      1) Avoiding interruption because of converted nodes missed.
      2) Solution for skin-materials.

  Light:
      1) Adding what you showed us you did with point light (scaling etc).

Quote -  As a guideline to converting coordinates from Poser to Luxrender I found that dividing the number of meters in Poser by 2.63... gives the coordinate to use in Luxrender.

Example:
a spot in Poser pointing to coordinate (5, 2, 1) translates in Luxrender as "point to" [1.9 0.76 0.38]

This is just an estimate, but it should get you in the right direction.

Probably a "rotation" entry may help (insteed of "point to"). Background: It's impossible to find out where a light in Poser points to (except if a special "target" prop is used).

LOL.  I was just going to ask how to determine target of a Poser spot.  I couldn't figure it out.  Now i know why.

again, to me, you're just not making sense.  you're coming up with a solution that needs content editing, when in point of fact that's just not necessary or beneficial to content owners or creators. yes, every render engine has something special.  which is why the content should be renderer agnostic.  just leave the content alone, which you'd have to account for anyway, and let people select the special treatment themselves.

it seems pretty trivial to have a tab for different types of treatments and a list of materials to check with a default of nothing checked or guessing by some basic material property, including name.   it would make more sense to detect things VSS string evaluation style than some artificial prefix.  like bulb, glow, light, flame, etc. for lights, skin for skin, etc.  and personally, i've never used ambient for anything that doesn't glow in all my years of using Poser.

it seems simple to implement, necessary for legacy content, and doesn't make the content renderer specific. 

Lux and SSS 

From the FAQ:

Implementation of subsurface scattering is planned for LuxRender version 0.8. In the meantime, however, you can simulate it quite effectively, if not 100% physically correctly.

...

Third, the mattetranslucent material is best used in a "mix" material along with a glossy material. The combination of mattetranslucent and glossy materials, along with some tweaking and adjustment, does a very good job approximating subsurface scattering in LuxRender.

Quote - again, to me, you're just not making sense.

This is a statement I can live with. Thanks for feedback.