Quote -
Background is a skyglobe without a skyglobe, just with the following at the very end in file ".lxo" ;

AttributeBegin

Transform [1 0 0 0  0 1 0 0  0 0 1 0  0 0 0 1]

LightSource "infinitesample"

 "string mapping" ["latlong"]

 "color L" [1 1 1]

 "float gain" [300]

 "integer nsamples" [1]

 "string mapname" ["tex/Factory_Catwalk_Bg.jpg"]

AttributeEnd

One additional spot is used to get some shadows.

The background image is a "latlong" map I found somewhere on the net. Don't remember where. But you can find a some in your Poser texture folder under HDRVFX. For spherical images in there replace "latlong" above with "spherical".

Rendertime 35 minutes.

Ah that's cool. So I can use that type of light for IBL images as well, I think, using the "angular" mapping.

How did you know about the light type "infinitesample"? Now that I went looking for it in the Lux source code, I see it, but it wasn't in the scene file format documentation. How is it different from "infinite"? (Not Poser infinite, I mean the Lux light type.)

Congratulations to all, its great to see a group of people come together to pull this off.

odf,

I don't think it has anything to do with the objects, I'm starting to think it has to do with my files.  I figured out which objects in each scene seemed to be the cause of the crash and so far in new scenes none of them cause crashes.

I've had each of the items (props or figures) in other scenes, including brand new ones I did today and had no problems.

Since I can't get the same problem when I create a new file, I'm guessing that either my Poser scene file is some how being corrupted during the save and load process and passing problems along, or something else on my system is causing problems.  My system always seems to wind up doing strange and unexpected things.  So for now I'm going to kick my computer in its exhaust fan and watch some mind numbing television. ;)

Looking forward to the next step you guys take with this, seeing you do this is fascinating and just plain fun.

I'm loving the sunsky light.
This rendered for 9 hours.

Quote -
How did you know about the light type "infinitesample"? 

I had to know the difference between infinite and distance light. So I looked into the source.

Quote -
How is it different from "infinite"? (Not Poser infinite, I mean the Lux light type.)

"infinite" in Lux is exactly what it is in Poser .

"infinitesample" is using the image like a "skyglobe" does. Additionally the same image is used to lit the scene. The difference here between Poser and Lux: For IBL in Poser only a small image is required. A skyglobe needs a very large one.

Adding a texture to an infinite light should give the same effect as in Poser (with small probes).

I've not mutch time at the moment, so I'm not able to test so mutch. I don't know yet what exactly the difference between distance and infinite light is.

Quote -  
I'm loving the sunsky light.
This rendered for 9 hours.

Because your image seems to be overexposed, lowering "gain" for the light may also put the rendertime down. I think 9 hours is to mutch for this scene (not against you, just trying to make clear somebody should make a list with  "what option when" and "how to - go for speed").

Quote -
Because your image seems to be overexposed, lowering "gain" for the light may also put the rendertime down.

Doesn't the exposure depend on the tone mapping?

I remember BB explained at some point why he used such a large factor to translate Poser light strengths into Lux gains, but I can't quite recall what it was.

 It rendered for 9 hours because I turned it on this morning before going to work. :)

I ran a few test renders last night on the same scene getting the sun direction and camera position right and they were acceptable quality within 30 minutes.
The overexposure is on purpose, gain is already low at 0.04 but I cranked the fstop down to all the way to 0.7, exposure at 1/250, iso at 80.

LOL, I think I'd have a mental block against using an fstop that low. The fastest lens I've ever had could go to 1.4 at most.

I have to admit I find the overexposure a bit irritating, as well.

adp do you have in your link the updated script? with bagginsbil's updates from yesterday?

does the GUI already work automatic?

Quote -
It's not lol...Linear and 600/400 render size ;o). Notta workin' ;o).

Laurie

I am wondering if where we placed the files and installed it from could possibly have anything to do with it.
Like you, I have LuxPose installed and it opens and appears to run correctly. yet I do not see that it affects the eported file.

I used the Poser 8RuntimePythonposerScriptsPoserLuxExporter_alpha_1-10eAIR Folder and ran the LuxPose.air file from there.

Did you do the same?

Using WinVista HP 64 Bit and the 64bit LuxRender.

There must be something simple that we have done differently from those who have it working for them????

Maybe you're right, mariner.

The script looks in the path where it is started from for a folder with name "AIR" for the datafile written by the GUI.

If you installed the GUI to some other place the datafiles are not found by the script.

You can check this to be shure: Make some change via GUI. Then look into the datafile at AIR/LuxPose/data/dataOut.bbml if something is changed in the file after you pressed OK in the GUI.

Quote - adp do you have in your link the updated script? with bagginsbil's updates from yesterday?

does the GUI already work automatic?

Bagginsbill has decided to use his own script independently from what is published here. Some irelevant snippets where posted here, the "kernel" not.

Or did I miss something?

I'm sorry for not posting my latest yet. I have a few more final touches to add.

My previous posts were just progress reports.

i thought you guys are working together?

are you  3 now working seperate?

Quote - i thought you guys are working together?

are you  3 now working seperate?

Hey, you should be grateful that we don't work against each other.

Incompatible timezones, nothing to be done about it.

They may be separated by timezones & wide spots of water but they're working to a common goal.

I am unhappy with the AIR installer. I want everything pre-installed in the LuxPose folder.

I have found through experimentation that when you "install" the GUI using the .air file, it produces a binary executable that is identical regardless of which application it is. The application is actually in a .swf file and the .exe runs that. The .exe knows which to run from an xml file also deposited in the application folder.

I have found that I can update the application just by replacing the .swf file. There is no need to completely re-install.

Further, I have found that there are a few other files deposited in the app folder that are not needed, and that I can delete those.

Further, I have found that I can copy the remaining few files and subfolders and put them anywhere I want and the application runs just fine.

So what I'd like to do is to avoid the .air file and instead just put already prepared files in the LuxPose folder.

I have no problem doing this for Windows, since that's what I'm on, so I can assemble the package. But for Mac or Linux, I need the assistance of somebody who has already installed the LuxPose UI on those systems.

The AIR installer asks you where to put the application, and the default it c:Program FilesLuxPose. In there the files I things I needed for Windows are:

LuxPose.exe - the executable
LuxPose.swf - the actual Flex application
META-INF - a folder with metadata about the application - necessary for it to run
META-INF/AIR -
META-INF/AIR/application.xml
META-INF/AIR/publisherid

This is what I will use to create the pre-assembled LuxPose GUI for Windows. I will put this stuff in the package.

I believe that a Linux package would be similar, with a different binary for the .exe file. But I suspect the Mac package is a different beast.

Now I know that Mac apps are not really files, but magical folders of some kind. I'm assuming that instead of LuxPose.exe, there is something else, and that the other files are the same.

I don't know how to go about assembling a pre-assembled Mac or Linux application from what is deposted after you run the .air installer. If somebody wants to have a go at figuring that out, that would be great. I'm worried that I can't make this work on Mac, though, because I suspect that the application itself uses the data fork/resource fork mechanism that Macs have, and that I won't be able to distribute that stuff properly in a zip file built from my Windows machine.

In the meantime, I think what I'll do is include the AIR file for non-Windows users and they'll just have to run it and install the actual application back into the LuxPose folder. I worry, though, that this users will ignore instructions and deposit the app in the wrong folder. I really want to find a way to do this automatically.

Once I have the GUI pre-packaged in the LuxPose folder tree, we will no longer have to configure paths for the GUI to find the data and for the Python to find the GUI. Everything will just be relative paths and require no info from the user.

The last little things I a need to learn is:

• In Python, find out if I'm on Windows, Linux, or Mac. I will use that info to decide what the name of the GUI application actually is. It is LuxPose.exe only on Windows.
• How to launch the application in those other environments. I'm assuming that spawnl will work. I'm using spawnl in Windows just fine. But the Python docs on spawnl say "Availability: Unix, Windows". This worries me, as it implies it is not available on Mac OSX. Is that just a typo? Does spawnl work in Linux and Mac?

Quote - i thought you guys are working together?

are you  3 now working seperate?

ice-boy, we are working together, and I'm using a lot of code that adp and odf wrote.

But we do not have a boss, and so we must make decisions by committee. I'm not used to that, and I have some peculiar demands in coding style. I can't stand typing a lot and I hate code that is less simple than it could be. Therefore, I decided to rewrite certain parts.

As a result, my exporter framework is much smaller and easier to follow than what adp wrote, and while his works, it doesn't work in a way that I find comfortable to modify.

Once adp and odf have a chance to look at what I've done, they can decide to use it, or keep going with some other approach. It's not a big deal either way.

But my setup already has the ability to pre-export data in preparation to use the GUI. adp's does not. This means that the exporters are "prepared", producing information (a lot of information) in bbml files which are passed to the GUI. This is necessary, for example, to allow you to browse all the materials and interactively override the shaders or shader parameters in the GUI. Then the GUI passes back all the choices (of which there are literally thousands). This information must then be given to the exporters to mediate what they do. I have all this implemented in very simple code. Writing an exporter no longer involves producing a class and writing multiple methods, each of which has to say self.parameters.get(...) a billion times. My exporters are "modules" not "classes". Further, the data of interest to the exporter module is already poked into its global name space, and already in real object format, not just strings. So an exporter wanting to know if xyzEnabled is true simply says:

if xyzEnabled

instead of

if self.globalParameters.get('xyzEnabled', 'false') != 'false'

There are other differences. Any one of these may be subtle, but when every single line of code ends up being 30 characters longer than it needs to be, I get irritated beyond belief.

This is no indictment against adp. Please don't misunderstand me. I have a unique style that requires that I write the smallest possible solution, and that I do not add anything unnecessary to a framework. So I felt I had to produce a new framework, or I'd go insane.

Believe me, once I have one of my frameworks set up the way I like, adding new things goes lightning fast.

Some other differences in my exporter:
 

• Each exporter produces a "section" of the lux scene file. Mine can put these in separate files or all in one file, or any combination.
• If a section is in its own file, my exporter can update just that file. This means you can make changes in the GUI and re-export just the materials or just the lights or just the render settings, and skip the time-consuming export of the geometry.
• My exporter will shortly (and transparently) support presets, where the data for a particular exporter comes from a pre-defined file instead of from the dataOut.bbml. Individual exporters don't need to know about this.
• My exporter can display the contents of a section on the console or pop it up in a text editor, as it is being created.
• My exporter will let you save the scene file where your Poser scene file is instead of burying it in the "toLux" folder.

Oh WOW!!! :b_drool:

Quote -
The last little things I a need to learn is:

• In Python, find out if I'm on Windows, Linux, or Mac. I will use that info to decide what the name of the GUI application actually is. It is LuxPose.exe only on Windows.
• How to launch the application in those other environments. I'm assuming that spawnl will work. I'm using spawnl in Windows just fine. But the Python docs on spawnl say "Availability: Unix, Windows". This worries me, as it implies it is not available on Mac OSX. Is that just a typo? Does spawnl work in Linux and Mac?

I'll start with these and may experiment with the AIR stuff later. I find the installer rather annoying myself.

Anway, Python has the os.name attribute, which does not tell you the name of the operating system itself, but the name of the operating system specific module that was imported. On Linux (and supposedly on MacOS as well, but I haven't tested that) the value is 'posix'. Under Wine, I get 'nt', which I suppose is also the value under Windows. I'll keep investigating. Hopefully, there's some way of distinguishing between Linux and MacOS.

MacOS uses a BSD kernel, which means that basically, the Apple-specific stuff is piled on top of a Unix system. So all the basic Unix functionality will still work. Executable files can be installed and executed normally, as long as they're compiled for MacOS. But there's also a special packaging system, which I am not familiar with. If AIR uses that, we'll have to call in an expert. Otherwise, we might be able to feel our way. I have access to Apple computers at work, so I could do some testing if necessary. But I'm sure there are quite a few genuine Mac people reading this thread as well, so I may still be spared from that.

Ah, Stackoverflow had the answer:

    import platform<br></br>
    platform.system()<br></br><br></br>

That gives me 'Linux' when I run python natively, and 'Windows' under Wine. I don't know what the value will be on Macs, supposedly something like 'Macos' or 'MacOS'.

*"That gives me 'Linux' when I run python natively, and 'Windows' under Wine. I don't know what the value will be on Macs, supposedly something like 'Macos' or 'MacOS'."

'StevieBaby<3OS"

Quote -
This is no indictment against adp. Please don't misunderstand me. I have a unique style that requires that I write the smallest possible solution, and that I do not add anything unnecessary to a framework. So I felt I had to produce a new framework, or I'd go insane.

Believe me, once I have one of my frameworks set up the way I like, adding new things goes lightning fast.

Seems to me you didn't get the point of what my code is good for, I guess. Sorry.
Calling it "framework" may be missleading. 

This type of frameworks gives anybody a chance to follow the code, even a few years later. Simple because if a parameter is requested, this is clear to see because the codeline says it. Yes, a lot more of typing - but only for me. And I'm pretty fast with Python-code typing using Aptana.

odf and you, or any other person writing "worker parts", could completly ignore the framework. Just write with your own style what should happen to say export a light as a lib to include. But write it indepent from other modules because they may change. This is the guarantee to have a good chance the code will work if anything other changes. The framework is there to feed your code with some parameters (in which form ever). Actually the framework does a .

And yes, it would make sense to have a few global functions for common things. How to translate mesurement form Poser to Lux for example. Or do vector-operations.

Also whitout offending anybody, but if you had concentrated yourself on the material-exporter or the GUI the project where a few steps ahead. More samples would exist and more people where involved if the GUI where published. How to install it or how the exported format looks like isn't important. We just need a bit code to glue anything together (easier if standards where used like XML for example).

By the way: My parameter class is able to write BBXL and XML files since a couple of versions. And it is usable as dictionary or as an object with attributes. Without the need to do do something. 

Ok, what I want is the exporter is useable as fast as possible - regardless of how. What I dream of is a flexible open project able to grow and easy to maintain from nearly anybody with a bit know-how.

And now I have to be off for a while, because I have some important things to do. I'll be back tomorrow (european time).

Quote - Some other differences in my exporter:
 

• Each exporter produces a "section" of the lux scene file. Mine can put these in separate files or all in one file, or any combination.

Oh boy. This is something we talked about very early. This is the reason why we distribute the parameter "file" and do print >> file, "another string to output to a file or stream".

The worker parts must not know where output goes to. The workers just have to write to "file". This is part of the framework from the first testversion.

You just reinventing the wheel.
But go ahead.

Quote -  It rendered for 9 hours because I turned it on this morning before going to work. :)

I ran a few test renders last night on the same scene getting the sun direction and camera position right and they were acceptable quality within 30 minutes.
The overexposure is on purpose, gain is already low at 0.04 but I cranked the fstop down to all the way to 0.7, exposure at 1/250, iso at 80.

If you adjust the gamma under linear you can also get the image toned down. Just play around (I've been doing it for days....lol).

Laurie

Thanks for the information . I may have cured the problem, atleast for me.

1. Uninstalled LuxPose.

2. Deleted the folder that BB mentioned

3. Moved the LuxPose.air File out of the Poser 8RuntimePythonposerScriptsPoserLuxExporter_alpha_1-10eAIR folder to the Poser 8RuntimePythonposerScriptsPoserLuxExporter_alpha_1-10e folder.

4. Looked at the dataOut.bbml

5. Ran LuxPose and made changes

6. Looked at dataOut.bbml  file again and yes there were changes.

7. Used your PoserLuxExporter_alpha_1-10e Python Exporter.
   No changes when I opened LuxRender.

8. Ok, this time I deleted your generated poserscene_alpha 1.0.3.lxs File from the Poser 8RuntimePythonposerScriptsPoserLuxExporter_alpha_1-10etoLux Folder.

9. Ran your PoserLuxExporter.py script

10. Opened LuxRender

11. opend the New poserscene_alpha 1.0.3.lxs File

12. Voila!!!! - It now works for me.

Interested to see "IF" this works for Laurie

Quote - Maybe you're right, mariner.

The script looks in the path where it is started from for a folder with name "AIR" for the datafile written by the GUI.

If you installed the GUI to some other place the datafiles are not found by the script.

You can check this to be shure: Make some change via GUI. Then look into the datafile at AIR/LuxPose/data/dataOut.bbml if something is changed in the file after you pressed OK in the GUI.

I can see points on both sides of the argument, er discussion (BB and adp)...

I hope you fellas can come to an accord and make it all work smoothly :o).

Laurie

Quote -
Thanks for the information . I may have cured the problem, atleast for me.

1. Uninstalled LuxPose.

2. Deleted the folder that BB mentioned

3. Moved the LuxPose.air File out of the Poser 8RuntimePythonposerScriptsPoserLuxExporter_alpha_1-10eAIR folder to the Poser 8RuntimePythonposerScriptsPoserLuxExporter_alpha_1-10e folder.

4. Looked at the dataOut.bbml

5. Ran LuxPose and made changes

6. Looked at dataOut.bbml  file again and yes there were changes.

7. Used your PoserLuxExporter_alpha_1-10e Python Exporter.
   No changes when I opened LuxRender.

8. Ok, this time I deleted your generated poserscene_alpha 1.0.3.lxs File from the Poser 8RuntimePythonposerScriptsPoserLuxExporter_alpha_1-10etoLux Folder.

9. Ran your PoserLuxExporter.py script

10. Opened LuxRender

11. opend the New poserscene_alpha 1.0.3.lxs File

12. Voila!!!! - It now works for me.

Interested to see "IF" this works for Laurie

Quote - Maybe you're right, mariner.

The script looks in the path where it is started from for a folder with name "AIR" for the datafile written by the GUI.

If you installed the GUI to some other place the datafiles are not found by the script.

You can check this to be shure: Make some change via GUI. Then look into the datafile at AIR/LuxPose/data/dataOut.bbml if something is changed in the file after you pressed OK in the GUI.

I can see I'm going to need some more coffee....brain fog has set in....lmao.

Laurie

Quote - The last little things I a need to learn is:

• In Python, find out if I'm on Windows, Linux, or Mac. I will use that info to decide what the name of the GUI application actually is. It is LuxPose.exe only on Windows.
• How to launch the application in those other environments. I'm assuming that spawnl will work. I'm using spawnl in Windows just fine. But the Python docs on spawnl say "Availability: Unix, Windows". This worries me, as it implies it is not available on Mac OSX. Is that just a typo? Does spawnl work in Linux and Mac?

Anything you need to know about the system a scipt is running on can be discovered using module "platform". Down to the processortype or the exact os version.

[http://docs.python.org/library/platform.html

](http://docs.python.org/library/platform.html)

Quote - > Quote - Some other differences in my exporter:

 

• Each exporter produces a "section" of the lux scene file. Mine can put these in separate files or all in one file, or any combination.

Oh boy. This is something we talked about very early. This is the reason why we distribute the parameter "file" and do print >> file, "another string to output to a file or stream".

The worker parts must not know where output goes to. The workers just have to write to "file". This is part of the framework from the first testversion.

You just reinventing the wheel.
But go ahead.

Well, yes, you have print >> file and you can pass any file to the exporter worker.

But, first thing I don't like is the exporter worker has to use print and format everything itself. Second, there is no provision for printing things out of order, which is sometimes necessary.

In my framework, there is a 'lux' object. This is a smart wrapper around files or other stream-like objects. It maintains a stack of streams, so you can push a new stream on it, write some stuff, and pop the stream.

Anybody can use print >>lux or lux.write(...) but this is not the most convenient approach.

Instead, the lux object understands a lot of methods.

To push a new scene sub-file, you say:

lux.pushFile('foo.lxx')

This automatically inserts an Include directive into the current output file which will include foo.lxx. Then it opens the foo.lxx file and pushes it on the output stack. When you're done with that subfile, you call lux.pop() and the file is closed. If a filename has a path it will be used, otherwise the output folder of the current file before pushing is used.

To push a new file without "including" it, just call lux.pushFile(filename, False). To just push an arbitrary stream call lux.push(stream). This stream will not be closed. To auto close it on pop, calls lux.push(stream, True).

As I said, you can format everything yourself, but that is error prone and is a lot of typing. Instead, the lux object has a special attribute setter. Assigning any attribute to it that is not one if it's own existing attributes is assumed to be a request to put a lux-style property.

For example, to set the camera field of view, instead of:

print >> file, ' "float fov" [%s]' % fov

I write:

lux.fov = fov

That does the same thing, because fov is a float.

To set the camera autofocus, instead of:

print >> file, ' "bool autofocus" ["%s"]' % gp.get("autofocus", "false")

I write:

lux.autofocus = autofocus

Lists and tuples are automatically examined to see what is inside, and the type is set from that. But sometimes a tuple can be a float vector, a color vector, a vector vector, etc. So there are easy ways to specify.

For example, instead of:

print >> file, '   "color L" [%s %s %s]' % tuple(self.color)

I write:

lux.color.L = color

To copy a bunch of values, you can use the method lux.copy.

Instead of:

            print >> file, ' "bool autofocus" ["%s"]' % gp.get("autofocus", "false")
            print >> file, ' "integer blades" [%s]' % gp.get("blades", 6)
            print >> file, ' "string distribution" "%s"' % gp.get("distribution", "uniform")
            print >> file, ' "integer power" [%s]' % gp.get("power", 1)

I write:
lux.copy(section, 'autoFocus', 'blades', 'distribution', 'power')

There is no need to specify types in this case because the actual values are already typed as bool, int, or string.

Whenever any of these setter methods are used, the values passed in are automatically transformed via the function s2lux. This converts True to "true", False to "false", etc. Also for strings, lux wants no spaces and all lower case, so it does that. For the rare case where you have a string that you do not want converted, you say:

lux.someProperty = literally(someValue)

To start a new lux object, you use the .typeof attribute like this:

lux.typeof.LightSource = 'spot'
lux.typeof.Camera = 'Perspective'

In the rare case where you really have to manually format something, you can just call lux and it works like C's printf.

lux('someOddThing [%.02d %02d %02d]n', a, b, c)

There are many other helper functions. With this scheme I stopped making errors in formatting, or forgetting what the type was supposed to be and, for example, printing a float when I wanted an integer or a bool.
 

I want to add support for a pull-down menu to choose a realistic camera profile.

The lux documentation says:

Quote - LuxRender contains camera data for a small number of cameras; these can be chosen as a preset. It is also possible to supply your own camera model if you happen to have this information available as a .dat file.

Where are these? I don't see any in the LuxRender application folder.

Did they mean LuxBlend, not LuxRender?

What is it what stops you to use what you like inside your "worker" lib? Look how odf did it. You just have to make sure your output goes to "file". That's all.

Splitting things up insteed of having one monolitic piece of code is required to follow one of the basic ideas: Try to make Poser compatible with other render engines. Not only Lux.

So the steps: Output one light, output one material, etc. is required if we want to follow the basic requirements. Beside of that, is just a good coding style.

If you look for a Lux python module there is already one you could inherit:

http://www.luxrender.net/static/pylux/

This is also required to feed Lux in realtime.

But really, I mean you should concentrate on the materials and probably the GUI.

 (Just to make it clear - my last posts ar meant friendly)

Quote - I want to add support for a pull-down menu to choose a realistic camera profile.

The lux documentation says:

Quote - LuxRender contains camera data for a small number of cameras; these can be chosen as a preset. It is also possible to supply your own camera model if you happen to have this information available as a .dat file.

Where are these? I don't see any in the LuxRender application folder.

Did they mean LuxBlend, not LuxRender?

Name the camera "realistic camera". Here are the specs:

realistic camera

As its name indicates, the realistic camera is the camera type that most closely matches a real photographic camera. The difference between this camera and the ordinary perspective camera is that the realistic camera calculates the way light is distorted by the lens, whereas the perspective camera uses a much simplified camera model that resembles a pinhole camera. Hence, the realistic camera is capable of showing lens characteristics like barrel distortion and vignetting. LuxRender contains camera data for a small number of cameras; these can be chosen as a preset. It is also possible to supply your own camera model if you happen to have this information available as a .dat file.

#### field of view

The lens data file of a realistic camera corresponds to a camera with a certain focal length. However, the program can generate a similar lens with a different focal length (and thus field of view) by scaling the lens data.

#### film size

This value indicates the size of the diagonal of the camera film in millimeters.

#### film distance

This value indicates the distance between the film and the backmost lens element. Changing this to a different value than the default for the lens will result in an image that is out of focus.

#### aperture

The depth of field can be influenced by setting the aperture of the camera. The values correspond to the ones found on a real photographic camera; lower values result in a shallower depth of field.

#### camera data file

The realistic camera can use one of the four preset cameras, or it can use a user provided .dat file. Such a file needs to be in the file format as indicated in the paper by Kolb, Mitchell, and Hanrahan.

#### focus distance / shutter / clipping

These settings work the same way as the perspective camera settings.

I had to wait for my chauffeur. But now I'm really off :) 

Quote - I can see points on both sides of the argument, er discussion (BB and adp)...

I hope you fellas can come to an accord and make it all work smoothly :o).

Laurie

No worries, Laurie. I'm trained to build teams out of individuals. Means: I have a thick skin and I'm very flexible. odf is someone sitting back and grin ;)

The top rule here is: Make it happen. And make it soon.

Quote - What is it what stops you to use what you like inside your "worker" lib? Look how odf did it. You just have to make sure your output goes to "file". That's all.

Nothing. I'm using odf's geometry worker exactly as it is. I didn't rewrite that.

Quote - Splitting things up insteed of having one monolitic piece of code is required to follow one of the basic ideas: Try to make Poser compatible with other render engines. Not only Lux.

But that's exactly one of the motivations I had for rewriting a bunch of stuff. You have many of the workers in one big file. I have each in a separate file, and all they have in them is stuff that actually exports. There is nothing in them that does any kind of book keeping or parameter gathering. That's all done before they get called by a common class called Exporter.

Furthermore, the Exporter class is not specific to Lux. It is designed to wrap any package of exporters, regardless of what they are for. It will take care of instantiating each module, setting up all the data properties, managing the subfiles, etc. It has nothing whatsoever to do with LuxRender. It only has three parameters to make it work for any target renderer. These parameters are the package name, the exporter name, and the name of the master output file wrapper (in this case, 'lux').

Quote - So the steps: Output one light, output one material, etc. is required if we want to follow the basic requirements. Beside of that, is just a good coding style.

But this is not news. That's how I did it. I don't know what you're getting at here, especially since you haven't seen the code yet.

Quote - > Quote - I want to add support for a pull-down menu to choose a realistic camera profile.

The lux documentation says:

Quote - LuxRender contains camera data for a small number of cameras; these can be chosen as a preset. It is also possible to supply your own camera model if you happen to have this information available as a .dat file.

Where are these? I don't see any in the LuxRender application folder.

Did they mean LuxBlend, not LuxRender?

Name the camera "realistic camera". Here are the specs:

realistic camera

As its name indicates, the realistic camera is the camera type that most closely matches a real photographic camera. The difference between this camera and the ordinary perspective camera is that the realistic camera calculates the way light is distorted by the lens, whereas the perspective camera uses a much simplified camera model that resembles a pinhole camera. Hence, the realistic camera is capable of showing lens characteristics like barrel distortion and vignetting. LuxRender contains camera data for a small number of cameras; these can be chosen as a preset. It is also possible to supply your own camera model if you happen to have this information available as a .dat file.

#### field of view

The lens data file of a realistic camera corresponds to a camera with a certain focal length. However, the program can generate a similar lens with a different focal length (and thus field of view) by scaling the lens data.

#### film size

This value indicates the size of the diagonal of the camera film in millimeters.

#### film distance

This value indicates the distance between the film and the backmost lens element. Changing this to a different value than the default for the lens will result in an image that is out of focus.

#### aperture

The depth of field can be influenced by setting the aperture of the camera. The values correspond to the ones found on a real photographic camera; lower values result in a shallower depth of field.

#### camera data file

The realistic camera can use one of the four preset cameras, or it can use a user provided .dat file. Such a file needs to be in the file format as indicated in the paper by Kolb, Mitchell, and Hanrahan.

#### focus distance / shutter / clipping

These settings work the same way as the perspective camera settings.

What was the point of this post? I asked where I can get the .dat files that are supposed to be included with LuxRender. This post is just a full copy of the very page I quoted earlier.

I've marked in big letters the part I already quoted and asked about.

Quote - I want to add support for a pull-down menu to choose a realistic camera profile.

The lux documentation says:

Quote - LuxRender contains camera data for a small number of cameras; these can be chosen as a preset. It is also possible to supply your own camera model if you happen to have this information available as a .dat file.

Where are these? I don't see any in the LuxRender application folder.

Did they mean LuxBlend, not LuxRender?

http://src.luxrender.net/lux/file/f98eef13b6d6/cameras/realistic

You can grab them from the source repository. The LuxRender app does not include them probably because it is up to the exporters to make use of them.

Yay, oh yay! Dynamic cloth goes over just fine BTW for those interested ;o)....

happy dance

Laurie

Good to know, Laurie! Thanks for testing it.

Kevin

thank god that there is no problem with dynamic cloth

i am not good with computers and folders. so i think i will whait with the testing when it will be easier to open Luxpose gui.

Quote - thank god that there is no problem with dynamic cloth

i am not good with computers and folders. so i think i will whait with the testing when it will be easier to open Luxpose gui.

I will be ready soon with it. I have it so you launch the GUI from Poser. Then you stay in the GUI all day. From there you click to perform the export (partial or full), launch LuxRender, or do both with one click.

Quote - > Quote - I want to add support for a pull-down menu to choose a realistic camera profile.

The lux documentation says:

Quote - LuxRender contains camera data for a small number of cameras; these can be chosen as a preset. It is also possible to supply your own camera model if you happen to have this information available as a .dat file.

Where are these? I don't see any in the LuxRender application folder.

Did they mean LuxBlend, not LuxRender?

http://src.luxrender.net/lux/file/f98eef13b6d6/cameras/realistic

You can grab them from the source repository. The LuxRender app does not include them probably because it is up to the exporters to make use of them.

Aha! Thank you so much. I already have the source. I will include the dat files in LuxPose.

just a quick post to say thank you, bagginsbill.  especially since you seem to be handling materials and materials choices in a very usable and flexible manner.

My first sample image (nothing special ,but hey, its a just a test)
I hope I do this right , I probably won't.

Quote - Its ALIIIIIIIVE, I got it to work by changing the tonemapping to reinhardt/Non-linear. Thanks for the help. This script is wonderful. It was a pain to convert surface shaders to Blender/Luxblend to render with Lux from poser export. This is a dream come true.

My first sample image (nothing special ,but hey, its a just a test)
I hope I do this right , I probably won't.

You can do it with linear too. Everyone thinks you can't for some reason...lol. All you need to do is adjust your exposure and gain ;o).

Laurie