oh great
thats going to be a MAJOR issue then.
so right now there's nothing I can do about it.. shrug the 'giu' does nothing right now here...

Reinhard tonemapping...left it run overnight, about 8 hours. Bi-directional.

I know she's a bit "shiny" ;o). I just wanted some gloss on there because ice-boy mentioned he thought it was gloss that might be causing the fireflies. I have all the time in the world to learn how to  make her skin look better when the exporter is done. Right now, I'm not really going for perfect ;o).

Laurie

I'm changing my code to make at least the setting in dataOut.bbml work for now. I'll also add some code to compute dihedral angles for a mesh, so that the exporter can come up with educated guesses as which objects to compute normals for and which ones not.

okay. fixed the GUI Issue.

even when the GUI was removed totally, uninstalled and removed from my Roaming, it would fail to work when reinstalled.

I found the issue to be it was defaulting to where I first way back when I tested the GUI for BB when he first asked us to.

that was in D:Luxpose DebLuxPosedata
except it now needed to be in D:PoserSmith MicroPoser ProRuntimePythonposerscriptsscriptsMenuLuxPoseAIRLuxPosedata

not sure where it got the default to the first path from.

I manually changed the path in Prefs.bbml and it's working fine now

*Quote - "Now common advice says that the diffuse component should be at most around .8. So what does that mean? It says that whatever spot you're looking at will be .8 times the luminance of the light.

But think about that. If you render this object from some viewpoint, you see roughly 80% of the light luminance coming from the object. 80% of the light is bouncing towards this camera position. Now move the camera and render again. Here, too, 80% of the light is bouncing towards this new camera position. How can this be? If 80% went to the old position and 80% is also going to the new position, then 160% of the light is going to these two positions collectively. That's impossible, right?

In fact, if you mounted a thousand cameras in a hemisphere around this object, you'd find that all of them are getting 80% of the light. What does that actually mean?"

*Light will be hitting the object from all directions. Only some rays (or some photons within a ray) will be reflected towards any one camera. Each camera is receiving 80% of the light that would have been reflected in its direction had the surface been 100% reflective. Your second camera is receiving 80% of the potential light too, but it will come from different light rays than those that are reaching the first camera.

You have the old 'if a tree falls in a forest when there's no-one there to hear it, does it make a sound' conundrum going on here. If you have no cameras at all, is there now 0% of the light going anywhere? And if you had 10 people in the forest, would that make the sound 10x as loud because the aggregate of the sound waves reaching everyone's ears would be 10x that reaching the ears of just one person?

Quote - > Quote - turn what off now? and how? if you mean the banding? thats the light not the cube.. thats come in fine...

The banding is not the light. It's the exporter computing per-vertex normals for the cube when it shouldn't. Not your fault.

If bbml files worked in ADP's framework as bagginsbill intended, you would be able to turn that off for the whole scene if you put something like the following in your dataOut.bbml file:

Geom<br></br>
    compute_normals=false<br></br>

I'll patch my code to accept string options, since that is all I can get from the framework as it stands.

Another alternative would be not to weld the faces of the cube.

Im on the way to make the "normals" feature a part of the actual GUI.

can you do that by object tho....?

Quote - > Quote - > Quote - turn what off now? and how? if you mean the banding? thats the light not the cube.. thats come in fine...

The banding is not the light. It's the exporter computing per-vertex normals for the cube when it shouldn't. Not your fault.

If bbml files worked in ADP's framework as bagginsbill intended, you would be able to turn that off for the whole scene if you put something like the following in your dataOut.bbml file:

Geom<br></br>
    compute_normals=false<br></br>

I'll patch my code to accept string options, since that is all I can get from the framework as it stands.

Another alternative would be not to weld the faces of the cube.

Im on the way to make the "normals" feature a part of the actual GUI.

Excellent! My patched code is now on github. Any value for 'compute_normals' that's false according to Python's rules turns the normal off, plus the strings '0', 'false' and 'False'.

ETA: Kaibach, I'll try to get some per-object guesstimate going tomorrow night. Probably something along the lines of the average or maximal angle between polygons. Time for bed now.

Quote -
Excellent! My patched code is now on github. Any value for 'compute_normals' that's false according to Python's rules turns the normal off, plus the strings '0', 'false' and 'False'.

Udated, new version 1-14a

GUI contains now switches to turn on/off normal re-computing for (all) figures and/or (all) props.

Because the GUI has no connection to Poser, setting this individually per figure/actor/prop isn't possible yet.

I'm really sorry I'm taking so long, but the refinements I'm doing are really important in my opinon.

Here's what I've done so far:

The entire system is housed in a self-contained LuxPose Poser runtime. A user simply unzips it and adds it to Poser. There is nothing to install, configure, or in any way otherwise prepare to use it. If the user prefers, it can be unziped into the main Poser runtime, but I would discourage that. As it has evolved, there is junk left over that causes problems and detangling the junk from your main runtime is not easy.

When used as an external runtime, it is usually the case that Python scripts don't work because of path issues. I have solved this. The LuxPose runtime can be stored anywhere. There can be multiple occurences of them, although only one can be used at a time. So as it evolves you can keep multiple versions and switch between them if you need to track down the cause of some new behavior from one version to another.

In this runtime, under the Python folder there is a LuxPoseSystem folder and a LuxPoseScripts folder. The scripts folder contains things the user will explicitly execute via the Poser UI. The system folder contains all the real code.

In the system folder, there are the following Python "packages":

bbml - everything you need to read and write bbml data files trivially.
luxmatic - the material generation and conversion stuff
pydough - the geometry conversion stuff from odf (modified by me slightly to rotate the world 90 degrees)
paser - the Poser application server that provides ways to call the exporter (or anything we want besides that) from OUTSIDE Poser
luxpose - the actual LuxPose exporter library

The luxpose exporter package top level code is 99% unrelated to LuxRender. Eventually I will make it completely applicable to any target, but for now I'm OK with a little bit of Lux pollution in there. That's why it is in luxpose. Eventually the main code will move out of luxpose into a new package that will provide generic export capability from Poser to any other format we care to build.

The remainder of the luxpose package is in a subpackage called exportLib. This contains the individual exporters for Film, Camera, Lights, Materials, Geometry, etc. Each of these is in its own module. They are so simple that the longest one is Lights, at 83 lines of code.

I have a few more little book-keeping things to clean up among the modules I've just discussed, but I'm very close.

The UI has been extended to do many of the things we have talked about, but not all. The biggest thing I want to add is handling lists of Poser objects that each need some exporter-specific settings. In particular, we have just been discussing geometry exporter per-object properties, and this is precisely what I want to build. I need the same for the materials.

Included in my package is the GUI, but you no longer have to install it as an AIR app. It's ready to go.

I just got a Mac, and shortly I will make the pre-installed GUI for Mac as well.

I'll need help with the pre-installed Linux.

Quote - > Quote -

Excellent! My patched code is now on github. Any value for 'compute_normals' that's false according to Python's rules turns the normal off, plus the strings '0', 'false' and 'False'.

Udated, new version 1-14a

GUI contains now switches to turn on/off normal re-computing for (all) figures and/or (all) props.

Because the GUI has no connection to Poser, setting this individually per figure/actor/prop isn't possible yet.

Right. But now I have the application server running, and shortly we will be able to do that interactively. Or - we could put the per-light, per-actor, per-material stuff in the data files. Either way will work.

Oh - I forgot to mention.

The scripts you need to run will also be library objects in the LuxPose runtime. So you can launch any function from the Poser library, using Py-Pose files.

I'm also going to be adding into this some predefined reference lights, props, materials, and whole scenes.

Also, eventually, you will be able to invoke LuxRender presets without the GUI - just double click them in the library like any other Poser content. For example, you want to switch to a different sampler preset? Double click it.

Quote -
Here's what I've done so far:

Sounds good!

Quote -
I'll need help with the pre-installed Linux.

I'm here. Very familar with Linux. I have an additional machine with Linux so I can test on a "plain machine".

I've to go out now for 3-4 hours ( I'll check this forum with my smartphone every hour). It's 17:00 here and I'll have some time after I'm back. 

Oh, I did something else very handy. Developers will like this.

I added a moduleManager class that watches all of the luxpose scripts. Any LuxPose action triggered by the UI or by the server causes it to check for modified source code. Modification can go forward or backward in time so reverting to some previous code or putting in new code will trigger it.

If triggered, it deletes all LuxPose modules from the Python engine completely. Thus, any user action following a change in any python module or any user script will automatically reload the whole thing.

We no longer have to sprinkle the code with import, reload, import.

Question for bagginsbill:

That image I just posted last...

I changed the image gamma from 2.20 to 1.80 because it looked better to me at 1.80. Gave her just the right depth I thought. Was that wrong? There was gamma correction on the textures in Poser as well.

Edit: she looked a little "off" to me at 2.20 ;o)

Laurie

It's actually fine to do that. It's no different than taking the final image into Photoshop and using "levels" to get a bit more contrast. We do this with photos as well. Any time you take a photo and then alter the contrast using a power function, you're actually just altering the final gamma. It's a perfectly valid technique.

As with any technique, rules are meant to help the beginner achieve a good result. Once you move past the beginner stage (and you certainly have) then breaking the rules with a clear understanding of why you're doing it and what you will get is perfectly valid.

When I studied baroque music theory, (way back in time both for the music and for me), we were told in the first year to NEVER arrange a four-part harmony with parallel fifths, as Bach taught his students. Then in the second year we deeply studied Bach chorals and he did it all over the place, but with great finesse.

Note - I do this with incoming anti-gamma as well. On the environment sphere, I often mess with the incoming gamma before applying the color-changing effects. I also occasionally do it with skin textures, in order to alter the luminance or saturation in interesting ways that an HSV node cannot do by itself, since it isn't a power function.

Thanks ;o). Actually, I had thought about taking it into Photoshop and doing exactly what you mentioned, but I thought I'd try it in LuxRender first...lol. Nice to know I won't have to do that now with LuxRender images like I do with most of my Poser images ;o).

Laurie

Yes, and the added benefit is that by doing contrast adjustment in Lux, you are doing it with the full floating point values. Thus there is no loss of precision and you don't get the banding and zero-data problems you have in post-work levels adjustment.

Quote - Here is my nekkid Vicky again. This time, changed the spotlight to a point (scaled at 500). No fireflies.

Reinhard tonemapping...left it run overnight, about 8 hours. Bi-directional.

I know she's a bit "shiny" ;o). I just wanted some gloss on there because ice-boy mentioned he thought it was gloss that might be causing the fireflies. I have all the time in the world to learn how to  make her skin look better when the exporter is done. Right now, I'm not really going for perfect ;o).

Laurie

Very nice results for an organic figure in Lux. Too shiny?....Maybe she just got done performing a dancing  routine :)

Quote - > Quote - Here is my nekkid Vicky again. This time, changed the spotlight to a point (scaled at 500). No fireflies.

Reinhard tonemapping...left it run overnight, about 8 hours. Bi-directional.

I know she's a bit "shiny" ;o). I just wanted some gloss on there because ice-boy mentioned he thought it was gloss that might be causing the fireflies. I have all the time in the world to learn how to  make her skin look better when the exporter is done. Right now, I'm not really going for perfect ;o).

Laurie

Very nice results for an organic figure in Lux. Too shiny?....Maybe she just got done performing a dancing  routine :)

LOL. Well, someday, I'd like to get a little bit of translucency in that skin along with that gloss, but all good things come to he who waits ;o). Or something like that...lol.

Laurie

As I don't have viewing of footers enabled as I don't want extraneous items loading when I'm in the forums, would it be possible for someone to put the link to adp's download please so I can have a play please? Of course, no footers means that sometimes I miss out on things though :)
Thanks.

http://www.poserprofis.de/PoserLuxExporter_Alpha

here you go. :D

Anyone else having the problem with the new build of the center of mass of a figure being visible? I can't think it's anything else...I'm getting not the figure, but a huge ball in Luxrender instead of the figure ;).

Laurie

odf... you know, that sucks... now I had to find another scene to test... ;-)

But luckily, I just needed to pick the next one (with diffuse IBL light with no image map) :-)

I had to change line 194 of PoserLuxExporter_workers.py to:

if not node or node.Type() != poser.kNodeTypeCodeIMAGEMAP : return None

to get to bug #2:

RuntimePythonposerScriptsScriptsMenuluxPose_1_14workersPoserLuxExporter_workers.py", line 251, in convert2Lux
self.image, self.imagetype = self.getImage()
TypeError: unpack non-sequence

I guess IBL without image maps just isn't supported yet. 

Laurie

Quote - Anyone else having the problem with the new build of the center of mass of a figure being visible? I can't think it's anything else...I'm getting not the figure, but a huge ball in Luxrender instead of the figure ;).

Laurie

I haven't seen that one yet, I'm using the latest build as well, you've already seen the evidence of that in the other thread. ;)

Forgot to say I'm using the Windows X64 version

I'm using the 32 bit Windows version.

Waaaaaaaaa....lol. Where's me figure? ;o)

Laurie

also using the latest build and windowsx64, haven't seen that problem either.

Which figure is it supposed to be? is it one you've used in this before?

laurie--i don't get the ginormous ball but i do get a funny little ball at the bottom of my figure's feet, so i think something is rotten in 14a.   hasn't been in any other build.  curious.

Yes Lucifer...it's the same GND4 I was using before - same scene. The only thing I changed in this one was I put a tiny bit of translucency in the skin mats. But that's it.

Laurie

Quote - laurie--i don't get the ginormous ball but i do get a funny little ball at the bottom of my figure's feet, so i think something is rotten in 14a.   hasn't been in any other build.  curious.

I'm getting the little ball too, I've found if you move your figure over it hides the ball quite nicely. ;)

Quote - Yes Lucifer...it's the same GND4 I was using before - same scene. The only thing I changed in this one was I put a tiny bit of translucency in the skin mats. But that's it.

Laurie

Have you tried taking the translucency back off again? If that doesn't fix the problem then I'm stumped. sorry.

I just checked using a different figure, and I am getting the little ball too.

Yeah, I tried even making the center of mass material transparent and nothing works. Mine might be covering the whole figure either because GND4 is so heavily morphed, the hair is a figure as well, but not conformed, it's the hair's center of mass that is so huge...all of them guesses ;o).

Loading  pydough.geometry_export
Loading  pydough.poser_extractor
Loading  pydough.geometry
Compiling D:e frontierPoser 7RuntimePythonposerscriptsluxmaticnodes.pyc
Version alpha 1.14 (exporter: alpha 1.14), exporting Lux files to
D:e frontierPoser 7RuntimePythonposerscriptstoLux1
Exporting figure Victoria4
720 bad UV polygons
Mesh has 75830 polygons and 75830 texture polygons
Exporting figure Aeris_Hair
720 bad UV polygons
Mesh has 24178 polygons and 24178 texture polygons
Exporting actor GROUND
Mesh has 400 polygons and 400 texture polygons
Time used: 14.25 seconds

That's what I get from the script. Maybe it's those bad UV polygons?

Laurie

...and it's the most complete Micheal 4 has felt in ages....

The code has a problem:
actor.Visible is used instead of actor.Visible()
That's why everything is getting exported.

Open poser_extractor.py

search for "good_actor"

two lines below add "()" behind "actor.Visible", so it reads "return (actor.Visible() and geom"

Dizzi: My Victoria thanks you ;o). That did the trick...lol.

Thanks!!

Laurie

Quote - The code has a problem:
actor.Visible is used instead of actor.Visible()
That's why everything is getting exported.

Open poser_extractor.py

search for "good_actor"

two lines below add "()" behind "actor.Visible", so it reads "return (actor.Visible() and geom"

Oh sh...

Sorry, I do that all the time now. Neither Ruby nor Scala require redundant parentheses for function calls, so I'm now seriously struggling with Python's required verbosity.
ETA: Fixed on github (even though the fix is so simply that it's hardly worth downloading).

Unfortunately (or luckily) the image node bug you found is not in my department.

Quote - Oh, I did something else very handy. Developers will like this.

I added a moduleManager class that watches all of the luxpose scripts. Any LuxPose action triggered by the UI or by the server causes it to check for modified source code. Modification can go forward or backward in time so reverting to some previous code or putting in new code will trigger it.

If triggered, it deletes all LuxPose modules from the Python engine completely. Thus, any user action following a change in any python module or any user script will automatically reload the whole thing.

We no longer have to sprinkle the code with import, reload, import.

That sounds lovely. As does the rest of what you've been describing. I'm sure I'll enjoy studying any code you may be publishing.

Since I'm very much interested in getting LuxPose to work properly under Linux/Wine, I'm happy to help with the porting and testing. By the way, you know that you can easily get a free Linux 'machine' set up, right? Just download Oracle's VirtualBox for your Windows machine or your Mac, run it, create a virtual machine and then install, say, Ubuntu 10.4 inside that.

This uses [0.3 0.4 0.5] for the color and [0.35] for both the u and v roughness inside the glossy node. Less rubbery, I hope?

Meanwhile, how do we like the skin, which is what I was checking out?

Note: This is a trick question. This is just using a standard P4 style shader converted as is.

Ah, crosspost! I think I can stop posting skin tests now.

I think the skin looks great on yours, BB, except maybe for the lips. At first I thought this was one of those textures with the burned in highlights.

ETA: Wait it is? You trickster!

I think I had too much bump on the lip.

How's this?

Better, but maybe something in the middle for the lips? This looks a bit too smooth. You may want to keep the grooves but get rid of the low-frequency noise in the bump map.

Quote - Better, but maybe something in the middle for the lips? This looks a bit too smooth. You may want to keep the grooves but get rid of the low-frequency noise in the bump map.

I'll just switch maps and see what happens. It's so hard to find good bump maps in these texture sets I have.

She put the lotion on her skin.

(Seriously, the full-body render looks like freshly put-on lotion. Not bad!)

This is Specular_Value = .5, Highlight_Size = .22.

I hope everybody realizes, though, that the interpretation of these numbers is very likely to change. I have a goal that if it looks right in Poser it will look right in Lux, and these don't match how they look in Poser.