Just replace function scene.LightChange() with something.

Fantastic work, you two! I'll try to finalize the geometry exporter tonight, so that I can spend more time playing with what you've implemented.

In a completely unrelated note, I just realized that I can use list comprehensions. I've been avoiding generator expressions since they would not work in Poser 6, which uses Python 2.2. But list comprehensions were introduced in 2.0. Awesome!

Err... carry on.

Quote - In a completely unrelated note, I just realized that I can use list comprehensions. I've been avoiding generator expressions since they would not work in Poser 6, which uses Python 2.2. But list comprehensions were introduced in 2.0. Awesome!

Err... carry on.

Maybe it makes sense to have different versions of some functions? 
Kind of this: if PYTHON_VERSION >= 2.4 : # Fast and memory efficent def topological_order(children): seen = set() result = num.zeros( ... ) ....

    if not v in seen :
      seen.add(v)
    ...

else:
  # remarkable slower 
  def topological_order(children):
    seen = {}
    result = []
    ....

Whoo, fun!  
   I threw together a scene in Poser (I mean, really.  Everything's right 'out of the box'):

   I'm on IDL-bereft Poser 7, so I didn't think it'd be a fair comparison with the Lux render.  So I overlaid that first render with another, where I used an all-white IBL, too (which washed out the background, but that's to be expected):
 

  And the ~10-hour Lux-render: 

Kind of a weird dark outline around the base of her shadow, but gee, I can live with that.  

 I'm interested in how different the color is on her outfit.  The original MAT makes use of diffuse tinting on top of the texture map (which is almost, not quite, all grey), and it looks like it implements that differently in Lux.  Still, wow.  Very exciting!

 I just realized I forgot to reverse the transparency maps on her eyebrows and lashes, so there's kind of a wonky grey area around them.  At least I assume that's why they're grey...

 I'm sure there's a reason the spotlight looks like it's aimed differently, even though the shadow is in the same position, despite that I didn't move it.  I just don't know what it is.  

(And yes, I still use my DAZ Gen2-figures the most, I'm stuck on them!)

Quote - (And yes, I still use my DAZ Gen2-figures the most, I'm stuck on them!)

Huzzah for old-school figures!  No, I'm not making fun here, I'm serious :)

is it normal that after 10 hours of rendering you still see noise?

luxrender can not be that slow. i understand that everything is physical correct and i understand that its realistic. but 10 hours in 2010 can not be right.

there have to be some optimized settings.

Quote - I'm interested in how different the color is on her outfit.  The original MAT makes use of diffuse tinting on top of the texture map (which is almost, not quite, all grey), and it looks like it implements that differently in Lux.  Still, wow.  Very exciting!

First, the material-converter isn't ready yet (BB is hardly working on it).

Second, light in Lux works more real as with Poser. That means every light results in a lot of indirect lighting. Your Poser render has just to much "black" because there is not enough indirect light reflected from the light-gray walls. Poser does not "see" this.

Quote - is it normal that after 10 hours of rendering you still see noise?

I wondered that, too... but it resembles photo-grain; I like it, myself. But keep in mind this is an alpha - if something in the conversion caused it, and it can be optimized, I'm sure these guys will.

 Also, from experience, GI/radiosity in Lightwave (as of 7.5 at least, I'm behind, heh) can leave quite a bit of noise, too. It may just be the nature of the technique? Monte Carlo, is it?

Quote - First, the material-converter isn't ready yet (BB is hardly working on it).

 Hence I'm keeping a "that's interesting" rather than a "that's wrong, oh noes" mindset. I'm just impressed it's doing as well as it's doing, already. Good work!

The spotlight is aimed at 0 0 0 because I haven't released the updates to point the lights where they should be.

Regarding the colors - I haven't fully decided how to handle gamma correction. If you're starting with something that was designed for GC in Poser Pro, it's obvious what to do.

If you're starting with Poser 7 style shaders, it's not so obvious. All incoming colors are supposed to be converted to linear, and that includes those color chips in the nodes. But for the moment, I only linearize the color image map, not the chips. Since as you say there was a gray tint on the cloth, that tint should probably be anti-gamma corrected in the conversion. I have a switch for it in the code, but we need a config file and a GUI to edit it.

I got fed up with YAML, XML, JSON - all are ugly. So I've invented a new super-sweet markup language - BBML. And I'm writing BBML parsers for Python and AS3. And I've already got the ability to define both the data model and the GUI using BBML.

I haven't had much time this week to produce an update. Hopefully soon.

On the left, I have two edit boxes - top is for config data, bottom is for GUI.

On the right, the resulting GUI that comes from what I typed into the GUI BBML. This is what you'd interact with.

On the bottom is a logging output window showing me a dump of the parsed BBML, so I can verify that the data was accurately assembled.

For reference, if it helps, I added GC to all the shaders in the Poser render.  Just to be safe, I removed the GC before I imported it to Lux, so it wouldn't be over-gamma-corrected. 

For the programmers:

Notice in BBML there is almost never a need for quotes, braces, colons, brackets, parantheses - nada.

It reads like an informal human description of what you want, and it works.

The only time you need to use quotes on a string is if you want an = or > character in the text.

Nesting of objects is indicated by indentation, like Python source code.

For the frequent case where you need an object containing just one other object, you can put them on one line with the > character, instead of two lines with the second indented.

Form
  FormItem label=Something you want >TextInput width=60

The equivalent XML would be:

I prefer BBML.

XML needs at least a default value, I think.
A datatype and/or a Lux-parameter name?

Or do I miss the point?

 Is there a beta version of the plugin available already that I could have a play with over the weekend? I would really love to give this a try on some of my scenes.

Thanks

You can try this for the moment: http://www.poserprofis.de/PoserLuxExporter_Alpha

Quote -
 Hence I'm keeping a "that's interesting" rather than a "that's wrong, oh noes" mindset. I'm just impressed it's doing as well as it's doing, already. Good work!

Oh sorry - I understood you correct. I've some problems to express myself in english. My note was more addressed to other readers.

 Thank you ADP!

Can't wait to get home and give it a try.

Quote - I got fed up with YAML, XML, JSON - all are ugly. So I've invented a new super-sweet markup language - BBML. And I'm writing BBML parsers for Python and AS3. And I've already got the ability to define both the data model and the GUI using BBML.

I like the way you think.

If you were my preferred gender, this is where I'd ask you to marry me. :lol:

Quote - is it normal that after 10 hours of rendering you still see noise?

luxrender can not be that slow. i understand that everything is physical correct and i understand that its realistic. but 10 hours in 2010 can not be right.

there have to be some optimized settings.

Depends on the render settings but 10hrs is quite short for a Lux render.  It's very processor intensive.   Once they get the GPU accelerated version running it'll probably help speed it up but so far no physically accurate, unbiased render engine is spectacularly fast - even Maxwell

I once tried a Lux render of a VRay scene (which is in my gallery) and just left it running.  3days later it was still showing grain but I probably hadn't optimised the render settings as much as they could have been.
Render is www.renderosity.com/mod/gallery/index.php
The room is mostly lit by bounced light from the window and there's one light up above the stairwell

Quote - > Quote - In a completely unrelated note, I just realized that I can use list comprehensions. I've been avoiding generator expressions since they would not work in Poser 6, which uses Python 2.2. But list comprehensions were introduced in 2.0. Awesome!

Err... carry on.

Maybe it makes sense to have different versions of some functions? 
Kind of this: if PYTHON_VERSION >= 2.4 : # Fast and memory efficent def topological_order(children): seen = set() result = num.zeros( ... ) ....

    if not v in seen :
      seen.add(v)
    ...

else:
  # remarkable slower 
  def topological_order(children):
    seen = {}
    result = []
    ....

Hmm, I guess that particular example might work, but your strategy still would not allow me to use syntax from, say, Python 2.4 in an older version that does not understand that syntax. In that case, I'd have to put my 2.4-specific code in a separate file and import that file only if the Python version allowed that. That seems quite convoluted, and so I'd only do that for features that gave me a significant speed gain. I don't think that's the case for generator expressions, at least not in this particular project.

But back to list comprehensions (which I can use in Python 2.2). Compare this:

   
odd_squares = [n*n for n in xrange(20) if n %
2]<br></br>

with this:

   
odd_squares = []<br></br>
    for n in xrange(20):<br></br>
      if n % 2:
odd_squares.append(n*n)<br></br>

Any idea which I'd prefer to write?

Of course, there's also this:

    odd_squares = map(lambda n: n*n, filter(lambda n: n % 2, xrange(20)))

which looks quite horrible, but only because Python's syntax is a bit clumsy when it comes to functional programming support. In Ruby, I could write this:

   
odd_squares =
 0.upto(19).select { |n| n % 2 >
0 }.map { |n| n*n }

and in Scala this:

    val
odd_squares = 0 to 19 filter (n => n % 2 > 0) map (n =>
n*n)<br></br>

or this:

    val
odd_squares = for (n <- 0 to 19 if n % 2 > 0) yield
n*n<br></br>

Oh, hey.  I found the noise reduction parameters (which were staring me in the face. :p )   It works pretty well.

Quote - Regarding the colors - I haven't fully decided how to handle gamma correction. If you're starting with something that was designed for GC in Poser Pro, it's obvious what to do.

Gamma correction is not worth to do and it can give wrong results.
Gamma correction was used in old TV stations when TV sets were made with valves.
Today a well calibrated computer monitor is already gamma corrected and LCD monitors don't behave as a cathode ray tube and nothing need to be corrected.

Oh dear! Where are my potato chips?

Quote -
Gamma correction is not worth to do and it can give wrong results.
Gamma correction was used in old TV stations when TV sets were made with valves.
Today a well calibrated computer monitor is already gamma corrected and LCD monitors don't behave as a cathode ray tube and nothing need to be corrected.

uh....

Laurie

oh joy. can we leave that discussion for another time?

I'll have a box of Junior Mints, some Mike and Ike's and a large popcorn. Extra butter.

Laurie

put me down for a large coffee, a muffin and a big bag of plain chips...

Quote -
But back to list comprehensions (which I can use in Python 2.2). Compare this:

   
odd_squares = [n*n for n in xrange(20) if n %
2]<br></br>

with this:

   
odd_squares = []<br></br>
    for n in xrange(20):<br></br>
      if n % 2:
odd_squares.append(n*n)<br></br>

Any idea which I'd prefer to write?

Maybe you want to try this:

import time
import Numeric as num

y=10000000
t=time.time()
os = [n*n for n in xrange(y) if n % 2]
print os[:10]
print time.time()-t

del os

t=time.time()
os = num.arange(1, y, 2)
os=os*os
print os[:10]
print time.time()-t

On my machine this comes out:

[1, 9, 25, 49, 81, 121, 169, 225, 289, 361]

1.99559211731

[  1   9  25  49  81 121 169 225 289 361]

0.107155799866

Which one would you prefer to use?
 

Quote -
Gamma correction is not worth to do and it can give wrong results.
Gamma correction was used in old TV stations when TV sets were made with valves.
Today a well calibrated computer monitor is already gamma corrected and LCD monitors don't behave as a cathode ray tube and nothing need to be corrected.

You are right - if you talk about an image you want to display. This image needs no correction. But, if you want to create this image, you have to watch for gamma.

Quote - Today a well calibrated computer monitor is already gamma corrected and LCD monitors don't behave as a cathode ray tube and nothing need to be corrected.

 
LCD monitors internally apply a non-linear curve so that they can display the same signals as CRT monitors. While natively having a linear response, LCDs have a similar response to CRTs, on purpose.

Quote - is it normal that after 10 hours of rendering you still see noise?

Adding filters helps a lot :)
With GPU support, it would take about 30 seconds to render :)

Quote - > Quote -

Gamma correction is not worth to do and it can give wrong results.
Gamma correction was used in old TV stations when TV sets were made with valves.
Today a well calibrated computer monitor is already gamma corrected and LCD monitors don't behave as a cathode ray tube and nothing need to be corrected.

uh....

Laurie

Sheesh, they just don't get it, do they, Laurie? Why is it so hard to understand? Poser needs linear data to process colour correctly. Has nothing to do with monitor calibration.

Quote - On my machine this comes out:

[1, 9, 25, 49, 81, 121, 169, 225, 289, 361]

1.99559211731

[  1   9  25  49  81 121 169 225 289 361]

0.107155799866

Which one would you prefer to use?

Well, obviously that depends on how long a list I need to produce. Or how many times that code is called. Where efficiency is a real issue, I'd obviously use Numeric. But I'm doing that anyway in my code, so I'm not sure what you're trying to tell me.

By the way, your Numeric version produces an integer overflow on my 32-bit machine. The first one will work no matter how large y gets, just as long as there's enough memory.

Quote - > Quote - > Quote -

Gamma correction is not worth to do and it can give wrong results.
Gamma correction was used in old TV stations when TV sets were made with valves.
Today a well calibrated computer monitor is already gamma corrected and LCD monitors don't behave as a cathode ray tube and nothing need to be corrected.

uh....

Laurie

Sheesh, they just don't get it, do they, Laurie? Why is it so hard to understand? Poser needs linear data to process colour correctly. Has nothing to do with monitor calibration.

I've had to gamma correct every render I've ever done ;o). Either in the render itself or in Photoshop - either way, it has to be done...lol.

Quote - > Quote - > Quote -

Gamma correction is not worth to do and it can give wrong results.
Gamma correction was used in old TV stations when TV sets were made with valves.
Today a well calibrated computer monitor is already gamma corrected and LCD monitors don't behave as a cathode ray tube and nothing need to be corrected.

uh....

Laurie

Sheesh, they just don't get it, do they, Laurie? Why is it so hard to understand? Poser needs linear data to process colour correctly. Has nothing to do with monitor calibration.

A very short explanation.

1- Gamma correction came from the old B&W TV days.
2- TV cameras work in a linear region and have a linear response to light.
3- In those days TV receivers only used cathode ray tubes.
4- A cathode ray tube must work between black and white levels and due to this it has a not linear response to the received signal.
5- To have a linear response the non linear response must be corrected, this was called gamma correction.
6- So each TV receiver must have a gamma correction fitted to its cathode ray tube.
7- TV receivers used valves, no transistors or integrated circuits existed in those days.
8- To make gamma correction it would be make very expensive the TV receivers.
9- So TV receivers were let without correction and the correction was made in the TV station.
10- The amount of correction depend on the cathode ray tube and the level of brightness, so it is impossible for a TV transmitter to make and exactct correction for all receivers.
11- So the correction done by the TV station is only an approximation based on an average value.
12- With color TV the situation became even worst because the cathode ray tube has three cannons, one for each color.
13- The errors of the correction are even worst, because the signal must be received by B&W and color TV receivers.

This were the old days and continue to be in this way for decades. With computer monitors and current technologies things have changed.

14- Today exist integrated circuits and microprocessors.
15- It is possible to make the gamma correction in the monitor and is cheap.
16- The correction is exact because the fabricant can fit the characteristics of the cathode ray tube he is using and also it can track the intensity levels that you use.
15- Computer monitors are not used to watch TV (well...not always true), it are used with linear data, so a good monitor has all the internal correction to output this linear data.
16- LCD monitors even don't need to have this internal correction.
17- Cheap monitors don't have internal correction.
18- Video cards also have a correction that you can adjust, only an approximation because it doesn't fit the cathode ray tube you use and the intensity levels.
19- You can calibrate the monitor so it can have a linear response to signal levels.
20- The correct calibration is with a luxmeter, eye calibration is not correct.

Well, in practice, nobody cares on calibration, each one adjust in a way he/she likes and the same image in different monitors doesn't look the same.

Quote - By the way, your Numeric version produces an integer overflow on my 32-bit machine. The first one will work no matter how large y gets, just as long as there's enough memory.

Numeric allows you to select the needed length for datatypes as you surly knows. This is why Numeric is memory effecient.

Please don't missunderstand me. I don't say anything against your good programming style, surly not.

But Numeric is available for all versions of Poser Python (different versions, but all have at least the basic features; this is where IF VERSION==nn makes sense).

Quote -
1- Gamma correction came from the old B&W TV days.

0-Gamma correction is used long before in printing industry (density allocation; other name, same effect). 

Gamma correction is needed if your input has more colors (better: differences in brightness) as your output medium. A linear correction/interpolation is mathematical correct, but not made for human eyes.

Quote - Please don't missunderstand me. I don't say anything against your good programming style, surly not.

Well, I did not think you were trying to criticize my programming style. I was just confused, because I didn't understand what you were trying to tell me.

Quote - But Numeric is available for all versions of Poser Python (different versions, but all have at least the basic features; this is where IF VERSION==nn makes sense).

Ah, okay! I get it now.

The latest version of my code - which I haven't posted yet - pulls the data out of the geometry object right at the initialization and sticks the vertex and uv coordinates into Numeric arrays. I just did a bit of profiling. At the moment, about two thirds of the runtime are spent in Mesh.add_polygon() and Subgeometry.split_at_vertex_seams(), which contain lots and lots of setdefault() and append() calls. So these are the first places where I'll try to speed things up a bit once I've got the functionality complete.

Quote -
Well, in practice, nobody cares on calibration, each one adjust in a way he/she likes and the same image in different monitors doesn't look the same.

Try to feed your monitor with an HDR-Image linear downgraded to 8 bit RGB. Dosn't look good, right? Now correct and use a Gamma of 2.2. 

Getting an extra large popcorn with extra (real) butter and a large Dr. Pepper

Oh and new snapshots please when time allows....I made a right mess of it when I tried to manually merge some stuff....(teach me to stick to the hardware) or you could just loan me the big brains for a day or so, I'll give em back promise! :biggrin:

I am overwhelmed and depressed with kawecki's near-constant disinformation campaigns.

I am thinking of leaving this thread. It happens over and over.

Kawecki assembles a group of premises (supposedly facts), about a third of which he has completely backwards and wrong. Then we get a "scientific" sounding analysis that is complete bullshit.

I'm tired of dealing with it.

In this thread it started with assertions that Python can't be used for export - exactly what we're doing. Now it's that sRGB colors are linear and do not need to be anti-gamma corrected.

In the underwater scene thread kawecki argued that z-depth, not distance, is the correct approach (it is not) and that a shader implementing distance-based inverse exponential falloff would be too slow (my shader adds 2 seconds to a 2 minute render.) He also said that I would not be able to take into account the effects of depth. I did. Because of the constant arguing, denying what I show to be true, and confusing the issues enough that people conclude stupid things like "even the experts disagree", I abandoned that thread and did not publish my underwater shader.

That was not the only incident. There are dozens of others. Stupid arguing over points that are proven and settled drive me crazy. I can't take the adrenalin this produces in me.

I'm now thinking of abandoning this thread.

ignore him. I know your pain about his crap. I've argued with him a few times... and came to the realization he's not all there. like the time he argued that lighthouses and foghorns can't work... against actual evidence they do...  but since he does not actually break the rules, they won't do anything about him.

don't give up on the work you've done just because his lack of mental stability.

Quote -
I'm now thinking of abandoning this thread.

:::Sigh::: 

PLEASE DONT!

Choose to ignore instead, as painful as it can be to watch bantering, The VAST MAJORITY find your contributions, skills and knowledge :::PRICELESS:::

.02 

Scott 

I've been asking for an ignore button (as have others) for a long time now, but the Powers That Be don't feel it's necessary.

My offer of a nice quiet place where all the programmers (and only the programmers) can go back and forth with no outside interference still stands.

Laurie

I don't think Kawecki means any genuine harm in his posts, it's best to either take them with a large pinch of salt or just ignore them, abandoning everything when you're so close to getting something amazing like this actually working would be a tragic waste of your time & talent up to this point.

Your inbox would collapse under the strain of having 1000s of us emailing you every day pleading with you to get back to work.

Quote - I've been asking for an ignore button (as have others) for a long time now, but the Powers That Be don't feel it's necessary.

My offer of a nice quiet place where all the programmers (and only the programmers) can go back and forth with no outside interference still stands.

Laurie

I've never used the ignore feature on any forum, but I have to agree here if it means BB leaves the project. I don't post much, but ever since the announcement at DAZ about Reality and how he didn't want to do an exporter for Poser users I have been following this thread with great interest! With all the progress that has been made it would be a shame to abandon it. If anything, collaborate offline to avoid any future irritations of which more will surely follow.

Quote - My offer of a nice quiet place where all the programmers (and only the programmers) can go back and forth with no outside interference still stands.

Well, this is starting to look more attractive.