Quote - what the f*ck happened to the wiki. thats a bloody incoherent mess.

What's incoherent about it? Do you have some suggestions for improvements?

It looks quite clearly structured actually, IMHO.

Quote - > Quote - what the f*ck happened to the wiki. thats a bloody incoherent mess.

What's incoherent about it? Do you have some suggestions for improvements?

It looks quite clearly structured actually, IMHO.

I agree. It describes quite clearly what LuxPose is, what it isn't, outlines caveats, how to obtain and make it work, plans for the future and a wishlist.
Perfectly coherent to me, and thanks for your work on it, Laurie (and Bagginsbill?)...

Side note: a few more days, and I'll be back in Oz... can't wait to give this a whirl and see it spin... :biggrin:

Quote - It's my first try at Lux Render.  Loaded scene and such, and says there were texture problems and can't load the nodes (so I take it as a work in progress).  While in Lux, I get a black and white picture so I assume it didn't take the textures nor nodes.  Oh well, I'll check back for updates.

ADP patched BB's original code so that instead of crashing immediately, when the exporter comes across material nodes that can't yet be handled, they are instead reported. Unfortunately there seems to be no simple way to ignore those nodes and still get a usable material out of it. That's why you often get black objects in those cases.

You have more or less the following two options at this stage: either start with whatever materials you have and simplify them by removing and bypassing the problematic nodes until you end up with something the exporter accepts, or you could go the other way, start with something very, very simple (think Poser-4-style materials) and gradually add more nodes to them. Either way, you'll probably have to do some work in the material room.

Some just wanted to make it clear as crystal that this script is in no way ready to load and start making pretty pictures ;o). Some of us (like me) may have contributed to this wrong idea by posting whole scenes. What we probably should have stressed is that the textures used were dumbed down in order to convert them. No gloss, no reflections, no nothing ;o).

Laurie

I think the wiki caveat does a great job at explaining what cannot be expected of this project at this stage, Laurie. Your images are mouth-wateringly stunning examples of what is already possible (with a bit of work adjusting materials and lights and whatever). Please don't stop posting them: they fuel the imagination and excite a burning desire to try something new.

This is actually a good thing.

Quote - Oh, looks like the 1.13 version doesn't fix the exceptions when TexPolygons() or Polygons() returns None and doesn't resolve textures :-(

Sorry about that! Line 169 of geometry.py should read

        if self.tpolys and
self.tverts:<br></br>

instead of just

        if
self.tpolys:<br></br>

It's fixed in the github version now.

Edit: Sorry, not quite! I just noticed that the subdivision function also has a problem with partially missing UVs.

Quote -  
Oops, sorry! I thought we had that fixed. Unfortunately, I'm off to work in five minutes, but I'll look into this first time tonight. Are you getting essentially the same exceptions as before, or new ones?

I guess I'll have to start timestamping my pydough code or something, so you can quickly check if you're getting the latest version or not.

Well, the problem in unimesh.py are those we discussed before, in addition I now have a object with no Polygons() instead of no TexPolygons(), so it needs an additional fix, too ;-)

Quote - Ok, here is the scene I was previously having problems with before I used the last weekly build of Luxrender. I apolgize for the size, but it had to be small enough for me to upload here ;o). It's still a bit noisy, but as you can see, the fireflies are gone. Before, I was getting huge gobs of fireflies streaming out from the sunlit side of the fountain as well as in a few other places. Nothing now :o).

The dress on Angela is one of mine and is dynamic and that went over just beautifully too :o).

Laurie

i also have huge fireflies problems. i have the official 0.7 version. i think i downloaded it when you all started working on LuxPose.

so please can someone give me the link to the newest version where they fixed the fireflies? because this is just insane. the render makes so many artifacts that its an insult.

thank you .

@ ice-boy, I'm using the weekly builds found on the luxrender forums. Try this link www.luxrender.net/forum/viewforum.php. You may have to be logged into the forums thou. I have a Win XP system and I'm using the win CVS builds (2nd topic on the forum page in the link). Version SSE2 works fine for me.

People asked about the skin material I used in the render on Page 6. Here it is. The first three blocks are what the material converter produced from a very simple Poser material (just the texture map plugged into the base node with some settings for diffuse color and strength and such). Obviously, the two scale nodes could be combined into one, but I couldn't be bothered.

The last three blocks replace the final block from the converter. The line starting with "color Kt" in the "mattetranslucent" block determines the translucency, a.k.a. next best thing when we don't have SSS. This is already toned down a bit from what I used in that last render. I'm rendering the new version as we speak and will post it once it's cooked a little bit longer.

#----->  
Antonia-126/skin_BODY    <-----<br></br><br></br>
# Image_Map<br></br>
Texture "ImageMap_14" "color"
"imagemap"<br></br>
"string filename"
["/home/olaf/Antonia/Contrib/SF-TonyPolygon/Runtime/Textures/!SaintFox/ToniPolygon/ToniPBody.jpg"]<br></br>
"float vscale" [-1.0]<br></br>
"float uscale" [1.0]<br></br>
"float gamma" [2.2]<br></br><br></br>
Texture "Color_Mul_20" "color"
"scale"<br></br>
"color tex1" [0.945097982883 0.972549021244
0.972549021244]<br></br>
"texture tex2" ["ImageMap_14"]<br></br><br></br>
Texture "Color_Mul_19" "color"
"scale"<br></br>
"texture tex1" ["Color_Mul_20"]<br></br>
"color tex2" [0.583333333333 0.583333333333
0.583333333333]<br></br><br></br>
MakeNamedMaterial "Antonia-126/skin_BODY/mt" "string
type" ["mattetranslucent"]<br></br>
"texture Kr" ["Color_Mul_19"]<br></br>
"color Kt" [0.25 0.1 0.1]<br></br>
"float sigma" [0.5]<br></br><br></br>
MakeNamedMaterial "Antonia-126/skin_BODY/gl" "string
type" ["glossy"]<br></br>
"texture Kd" ["Color_Mul_19"]<br></br>
"color Ks" [0.15 0.2 0.25]<br></br>
"float uroughness" [0.236836278392]<br></br>
"float vroughness" [0.236836278392]<br></br><br></br>
MakeNamedMaterial "Antonia-126/skin_BODY" "string
type" ["mix"]<br></br>
"string namedmaterial1"
["Antonia-126/skin_BODY/mt"]<br></br>
"string namedmaterial2"
["Antonia-126/skin_BODY/gl"]<br></br>
"float amount" [0.1]<br></br><br></br>
######################<br></br>

BTW, I think I've fixed the problem with the partially missing UVs. Obviously, more testing will be needed, but I can now export a figure with a parented prop that has no UVs, both "as is" and subdivided.

As usual, the code can be found under http://github.com/odf/pydough. Knowing ADP, it should soon find it's way into the "official" package.

Quote - @ ice-boy, I'm using the weekly builds found on the luxrender forums. Try this link www.luxrender.net/forum/viewforum.php. You may have to be logged into the forums thou. I have a Win XP system and I'm using the win CVS builds (2nd topic on the forum page in the link). Version SSE2 works fine for me.

The weekly builds for Luxrender (Windows) are here.

Laurie

Heh.

Here is a bit of a chuckle for you folks.
Relish the irony.

The problem some folks are having with their LuxRenders is what?

Fireflies, right?

What is Poser's Render Engine called?

It's not a problem, its another render engine!  You can quote me. ::biggrin::

The problem is fixed in the latest weekly build ;o)

Laurie

the problem is not fixed in the latest build.this is after 4 minutes. after 1 hour thee would be fireflies everywhere.

Well ice-boy. I don't think you can make an assumption after only 4 minutes. I tried the latest build with the worst scene for fireflies that I had and I got absolutely none.

Laurie

Quote - Well ice-boy. I don't think you can make an assumption after only 4 minutes. I tried the latest build with the worst scene for fireflies that I had and I got absolutely none.

Laurie

Just following this with no means to test for myself: can I infer from this, Laurie, that one can expect the odd firefly whilst rendering, but that they are transient and eventually go away? Just asking...

Laurie .
with every 30 seconds the render shows more fireflies. they will not go away.

you said you tryed iwth the worst scene for fireflies. did you try glossy materials? i have a glossy floor with a glossy sofa and a car shader on the sphere. i get fireflies.

maybe it can be fixed. but fact is that i have the latest buid,a simple scene,simple materials and simple lighting. i get a lot artifacts.

but they will fix it.

Quote - > Quote - Well ice-boy. I don't think you can make an assumption after only 4 minutes. I tried the latest build with the worst scene for fireflies that I had and I got absolutely none.

Laurie

Just following this with no means to test for myself: can I infer from this, Laurie, that one can expect the odd firefly whilst rendering, but that they are transient and eventually go away? Just asking...

Well, early in the render I got some large white pixels, but they eventually rendered out.

Laurie

Thanks Laurie... 

I switched from Mitchell to Gaussian pixel filter and I have no more of those hot white dots.

(Forgot which of you gave me that valuable tip, but thanks again.)

Patience. I'm at work, and being slammed by developers who can't tie their own shoe laces, so I can't do my usual of pretending to be working for pay while actually working on LuxPose.

Tonight I am going to knock this code out if it takes all night.

I will also include reference scenes so we can all start with the same test cases. That will help identify what is being done by one person and not by another that leads to a different outcome.

could someone please post the code snippet for Gaussian filter? i've been using 'sinc' with fair results (whoever posted that, thanks).

PixelFilter "sinc"
   "float xwidth" [4.000000]
   "float ywidth" [4.000000]
   "float tau" [3.000000]

Has anyone else had this happen?
windows Vista HP 64 bit
Poser  = ver8 SR3
LuxRender = luxrender_CVS_250810_x64
PoserLuxExporter_alpha_1-13

The Poser Scene Exports Fine with no errors.
LuxRender opens the poserscene_alpha 1.13.lxs and renders.

Here is where the problem happens.
I click on "Stop Current Rendering"
The I click on "Copy Rendering Image to Clipboard"

LuxRender Crashes and closes.
The Copy to clipboard never happens.
I can render for 20 minutes or 2 hours, it makes no difference.

Quote - BTW, I think I've fixed the problem with the partially missing UVs. Obviously, more testing will be needed, but I can now export a figure with a parented prop that has no UVs, both "as is" and subdivided.

As usual, the code can be found under http://github.com/odf/pydough. Knowing ADP, it should soon find it's way into the "official" package.

**Updated
**

Quote - could someone please post the code snippet for Gaussian filter? i've been using 'sinc' with fair results (whoever posted that, thanks).

PixelFilter "sinc"
   "float xwidth" [4.000000]
   "float ywidth" [4.000000]
   "float tau" [3.000000]

PixelFilter "gaussian"
"float xwidth" [1.5]
"float ywidth" [1.5]

Or whatever numbers you want. Gaussian looks a little blurry.

NOTE: I switch over to 64-bit on the weekend, using my new Windows 7 machine with Intel I7 860, and saw no more fireflies when I used the LuxRender latest weekly build. But just to be sure, I just downloaded the SSE2 onto my XP box and they are still there, even with the gaussian filter.

I could be wrong, but I think we're seeing a LuxRender bug here tied to processor architecture.

So who do I have to kill to get the unimesh.py fixed? ;-)

thank you, much appreciated.

i'm using XP & honestly can't see much difference in the fireflies on either build, so you may be on to something.

Quote - So who do I have to kill to get the unimesh.py fixed? ;-)

Laurie

If it helps anyone, my proc is an Intel DualCore. I'm not getting fireflies, not even with SSE2.

Laurie

Quote - > Quote - So who do I have to kill to get the unimesh.py fixed? ;-)

Laurie

Oh... Typo... I meant convince/contact/bribe/... ;-)

Where is BB's "Wish List" Located please?
I would like to add the ability to change the "Number of Threads" used in the LuxRender.

TKS

i should add i use 32-bit XP. that may be the difference?

Intel DualCore here too.

Quote - Where is BB's "Wish List" Located please?
I would like to add the ability to change the "Number of Threads" used in the LuxRender.

TKS

There should be a thread here called LuxPose Wishlist.  There is a link to the post on the first post of this thread.

The ability to change the Number of Threads in LuxRender is already there.  You need to look closer to the interface.

Quote -

the problem is not fixed in the latest build.this is after 4 minutes. after 1 hour thee would be fireflies everywhere.

Are you using portals for the windows? 
Or have you tried to change the lighttype?

Quote - > Quote - > Quote - So who do I have to kill to get the unimesh.py fixed? ;-)

Laurie

Oh... Typo... I meant convince/contact/bribe/... ;-)

The new lib from odf does not contain this file anymore. 

Quote - > Quote -

the problem is not fixed in the latest build.this is after 4 minutes. after 1 hour thee would be fireflies everywhere.

Are you using portals for the windows? 
Or have you tried to change the lighttype?

i am using portals on the windows. i changed the lighting and i changed the settings.
i will whait until we have the test scene where we will all use the same models and lighting. then we can compare.

Just for reference, I also had a massive firefly problem with the official 0.7 release but the last weekly release fixed it.  I'm also running a 64 bit Windows 7 system.

Quote -
The new lib from odf does not contain this file anymore. 

You're right. looks like it crept in from another folder which had another version installed (even got moved into a brand new folder).

Well, at least now I get another Empty collection for odf to fix :-):
RuntimePythonposerscriptsScriptsMenuluxPose_1_13pydoughposer_extractor.py", line 132, in collect_data
for i, v in enumerate(geom.WorldVertices()):
TypeError: iteration over non-sequence

Quote - > Quote -

The new lib from odf does not contain this file anymore. 

You're right. looks like it crept in from another folder which had another version installed (even got moved into a brand new folder).

Well, at least now I get another Empty collection for odf to fix :-):
RuntimePythonposerscriptsScriptsMenuluxPose_1_13pydoughposer_extractor.py", line 132, in collect_data
for i, v in enumerate(geom.WorldVertices()):
TypeError: iteration over non-sequence

Hey! Are you sure you didn't feed the script with donuts insteed of geometries? :) :)

Just a heads up!

Apparently the DS/Reality users are also having the same issue with cameras and rendered scenes not matching what was exported.
Someone posted screenshots of what was in a DS window and what came out in Reality/LuxRender and the R/LR render displayed more of the scene as if the camera zoomed out to take in more of the scene. There were elements in the R/LR scene NOT present in the DS render.

Perhaps the LuxRender cameras are off?? Images at the bottom of page 56 in the "Extra-Reality: a new level of realism" thread Daz Commons.
http://forum.daz3d.com/viewtopic.php?t=146680&postdays=0&postorder=asc&start=1100

I only post this here because there seems to be the same issue with LuxPose.

If I use two V4 with different textures, both of them will have the same texture in Lux.
Is this error located in the geometry- or the material-exporter?

Quick, hide the code to export the camera correctly!

Oh... we can't delete posts here, too bad ;-)

I thought the camera export problem was already solved (the code is in this thread), it's just not in the code yet... At least I have it working :-)

Quote - If I use two V4 with different textures, both of them will have the same texture in Lux.
Is this error located in the geometry- or the material-exporter?

Oooh - that should not happen. I will check on that later today. As long as you pass different keys for the figures into the mat converter, you should get different instances of the materials with different textures. When calling the mat converter with figure parts, it should be passing the figure name + the actor name, so there is more than one head, chest, etc. If it is only passing the actor name, then that is bad as they will all have the same key.

Quote -  If it is only passing the actor name, then that is bad as they will all have the same key.

Can I take this as: Must be the geometry part? I assume yes :)
I'm going to look at ...

Bagginsbill,

This is how materials are converted:

print >>file, self.convert_material(mat, self.mat_key)

A control print for mat and self.mat_key shows:
MAT <Material object at 0x044F2DA0> Victoria4 1
...

    and
MAT <Material object at 0x044F2390> Victoria4
...

So the figurename is given. 

Quote - If I use two V4 with different textures, both of them will have the same texture in Lux.
Is this error located in the geometry- or the material-exporter?

How does the code name exported materials ?
It should be using the figure/prop name to distinguish otherwise the same named materials (probably as a prefix), so the answer is that you're going to need to fixup both the geometry and material exporters.

Quote - > Quote - If I use two V4 with different textures, both of them will have the same texture in Lux.

Is this error located in the geometry- or the material-exporter?

How does the code name exported materials ?
It should be using the figure/prop name to distinguish otherwise the same named materials (probably as a prefix), so the answer is that you're going to need to fixup both the geometry and material exporters.

Materials are exported this way.

MakeNamedMaterial "Victoria41/1_Nostril" "string type" ["glossy"]

I removed the black in "Victoria4 1" already, but nothing changed. All materials are exported. But Lux renders both with the same material.

Can't search further because my day starts early tomorrow.

The mat converter takes the key passed in from whoever is calling it. It doesn't make its own names. If you already asked for the key before, it returns the existing material it wrote before, even if it was not the same material. If you pass a different key, even for the same material, it creates a new copy.

I'm still at work so cannot look at the script. Printing self.mat_key tells us nothing because maybe it isn't used. Certainly the material is not called Victoria 4. It must be concatenated with the material name. If it is just passing the material name, then that is why you do not get separated materials for the two figures. You have to check if the call to the mat converter is actually receiving the concatenated name.

[Edit] Cross-posted with your last post adp. I'll look at it later.

The only material that didnt come out was the hair (Black base map only)
2 infinite lights and one point light.
V3 GND2 morph (who says Poser models arn't good enough for Physically Correct lighting.)
I did let it render for 20 hours hopeing for a complete blending of the fireflies, but they are still present and new ones seemed to come up in the later hours. Definitly a Lux Bug.

Im more than pleased with the pipeline access of this script now, I cant imagine the possibilies when its complete.
I cant say thank you enough for your hard work.