Ugh, I need to read more closely ... I believe odf has already made a statement on this. ::sorry::

Quote - Understanding that BB is working on the Poser materials conversion aspect, I am curious if there is / will be a way to utilize the Lux Materials Database of presets from HERE, ? or is the intent to mimic what these shaders do in "higher end" (read more costly) packages.

That is among my plans. The LBM format is something the LuxBlender export utility created. It's not part of LuxRender, per se. Since it has no documentation, I'll have to read the LuxBlender code to understand what the LBM files say. But I will do that.

It would be a shame if we could not use the LBM files produced by others, so I really want to support them.  That is not the only format I plan to support.

We have Poser mt5 files and of course you just load them into Poser. To the extent that I can auto-convert these to Lux materials, I will.

We will also have the ability to define materials as luxmatic scripts. Luxmatic scripts are a much more powerful way of describing materials and the parameters that go with them. Luxmatic is a variant of matmatic, and it has long been my plan to make a GUI for matmatic. Now is the time. Coming out of this project will be a GUI for luxmatic and matmatic material definition and loading.

My Lux exporter GUI is still an infant, but my plan is to incorporate the ability to select a material or a group of materials and assign a shader, substituting the textures and colors already on those materials. This is what VSS does already, but without a nice GUI. Since this exporter needs to exactly what VSS does, I guess this means that VSS will finally get a GUI.

Between VSS, matmatic, and luxmatic, we'll have a very powerful (and scriptable!) material management system both for Poser itself as well as any exporter.

I think this is a workable starting set of properties for the film, render setttings, and camera. (There are a ton more in these areas.)

Now I'll integrate the GUI into the exporter framework and code the exporter to use the user supplied values from this GUI to construct the Lux scene file.

I really love this GUI engine - adding new properties is sooooo easy and requires zero coding.

Quote - > Quote - Understanding that BB is working on the Poser materials conversion aspect, I am curious if there is / will be a way to utilize the Lux Materials Database of presets from HERE, ? or is the intent to mimic what these shaders do in "higher end" (read more costly) packages.

That is among my plans. The LBM format is something the LuxBlender export utility created. It's not part of LuxRender, per se. Since it has no documentation, I'll have to read the LuxBlender code to understand what the LBM files say. But I will do that.

It would be a shame if we could not use the LBM files produced by others, so I really want to support them.  That is not the only format I plan to support.

We have Poser mt5 files and of course you just load them into Poser. To the extent that I can auto-convert these to Lux materials, I will.

We will also have the ability to define materials as luxmatic scripts. Luxmatic scripts are a much more powerful way of describing materials and the parameters that go with them. Luxmatic is a variant of matmatic, and it has long been my plan to make a GUI for matmatic. Now is the time. Coming out of this project will be a GUI for luxmatic and matmatic material definition and loading.

My Lux exporter GUI is still an infant, but my plan is to incorporate the ability to select a material or a group of materials and assign a shader, substituting the textures and colors already on those materials. This is what VSS does already, but without a nice GUI. Since this exporter needs to exactly what VSS does, I guess this means that VSS will finally get a GUI.

Between VSS, matmatic, and luxmatic, we'll have a very powerful (and scriptable!) material management system both for Poser itself as well as any exporter.

Thank you for this explanation BB :)

I have only dabbled with matmatic and VSS, but I do realize the power behind these. 

This again, is SO VERY exciting,  
(sort of like I remember being Christmas when I was about 7 years old :))

Neat GUI, bagginsbill! Are you going to patent the idea for the builder or can I steal it for my projects? :laugh:

At some point I'll have to take a good look at the geometry exporter and see what a good set of user-definable parameters would be. But there are two I can name right now: the number of subdivision steps and whether to subdivide in Lux via Loop subdivision or in the exporter via Catmull-Clark (I've been adding the latter over the last two nights, and it's working nicely except for the UV coordinate interpolation, which I haven't yet implemented).

The BBML parsers (one in Python, one in AS3) will be public domain I think. Not even open source, but rather completely open. Use them in commercial products of any kind.

The BBML GUI builder that interprets BBML as instructions to build a GUI - that is probably something I want to retain control of. It's incredibly powerful. I've built things like this before, but never this clean.

I think what I'll probably do is not release the source for the GUI builder. Instead, I'll grant permission for its use (as a binary app) in this exporter (LuxPoser? need a name!), and then decide what else to let others use it for on an individual basis.

I'll probably grant an open non-commercial binary license for all projects like this where it is to be used in something that is not for-pay. Any use in a commerical app - well I'd prefer to get paid for the value it creates. But that's far out in the future at the moment.

At the moment, I'm only constructing a Flex BBML GUI builder. Other flavors are certainly possible, such as WPF (in C# or IronPython) and wxPython. I actually built a simpler but working version of this for WPF/IronPython a couple years ago but didn't use it for anything serious. I'll revisit that.

Quote - Hmm, come to think of it, that could even be a case for crowd-sourcing. Connect the local per-user database with a central one (if we can find a volunteer to host it). If the object is found in the central database, the user will be presented with the values set, but of course she will be able to override them for her own use.

Caveat: Many users (including me) choose to not have their CG computers connected to internet, there is no reason for this, but several against it (like security and optimization).

There must be some automated way to split organics from not-organics and decide about smoothing or leaving sharp. I'd suggest using the Poser values of (figure-based) settings "Smooth Polygons" and "Crease Angle". The advantage is they are already there, there is nothing to do but translate them, they are already set for many items, users can change them easily, and the merchants are able to control how their stuff will look in Lux (if they bother, of course).

And last but not least, it's something Poser users are familiar with (well, most).

*(LuxPoser? need a name!)

I suggest we keep to the naming convention already used and go with LuxPose (as in LuxBlend, LuxMax, etc)

adp-

Are we serious about using an app server behind the GUI? If so, I'll add support for reading and writing BBML via URL's instead of just files. And I'll add support to send and receive dynamic data via an HTTP request.

How mature is your server? I have one (Paser) that is very powerful, but never published it.

In Paser, you write methods that accept arguments in ordinary Python style and return values that get sent back as an HTTP response.

For example, (a trivial one) to add a web service method to Poser that adds two things together and respond with XML, you simply write this in an ordinary Python file:

addResponse = XML('added')
def add(a, b): return addResponse() << a + b

If you then placed this code in /paser/apps/demo.py, you could call it via HTTP like this:

http://localhost:8888/apps/demo.py?op=add&a=20&b=30

The response would be:

50

If you called it with ...?op=add&a=foo&b=bar
the response would be: foobar

Notice that numbers are received as numbers and strings are received as strings. Paser does this automatically.

If you wanted to include XML attributes in the response you can write:

def add(a, b): return addResponse(first=a, second=b) << a + b

In the first example this would return: 50

Or you could write:

def add(a, b): return addResponse(first=a, second=b, sum=a+b)

And this would return:

Quote - That is among my plans. The LBM format is something the LuxBlender export utility created. It's not part of LuxRender, per se. Since it has no documentation, I'll have to read the LuxBlender code to understand what the LBM files say. But I will do that.

It would be a shame if we could not use the LBM files produced by others, so I really want to support them.  That is not the only format I plan to support.

Excellent.  That means people will be able to make/exchange (even sell?) materials for Lux, materials maybe even usable by  D|S users. Merchants will love this.

Also, I love the Poser Material Room and am pretty proficient with it, but I've noticed many people are completely lost in there; I can only assume it will be worse for Lux. The ability to use ready-made materials will certainly boost the acceptance of Lux by a bigger part of the community.

Quote - *(LuxPoser? need a name!)

I suggest we keep to the naming convention already used and go with LuxPose (as in LuxBlend, LuxMax, etc)

LuxPose works for me.

Works for me too ;)

Laurie

My suggestions:

'Plux' or maybe 'Loser'  : )

On a more serious note: I've been following this thread with interest. I don't understand any of the technical stuff and therefore don't have a feel for what stage development has reached.

Is someone willing or able to give a 'where we are now' summary?

We are now...

still in the baby stages methinks ;o).

Laurie

Quote - We are now...

still in the baby stages methinks ;o).

Laurie

So when do I get my bottle?

Do you prefer white, red or rose? ;o).

Laurie

Red please, but no Shiraz! Zinfandel is my favourite.

i like LuxPose

and

P-Lux

LuxPose suggest it has something to do with posing, not a good choice imo.  P-Lux or something like that is a better choice.

Quote - LuxPose suggest it has something to do with posing, not a good choice imo.  P-Lux or something like that is a better choice.

well.. it is going to be part of poser. which is posing. and the precedent has already been set by the Lux team as in = LuxBlend, LuxMax, LuxMaya, LuxXSI, LuxC4D, SU2Lux... so LuxPose is the logical choice.

I think LuxPose will be fine ;o). You don't really have to overthink it...lol.

Laurie

 I've been lurking in the shadows and watching this thread in excitement.  You people are superstars!  I don't know if I'll ever use Luxrender as the render times seem gigantic but it will certainly come in handy for certain projects.  And a GUI for VSS and Matmatic...?   Bring out the champagne!! :)

Quote - Skinned!

There is so mutch news - and I'm so damned short with time at the moment.

I'll answer within a few ours. I just had the time to add the new code from ODF (subdividing figures). It's disabled by default, but you just have to change one value in "PoserLuxExporter.py" to activate it. It's documented in the source.

Download: http://www.poserprofis.de/PoserLuxExporter_Alpha

Gave it a try (v6), it works like a charm.
I exported a V4 (with an advanced Poser material), wearing hair and a simple bathing suit; Of course I had to remove/replace the nodes the exporter doesn't understand (strangely enough, only Glossy and Noise were not recognized; Math nodes, Anisotropic, Blinn and some others went through).

While importing into Lux, the log gave me some errors, but started rendering nevertheless. I thought you might be interested in those errors:

<em>[2010-08-18 17:54:15 Info: 0] Loading FreeImage Texture:
'F:PoserRuntimeTextures...texture.jpg'...<br></br></em>(-snip lots of
those-)<em><br></br><br></br>
[2010-08-18 17:54:20 Error: 41] Couldn't find float texture named
'Color_Mul_65'<br></br>
[2010-08-18 17:54:20 Error: 41] Couldn't find float texture named
'Color_Mul_65'<br></br></em>(-snip lots of loading-)<em><br></br><br></br>
[2010-08-18 17:54:41 Debug: 0] Compiled scene size:
106755KBytes<br></br>
[2010-08-18 17:54:41 Debug: 0] Mesh: accel = none (global),
triangles = 1324 wald, quads = 0 quadrilateral<br></br>
[2010-08-18 17:54:41 Warning: 43] Inconsistent shading normals<br></br>
[2010-08-18 17:54:41 Warning: 43] Inconsistent shading normals<br></br>
[2010-08-18 17:54:41 Warning: 43] Inconsistent shading normals<br></br>
[2010-08-18 17:54:41 Warning: 43] Inconsistent shading normals<br></br>
[2010-08-18 17:54:41 Warning: 43] Inconsistent shading normals<br></br>
[2010-08-18 17:54:41 Warning: 43] Inconsistent shading normals<br></br>
[2010-08-18 17:54:41 Debug: 0] Mesh: accel = none (global),
triangles = 7440 wald, quads = 0 quadrilateral<br></br>
[2010-08-18 17:54:41 Debug: 0] Mesh: accel = none (global),
triangles = 12188 wald, quads = 0 quadrilateral<br></br>
[2010-08-18 17:54:41 Warning: 43] Inconsistent shading normals<br></br>
[2010-08-18 17:54:41 Warning: 43] Inconsistent shading normals<br></br>
[2010-08-18 17:54:41 Warning: 43] Inconsistent shading
normals<br></br></em>(-snip lots of that-)

Vaguely related question: Only one (of two) lights imported, and it's apparently situated behind my figure, so she's actually a black silhouette...
Is this a fatality so far, or is there a way to move that light so I can see anything?... I think I recall having seen people getting a "normally" lighted scene.

Oooh - couldn't find float texture Color_Mul_65 is an interesting one.

Poser let's you mix number and color nodes willy nilly. Lux does not. A texture that expects color as an input does not accept a number node, and vice versa. So the converter has to do a lot of extra nodes to cast from number to color or color to number, and it appears I missed a case.

Thanks for the notice - I'll watch out for that.

Sorry about the obvious nodes that should be implemented - Glossy and Noise. I will soon get back to the material converter, but I'm very anxious to integrate the GUI at the moment.

Quote - Oooh - couldn't find float texture Color_Mul_65 is an interesting one.

Thought it might interest you...  :-)

Quote - Sorry about the obvious nodes that should be implemented - Glossy and Noise.

No problem, we know it's a WIP.

That been said, somebody can tell me if the light position problem is a bug, or just a lack of code?

In the meantime I solved my problem by entering additional lights and moving them around myself (in a text editor). Obviously a GUI for doing this would be most welcome...

I loaded V4, clicked a pose, clicked a character morph and texture.  Moved her hand a little.  Loaded floor and wall props.  Thought about lighting.

Since the light export hasn't been refined yet I decided to try and take advantage of the downward pointing lights.  Converted the default Poser lights to spotlights and pointed them straight down, I didn't change anything else.  Moved the lights around and placed scaled and rotated planes under them to act as reflectors in Lux.  It didn't come out quite like I hoped, but I have no complaints.

Went on to move the camera and change render sizes.  Started exporting.  Had to clean up material nodes (as expected) before I got a clean export.  The export only took about 16-17 seconds, I don't think I can even get an obj file out quite that fast.  Had to go back and shift cameras a couple of times to get a match of the view I wanted.  I wasn't surprised by that either because I couldn't remember what cameras were being used.  Once I got that worked I let Lux run for a bit.

Two hours and fifty minutes later I got this image.  This is a raw render from Lux with default render settings.  Once you guys get the exporter done I think it'll be a truly powerful tool and open up a whole lot of possibilities.

adp, bagginsbill, odf, we who are about to render salute you!  ;)

Quote - I don't know if I'll ever use Luxrender as the render times seem gigantic

Depends on what you want to render. There are a few set screws only accessible with a user-interface or inserted by hand.

To get the most out of it one has to become familar with how Lux works. So a scene may be optimized toward Lux, not Poser.

Also keep in mind that the next version of Lux will have support for GPU rendering if you have a capable videocard.  For kicks, I have been trying the beta of Octane, and I am impressed with the speed.  Hopefully Luxrender will match it eventually.

Quote - 3dsMax has a metallic material that I have no idea from where they got it and so, I suppose that is not physically correct, but works fine.

You should add: For me.

Others may want to get images with higher quality. Just because it is possible, at least. And damn cheaper than a max-metallic fake.

Because Lux is open-source.

Quote - Another point is that to be a model physically correct it doesn't mean that it looks correct, it only means that the model obey the conservation of energy and follows the laws of physics.
We must define which are our objectives, what we want to do.
There are many application where 3d engines can be used, architecture, design,engineering, marketing, media, art
For example, radiosity is excellent for illumination design of interiors, but if you post an image in the gallery soon someone will comment that you did the image without shadows, objects are floating above the ground and so on. People want to see shadows even a well designed interior illumination produce no shadows.
You see a beautiful rendering of a house, it is marvelous and the image is excellent, but you and nobody lives in this house and nobody knows where it can be found.
A beutiful rendering of a crystal ball and a metallic sphere, is beautiful, but have you ever found in your life one that looks like that?
Beautiful images, but are artificial and have no life.

Don't turn to a philosophical consideration. Mutch of us do things just because we can. Because it's nice, because it looks professional at the end, add your preferred reason.

We don't ask why. We ask how. And then we do. 

Quote - We don't ask why. We ask how. And then we do.

And you really should know the rest of us are immensely grateful you do too.

Quote -
Caveat: Many users (including me) choose to not have their CG computers connected to internet, there is no reason for this, but several against it (like security and optimization).

No problem at all. The database we plan to use is very flexible. No constrain to have a net-connection. You can download parts and insert what you need into your local database. A bit like you do it now with poser-materials. But you can become a part of a global database, if you want to.

Quote - > Quote - We don't ask why. We ask how. And then we do.

And you really should know the rest of us are immensely grateful you do too.

Intensely grateful even ;o).

Laurie

That's the word I was looking for, Intensely. :D

And now back to the important parts :)

At first let me say: I'm glad and relieved to see you back, bagginsbill. 

Quote -
 Are we serious about using an app server behind the GUI? If so, I'll add support for reading and writing BBML via URL's instead of just files. And I'll add support to send and receive dynamic data via an HTTP request.

Yes, think it would be most flexible. No problems with different Poser versions and platforms.

Quote -

How mature is your server? I have one (Paser) that is very powerful, but never published it.

If you have something ready to go, add it to the project. We need an interface as soon as possible. Regardless of where it comes from.

Modultechnique (kind of objects) has the advantage that any piece can be changed anytime. 

So: go ahead!

Can we have a first version soon?
Would be nice we could publish a usable LuxPose at friday if possible  (name will be changed with this coming version). Sort of Weekend-Toy :)

I assume bagginsbill adds his server. So I can play with something other. Installer and/or database.

Finally managed to figure out why I couldn't get the lighting right, every light points to the centre (0,0,0). There must be a Lux setting to adjust where a light points to, right? :)

Oh, and regarding render times, the attached picture has been rendering for 9 hours now, but actually it looked pretty nice already after 20 minutes. That's the beauty of a luxrender, you can see very quickly how it's going to turn out.

Flenser, did you add the lights by hand into the Lux import files, or did you manage to export them from Poser?

Quote - Flenser, did you add the lights by hand into the Lux import files, or did you manage to export them from Poser?

I exported them from Poser, my trick was to move the lights far away from the centre, so they would spread their light over a larger area.

It's cool to see it being used already.

I've got the lights sorted out. I have the code ready that puts them pointing the right way, both spot and infinite.

I'm working on the GUI at the moment, but very shortly I'll have it all put together. Maybe not seamless yet, but a lot closer.

I'm not going to bother with the server for the moment. You'll just have to push two buttons - one to launch the GUI so you can change parameters, and another to export and render.

When the server is plugged in, the GUI can trigger the export and render automatically. That can come later.

Right now I really want to get the GUI integrated so people don't have to deal with the LuxRender scene file at all.

Quote - I exported them from Poser, my trick was to move the lights far away from the centre, so they would spread their light over a larger area.

Heck, I tried many times, and each time the exporter transformed my colored infinite lights into a single, overhead, slightly to the back, white light...  :-/

Oh well, if BagginsBill implemented the lights GUI it's a moot point.

One tiny question and it doesn't matter when it's implimented, only if ;o).

Will there be a preview window of materials whereby we can make slight adjustments (a preview of how the material will look in LuxRender)?

Not major adjustments of course, just the ability maybe to scale back on gloss or ambience....that sort of thing.

I'm just curious :o).

Laurie

You may have read already that we want to implement a database for use with Poser (not only for Lux-data).

CouchDB is a very flexible, non-relational database available for all important plattforms. If you want to try it out, visit http://www.couch.io/get

If you are interested to lear more here is an online book: "CouchDB: The Definitive Guide"

Quote - One tiny question and it doesn't matter when it's implimented, only if ;o).

Will there be a preview window of materials whereby we can make slight adjustments (a preview of how the material will look in LuxRender)?

Not major adjustments of course, just the ability maybe to scale back on gloss or ambience....that sort of thing.

I'm just curious :o).

Laurie

this would be cool.

the Lux script for blender has a preview window. you push a button and in 10-20 seconds it renders a preview.

Quote - It's cool to see it being used already.

Well it's used since the very first version posted. And once the word spreads and the more timid ones hear it doesn't require a PhD to be used, I'm sure there will be a rush.

Quote - I'm not going to bother with the server for the moment. You'll just have to push two buttons - one to launch the GUI so you can change parameters, and another to export and render.

I fully agree. I don't think pushing two buttons is too difficult, automating that could be postponed all the way to the final polishing; It's about as urgent as skinning.

Quote - Right now I really want to get the GUI integrated so people don't have to deal with the LuxRender scene file at all.

From a users PoV, being able to change render settings and set up lights (and -types) otherwise than by editing the Lux files is indeed the step missing to be able to consider it fully functional for the layman.

Suggestion for the GUI: Would it be possibile to have a small tooltip stating what each parameter does? Copy/pasting from the succinct Lux manual on their site would be fine.
Because I guess there will be a big wave of cluelessness breaking down on most Poser users... :-D

Quote -
 the Lux script for blender has a preview window. you push a button and in 10-20 seconds it renders a preview.

Hey, we would be glad to have a userinterface at all as soon as possible, and you are talking about extended features???????????????

Seriously, yes, but probably late. There are lots of basics with higher priority. Except - someone shouts us a piece of sourcecode we can plug-in (after bagginsbills GUI is implemented).

i just said that blender has one.i dont need a preview for lux.

the preview in poser material room doesnt give me exact info how it will render. but over the years i learned to know how to use it.