Quote - > Quote - I'm going sailing all day tomorrow.

Sailing huh? I've been sailing since the age of 7...
What are you sailing on?

32 foot O'Day. It belongs to my best friend, who's wife is my wife's best friend. Works out pretty good.

Note - I got up really early (5 AM) to try to produce a release of my newest code for you guys, but I got into another stupid thread with kawecki and aeilkema and now I am really mad, my hands are shaking, and I'm not doing anything.

Just thought I'd let you know what impact the community has on ME, when the community allows a couple individuals to say whatever they feel like saying.

Enjoy your busted LuxPose.

Sorry, odf, but no the error moved.

I change line 146 of poser_extractor.py to "for i, v in enumerate(geom.TexVertices() or []):" to get rid of the first exception, just like you did with geom.TexPolygons() further down. That's a cool approach btw :-)

And then I get this:

File "P:Poser 8RuntimePythonposerScriptsScriptsMenuluxPosepydoughgeometry_export.py", line 65, in write
except TopologyError, message:
NameError: global name 'TopologyError' is not defined

"Just thought I'd let you know what impact the community has on ME, when the community allows a couple individuals to say whatever they feel like saying."

and what can WE do about it? nothing at all. thanks for punishing us as well! we can't stop them (and god knows I've tried!)

so hey. thanks for taking it out on everyone else.

That's not true Kai, you can do somthing and you did.

The mods need to understand that there is more to this place than being "fair" to everyone. Here's my thought - as long as I enjoy interacting here, then I stay. And while I stay, I happen to create a lot of value both for the individuals participating and for the site.

But if I am so fed up that I don't participate, then that value creation stops. And then the community or the authority or both need to fix it.

The mods sometimes think that BOTH parties are partially right, because they believe in fairness and the (uncertain) principle that everybody is entitled to their opinion, especially when it is a subject where the moderator is unable to firmly be certain about the truth.

But this isn't about fairness or uncertain truth. The sRGB standard is written down, and kawecki repeatedly ignores its existance. He says that you don't need to GC if you have a modern monitor. This ignores the reasons that monitor vendors specifically have not made monitors linear.

Since monitors are not linear, but the "rendering equation" is linear, you have to convert data in and data out. This is a simple premise that I can say in one sentence, but instead I have to say in a thousand sentences because kawecki tells people something different, something opposite - he tells them that only old monitors have this problem that needs correction.

It isn't a problem it's a design choice that is a standard. Gamma correction is not a correction at all anymore - it is part of how things work.

Just like camera f/stops are not linear but based on a power function, so is the output of a digital display. He refuses to accept this, and forces me to type about it over and over in a thousand different ways, until it looks like I'm the one being argumentative.

At that point, this whole thing becomes very NOT fun for me. And I'm only here for fun. I do not have any commercial interest in anything related to GC. Having him accuse me of LYING in order to promote PRODUCTS that I do not HAVE is INSULTING. AND I AM PISSED OFF.

I cannot work when I'm pissed off. So this isn't about me "taking it out on all of you". This is about me shaking in my chair, unable to think about code. You have to be in the zone to code well, and I'm so fucking far out of the zone it's not funny.

My point to the community was this: kawecki and aeilkema are part of the community and they make it SUCK for me. If you want me to stay, then you need to discuss the problem of individual trouble makers and FIX it.

Or I will walk for more than a day or two. I'll walk for good. I hope all of you realize this is nothing more than a hobby for me and right now it's not a fun one at all.

I did fuck all.

I have nothing to back up my words. they can just ignore me. and they will as you know. none of us can do anything about it.

we don't have the power. they need to be pulled up (and others) by the staff. but since they are just within the rules that will not happen.

so deal with it or walk it's your choice and it's your ONLY choice but don't be a bloody prima donna.

I was using Lux glass for the windshield.

BB, why do you let yourself get caught up in a stupid argument and then let it ruin you rmood?
Nobody's forcing you to argue. :)

Quote - > Quote - > Quote -

I also think the fireflies point to a fundamental flaw. I don't believe it should be necessary to render 2500 samples in order to get rid of such an obvious rendering artifact. The notion of unbiased rendering as being unable to produce clean results until a huge number of samples is produced is a different notion than unable to produce accurate results until a huge number of samples is produced.

Let me clarify:

Unbiased rendering needs thousands of samples per pixel for accuracy - I agree.

Unabiased rendering needs thousands of samples per pixel to avoid artifacts - I disagree.

I think they have something wrong. If not that, then I think they have been thinking with too narrow a mindset. I think that a clean image should be possible in 50 samples no matter what in the kinds of images I've been doing. There is no refraction or caustic effect, and all light sources are large. With the bidir path integrator, it is easy as pie to find paths from camera to light source, and after 50 such paths, every pixel should be within 10% of its final accurate value.

When I have time, I will look into this problem.

the fireflies problems are bigger then some here are aware.

when you have 2-3 objects with glossy reflections then what can happen and sometimes happen is that the longer you render the more fireflies you get. so basicly what happens is that you dont get a better render with more time but more artifacts.

i have been readign some on google and the creators are aware of the problem but i think they dont know how to fix it. it is free so i can not complain.

Quote - Sorry, odf, but no the error moved.

I change line 146 of poser_extractor.py to "for i, v in enumerate(geom.TexVertices() or []):" to get rid of the first exception, just like you did with geom.TexPolygons() further down. That's a cool approach btw :-)

And then I get this:

File "P:Poser 8RuntimePythonposerScriptsScriptsMenuluxPosepydoughgeometry_export.py", line 65, in write
except TopologyError, message:
NameError: global name 'TopologyError' is not defined

Dang it! Is that a free prop or a commercial one? Because it would be much easier if I could do the debugging myself.

Anyway, if you change line 10 in geometry_export.py to import TopologyError as well, you should see a more useful error message.

odf:
It's a commercial one, otherwise I'd have sent it to you already. It's working after importing TopologyError.

I'd suggest to change line 66 to include the actor the warning is for. I only see "Exporting figure" and then a warning for a parented prop, that's a bit irritating.

Quote - Sailing huh? I've been sailing since the age of 7...
What are you sailing on?

All Me Bloomin life.
If I could get it to float, I could make it move.
While at MMA we used Mercuries and Shields in Phys-Ed and the bigger boats on weekends.

Capt'n Gyles used to hoodwink us into working on the Schooner Victory Chimes
http://www.nps.gov/maritime/nhl/victory.htm

MMA has the Schooner Bowdoin
http://bowdoin.mma.edu/

One of my MMA Classmates was Master of the Gazela Primeiro
http://www.gazela.org/ships/gazela/gazelahistory.htm

After being aboard these you really get a sense as to how life was in the old days of Wooden Ships and Iron men.

I retired last year after almost 40 years At Sea, over 20 as Master.

Now back to attempting some of BB's always challenging, for me, Lighting tactics.from poser to LuxRender.

Quote - odf:
It's a commercial one, otherwise I'd have sent it to you already. It's working after importing TopologyError.

I'd suggest to change line 66 to include the actor the warning is for. I only see "Exporting figure" and then a warning for a parented prop, that's a bit irritating.

At that point I don't know what the actor is anymore. See, I first weld the actors for a figure into a single mesh using Poser's welding information. Then I take that and split it into a separate mesh for each material in the figure. I could add some heritage info to each polygon and pass it along, but that would complicate the code and cost time.

One small problem is that apparently parented props are currently exported twice - once with the figure and once as separate actors. That's why you see those confusing messages. I need to talk to ADP and decide which part of the code is going to be responsible for removing those duplications.

Oh, double export? I didn't even check the output that far :-).
But maybe this is interesting to you then: The warning only appears for the prop when the figure is exported not when the prop itself is exported.

Quote - Here is my second try at the Thunderbolt car, I got the glass working quite a bit better.. this is with the refraction index at 1.1, down from the default of 1.5. The glass became opaque when the index got down to about 0.5.

Can't get rid of those last fireflies.

Sometimes it helps to read the words written of a rival program...lol.

I read (somewhere ;o)) that the fireflies are much more frequent and larger if the rendered pixel approaches pure white. I'm not sure if it's a bug with Lux or what can be done about it. But it sounded logical to me ;o). I'll have to go back over what i'd read to get the exact explaination ;o). But it had something to do with pure white, that I'm sure of ;o).

Laurie

Quote - Oh, double export? I didn't even check the output that far :-).
But maybe this is interesting to you then: The warning only appears for the prop when the figure is exported not when the prop itself is exported.

Yes, things are starting to make sense now. If a figure has UVs and there's a prop parented to that figure that doesn't, the exporter still tries to create one single mesh out of those with the UV polygons matching the polygons for the geometry, which obviously it can't. When the prop gets exported separately, the UV data is simply noted as missing, and all processing related to it is skipped.

In this light, it would probably be best to exclude parented props from the figure export and let the separate prop export take care of them. I'd have to think a little more about the best way of dealing with potentially existing figures that have UVs on some actors but not on others. I'm not quite sure how Poser would handle that. Maybe I'll do some testing.

Quote - > Quote - Here is my second try at the Thunderbolt car, I got the glass working quite a bit better.. this is with the refraction index at 1.1, down from the default of 1.5. The glass became opaque when the index got down to about 0.5.

Can't get rid of those last fireflies.

Sometimes it helps to read the words written of a rival program...lol.

I read (somewhere ;o)) that the fireflies are much more frequent and larger if the rendered pixel approaches pure white. I'm not sure if it's a bug with Lux or what can be done about it. But it sounded logical to me ;o). I'll have to go back over what i'd read to get the exact explaination ;o). But it had something to do with pure white, that I'm sure of ;o).

Laurie

Unless black is close to pure white, I may disagree.  Actually, it could be that the pixel that caused one of my fireflies was near to pure white, though it should have been black.  This is a known issue at Lux, and they are taking steps to make it better; though I don't know if they will completely get rid off all fireflies.

Quote - I got into another stupid thread with kawecki and aeilkema and now I am really mad, my hands are shaking, and I'm not doing anything.

:-/

What about putting this project in its very own, dedicated frame, instead of having 2-3 ragbag threads?

With a friend we've put our wallet where our mouth is and registered a domain name, LuxPose.org, and set up a dedicated forum. Anybody having web skills (LuckDragon seemed interested) is welcome to build an actual site (PM me, I'll give you FTP access to the server).

The forum is already functional.
I didn't set up a wiki engine yet, because I don't want to spend any time if nobody is interested. (The forum, the hosting and the domain were set up with my friend in 15 minutes, we don't intend to spend more if everybody prefers to stay here.)

The main question is, are you people interested to have a dedicated LuxPose site and forum, or do we keep floundering in the Poser forum here?...

adp001, bagginsbill and odf, contact me to get  @luxpose.org  e-mail addresses, POP or forward...   :-D

Quote - > Quote - I got into another stupid thread with kawecki and aeilkema and now I am really mad, my hands are shaking, and I'm not doing anything.

:-/

What about putting this project in its very own, dedicated frame, instead of having 2-3 ragbag threads?

With a friend we've put our wallet where our mouth is and registered a domain name, LuxPose.org, and set up a dedicated forum. Anybody having web skills (LuckDragon seemed interested) is welcome to build an actual site (PM me, I'll give you FTP access to the server).

The forum is already functional.
I didn't set up a wiki engine yet, because I don't want to spend any time if nobody is interested. (The forum, the hosting and the domain were set up with my friend in 15 minutes, we don't intend to spend more if everybody prefers to stay here.)

The main question is, are you people interested to have a dedicated LuxPose site and forum, or do we keep floundering in the Poser forum here?...

adp001, bagginsbill and odf, contact me to get  @luxpose.org  e-mail addresses, POP or forward...   :-D

I and another person have a discussion forum and we offered pretty much the same thing. People seem to prefer to stay here. So my suggestion would be not to waste any more of your time because everyone will just stay here anyway ;o).

Laurie

Quote - I and another person have a discussion forum and we offered pretty much the same thing. People seem to prefer to stay here. So my suggestion would be not to waste any more of your time because everyone will just stay here anyway ;o).

Yes, I know, human inertia... That's why we left it to the basics; Losing 15 minutes and $40 is something we both can live with.  :-D

But this project will need a website soon, when thousands of users start flooding in and asking (mostly the same) questions.
The initial thread contains much interesting (even vital) information, but it's impossible to use unless you read through the whole thing. This thread here will eventually grow as big, and will die too, and its information will die with it.
We need stickies, FAQs, not to mention separation of dev/bug discussions, usage questions, and casual chat.

Quote - > Quote - I and another person have a discussion forum and we offered pretty much the same thing. People seem to prefer to stay here. So my suggestion would be not to waste any more of your time because everyone will just stay here anyway ;o).

Yes, I know, human inertia... That's why we left it to the basics; Losing 15 minutes and $40 is something we both can live with.  :-D

But this project will need a website soon, when thousands of users start flooding in and asking (mostly the same) questions.
The initial thread contains much interesting (even vital) information, but it's impossible to use unless you read through the whole thing. This thread here will eventually grow as big, and will die too, and its information will die with it.
We need stickies, FAQs, not to mention separation of dev/bug discussions, usage questions, and casual chat.

Well, if it helps, we've started a FAQ on the wiki page, a wishlist, some basic info about the project and I'll filter back thru each thread and consolidate as much of that on the wiki as I possibly can. I'm disabled and not working, so it's not like I don't have the time for that and since I can't contribute much else, I'll do what I can to keep the wiki updated. Now that Dizzi was kind enough to get something started that I'm capable of maintaining, I'll do it to the best of my ability. The link to the wiki is now in my signature, so anyone who sees my sig will also see the link ;o).

The truth of the matter is that I agree with you, but the sad fact of reality is that people will tend to stay here on the site rather than migrate somewhere else.

Laurie

Actually, i would prefer a separate website.  The people working on LuxPose would have better control over the forum, for instance.  Although the wiki here is good, providing it is updated.  Though it is still in a third parties hands. 

I also agree that there should be separation of dev and general posts.  If this was set up on a new site, it could be that only the devs would have post priviledges on a particular thread, or sub-group, while everyone else could be read-only. 

Just my .01 worth.  (Inflation, bah!)

Quote - ...If this was set up on a new site, it could be that only the devs would have post priviledges on a particular thread, or sub-group, while everyone else could be read-only. 

Just my .01 worth.  (Inflation, bah!)

They have that already...lol. For the most part, they prefer to post here in the open forums ;o).

Laurie

 FYI - I made this a sticky, and added the links to the first post to the questions thread, the wishlist, and the original thread :)

A million thanks ;o)

Laurie

"TextureReferences().ResolveReferences()":

• for Poser 6 references are usually correct after rendering (P4-engine), so a Dialog asking if this should be done pops up and renders if the user agrees (only if there's incorrect references).  
• for Poser 7/8/Pros: "scene.ResolvePendingTextures()" is used

Checking if "TextureReferences().GetWrongTextureReferences()" contains elements might be useful to warn the user about incorrect references before exporting.

YAYYYY!!!

Laurie

I must admit to never having opened up the other Lux thread.

I viewed the videos about Lux and I must say that I'm very impressed.

I spent months and months doing nothing but lights in Poser 6 in order to understand them, and while I have not mastered them, I can say that for the most part I do my own lighting now inside Poser, which is something that I never thought I'd do.

With Lux, it seems that lighting may become less of a bane and will not only help those of us who have some understanding on how to create lights in Poser, but will certainly make it easier for those who don't, to create their own lighting.

I can't wait to see where this goes for Poser!

Quote - Nah, I'm getting it too in Poser 8 on my 32 bit system ;o). It's occurred to me that it's contained to Poser 8 and 2010, since users of earlier versions don't seem to be having the problem.

Laurie

I added something that tries to get the render-dimensions from the actual Poser window using wxPython (P8/2010 only, code contributed by Dizzi).

I didn't change the version number. You only need to replace the file "PoserLuxExporter_workers.py" in folder "workers" with the new one from the zip.

Quote - The Catmull-Clark subdivision wish is about having it in accessible in the GUI I think.

This, and/or make it accessible via a parameter.
Suggestion:
doCatMul=parameter.get(actor.InternalName(), dict()).get("CC", False) 

The problem I get is shown in the image attached. On the left is the Poser render and on the right is the LuxRender render. The file is exported to the same dimensions (checked in the .lxs file). The LuxRender one appears to be 'zoomed out' a little bit.

Have no idea if this is to do with the render dimensions but it has done it for each file I have exported in all versions of the alpha.

Poser 8, SR3, Display units = Feet

Made a simple scene in Poser Pro 2010: This green thingamajig is exactly 800x600 and fits tightly in the preview/render frame. In the background there is a big red sphere fitting in the inner frame, allowing to check for perspective changes.

Could it be there is a shift in the camera position?

rty - glad someone was able to be more scientific than me :)

The calculation of the camera fov must be off, if I manually adjust the fov I can get back to the view I have in Poser.
 

Quote - > Quote - The Catmull-Clark subdivision wish is about having it in accessible in the GUI I think.

This, and/or make it accessible via a parameter.
Suggestion:
doCatMul=parameter.get(actor.InternalName(), dict()).get("CC", False) 

There's already the parameter 'subdivisionlevel'. For example, to export with two levels of Catmull-Clark subdivision applied to each geometry, I simply add the following to my dataOut.bbml file:

Geom<br></br>
    subdivisionlevel=2<br></br>

(Caution: the export will take a long time that way. Minutes instead of seconds.)

I haven't looked into the bbml code for specifying the interface, but it should be easy to add the corresponding lines, so that this value could be set within the GUI.

The geometry exporter doesn't care how properties are assigned to particular actors. Once you've implemented per-actor or per-figure parameters in the wrapper, simply set the correct value in the option object that's passed to GeometryExporter().

Quote - > Quote - > Quote - The Catmull-Clark subdivision wish is about having it in accessible in the GUI I think.

This, and/or make it accessible via a parameter.
Suggestion:
doCatMul=parameter.get(actor.InternalName(), dict()).get("CC", False) 

There's already the parameter 'subdivisionlevel'. For example, to export with two levels of Catmull-Clark subdivision applied to each geometry, I simply add the following to my dataOut.bbml file:

Geom<br></br>
    subdivisionlevel=2<br></br>

(Caution: the export will take a long time that way. Minutes instead of seconds.)

I haven't looked into the bbml code for specifying the interface, but it should be easy to add the corresponding lines, so that this value could be set within the GUI.

The geometry exporter doesn't care how properties are assigned to particular actors. Once you've implemented per-actor or per-figure parameters in the wrapper, simply set the correct value in the option object that's passed to GeometryExporter().

Fine!

I'm going to make it working.

odf, are you in the mood to look into the camera thing? 

The methode how the fov is computed seems not correct.

        focal = cam.Parameter("Focal").Value()

        fov = 360 / pi * atan(12.75 / focal)

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

Quote -
Fine!

I'm going to make it working.

Don't know how to instruct the GUI to read available Figures/Actors/Props so one is able to select the Catmull-Clark option :(

I'll drop this for a while. Nobody but me seems to need it at the moment, I guess.

Quote -
Here is the Lux export. As you see the perspective remained the same, but there is now a lot of space around the green thingamajig.

Could it be there is a shift in the camera position?

Thanks for showing this. Can you make this setup available for testing?

Quote -
The methode how the fov is computed seems not correct.

        focal = cam.Parameter("Focal").Value()

        fov = 360 / pi * atan(12.75 / focal)

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

 

What if Lux's camera (lens) zeropoint is not the same as in Poser ??? Using Posers cam.WorldDisplacement() as we do actually then fails.

(the whole code for the camera is in file workers/camexport.py)

The camera works perfectly fine for me. If someone could tell me how to reproduce the problems some people had on my machine, I might have a chance of fixing it.

But the lights are completely messed up in the latest version. Someone apparently "fixed" the gains. Now the lights are incredibly weak and my whole image is full of fireflies. BB used to have a pretty large factor applied, which I never understood, but which seemed to work fine with reasonable settings for the linear tone mapping.

This is no fun. If things that used to work fine keep breaking at random with no apparent reason, I'll have to write my own wrapper and work with that.

Changing line 324 in PoserLuxExporter_workers.py to the following seems to have fixed the lighting issue for me:

            print >> file, ' "float gain" [%s]' % (self.gain * (1000 * BBLuxMat.DIRatio))

Quote -
This is no fun. If things that used to work fine keep breaking at random with no apparent reason, I'll have to write my own wrapper and work with that.

No, no fun. I messed up with this lights. The multiplicator for gain should come in several lines before so it can work with all light types. I deleted it but didn't add it above.

Fixed.

As it turns out, the extreme firefly problems I've encountered were not related to the lights at all. Here's what Lux produced after five minutes. This is Antonia in her beach volleyball outfit again, with the Poser 8 studio backdrop and two spotlights.

Edit: I've stopped the render after 5 minutes. The dimensions were 963x963, but the image was so noisy that I had to scale it down for posting.

Here's the exact same scene as above, also stopped after 5 minutes, but rendered with this new binary. I think the result speaks for itself.

BTW: I tried to use one of the weekly builds, but there were some dependency problems, so that recompiling seemed the easiest way. That may not be the case under Windows.

Perhaps you can try another Integrator. Path, for example.

Quote -
BTW: I tried to use one of the weekly builds, but there were some dependency problems, so that recompiling seemed the easiest way. That may not be the case under Windows.

This is good news! Any rumors about a fresh release?

A bug fix release would definitely be nice. But I haven't been following the forums, so I don't know.

Forgotten to mention:

The actual Exporter exports lights into a seperate file with extension .lxl
It's easier to edit if one wants to play with the lights.

Quote - It was mentioned that the current official LuxRender release had a bug which was fixed in more recent, unofficial builds. So after this frustrating experience, I decided to recompile LuxRender from the current source code and see if there were any differences.

Here's the exact same scene as above, also stopped after 5 minutes, but rendered with this new binary. I think the result speaks for itself.

BTW: I tried to use one of the weekly builds, but there were some dependency problems, so that recompiling seemed the easiest way. That may not be the case under Windows.

Is that something the general public can use or do you have to be a programmer to get it to work? ;o)

Laurie