Quote - Robyn: IBL Gain is about 60,000 times brighter than the sun?!?

Snarly?

I think this has since been fixed ;). New update just posted.

Laurie

Quote - Robyn: IBL Gain is about 60,000 times brighter than the sun?!?

Snarly?

When I picked up from the Luxpose project I found all sorts of gain adjustments in the code that I couldn't understand. Things like:

"gain *= 1000 * BBLuxMat.DIRatio"

"if integrator == 'Bidirectional':
gain *= 4096
else:
gain *= .3"

elif self.lightSource == 'distant' :
print >> file, ' "float gain" [%s]' % (self.gain * 1000000)

and so on (there were other examples). Loads of adjustments which may well be correct but I didn't understand them. And, I needed something I understood.

I made a decision to scrap all the gain adjustments and ouput everything with a gain of 1, and use the linear tonemapping settings to adjust the exposure instead. As a photographer, that was something I could get my head around - rather than turn the sun's brightness up or down I would just change the exposure :-)

That strategy worked wonderfully in all cases except IBL lighting. 

With Sun gain = 1 and IBL gain = 1 I'd get this:

But with Sun gain = 1 and IBL gain = 25000 I got this:

I don't profess to understand why this is so. I do know, however, that the second example matches my expectations much better than the first.

So for IBL, I have this magic factor of 25000 which doesn't make sense to me but seems to work.

If you can provide an explanation of what's happening here, or what settings would work better, then I'd be keen to hear it.

In the meantime I don't have much choice but to go with the factor for IBL. I'm happy that I've got rid of the need for all the other magic factors so if I have to have just this one then I can cope with that.

To have none at all, though, would be great!

Just a suggestion: what about setting a super simple equivalent scene in Blender and check what Blender exports and what Lux does?

The gain for Bidirectional integrator was something I added due to an empirical observation that the scene exposure value was completely different with that integrator, but all the others were consistent. I didn't understand it at the time and still do not - I simply noted that if I wanted to be able to switch integrators and keep lighting exposure levels the same, I had to do that.

The 1000 * BBLuxMat.BBLuxMatDIRatio was there because glowing objects and light sources have to agree on power. The ratio of direct to indirect light (DIRatio) was something I was exploring at the time, also empirically, since the documentation of LuxRender says absolutely nothing about these things. The factor of 1000 was just so I did not have to type tiny fractions like .000674 (or maybe it was the other way, to avoid having to type giant numbers) into the DIRatio. I never did finalize all those things.

I have no doubt that your 25000 is also one of these mysterious magnitude anomalies for which we will likely never get an explanation. I was just asking if the 60,000 x factor was what you expected SG. And it was. So good.

Now back to the question - why is Robyn's infinite light so weak as to effectively be disabled?

Quote - Now back to the question - why is Robyn's infinite light so weak as to effectively be disabled?

I believe that Pose2Lux was calculating the sundir vector incorrectly, wrongly placing the sun below the horizon. Another member here as demonstrated in PM that under certain circumstances Pose2Lux does indeed get the vector wrong. The 0.4 update has corrected all the anomolies that I have been able to test, so I'll now wait until Robyn has had a chance to test her scene with the the new version. Perhaps Robyn's scene won't be fixed by the latest update, but there's little merit in speculating about possible causes until I know for sure that problem remains.

BB..if you look back a few posts, Robyn has her light gain in Luxrender set really low on that image - less than 1.0. I'm not sure why that is, but I guess that's for her to answer ;).

Laurie

Snarly - OK. I looked at Robyns sundir but could not remember how to interpret the numbers. One interpretation says that was below the ground, another doesn't, and I don't want to take the time to look that stuff up again.

Out of curiosity, I'm pretty sure I had the infinite light converted perfectly in LuxPose - why did you do anything differently?

 if lightType in ('sun', 'distant', 'spot'):
  wm = light.WorldMatrix()
  pto = (0, 0, -1)
  pto = dotp(pto, mcol(wm, 0)), dotp(pto, mcol(wm, 1)), dotp(pto, mcol(wm, 2))
  if lightType == 'distant':
   point_from = mul3(pto, [-1, -1, -1])
   lux.point._from = xfm(point_from)
   lux.point.to = [0,0,0]
  elif lightType == 'sun':
   lux.vector.sundir = xfm(mul3(pto, [-1, -1, -1]))
  else:
   pto = add3(pto, wm[3])
   lux.point._from = xfm(point_from)
   lux.point.to = xfm(pto)

Quote -  if lightType in ('sun', 'distant', 'spot'):
  wm = light.WorldMatrix()
  pto = (0, 0, -1)
  pto = dotp(pto, mcol(wm, 0)), dotp(pto, mcol(wm, 1)), dotp(pto, mcol(wm, 2))
  if lightType == 'distant':
   point_from = mul3(pto, [-1, -1, -1])
   lux.point._from = xfm(point_from)
   lux.point.to = [0,0,0]
  elif lightType == 'sun':
   lux.vector.sundir = xfm(mul3(pto, [-1, -1, -1]))
  else:
   pto = add3(pto, wm[3])
   lux.point._from = xfm(point_from)
   lux.point.to = xfm(pto)

The problem right from the beginning for me was that there were two versions of Luxpose, and while they retained many similarities there were also many mutual incompatibilities. I chose to use ADP's version of Luxpose as the base from which I would work primarily because none of the files had copyright notices on them, whereas some in your distribution did. At the time I made that decision I didn't realise how many bugs were to be found in the version I'd chosen!

The code you've quoted only produces the correct result if the scene geometry has been written out using your modified version of pydough, whereas I was using ODF's original code as made available under the MIT licence towards the end of the project (assuming it has indeed ended?).

Yes well, ahem, that was part of the reason I got frustrated. There were a number of corrections posted (some by others, some by me) that just refused to show up in ADP's distributions. Part of the reason that mine had fewer bugs was fundamental - I arrange to do less typing, and therefore there are fewer typos. But others are not always comfortable with brevity in software and refuse anything written that way, regardless of benefits, such as it actually works.

Regarding copyrights, there were only two files with such, and those were two files lifted directly from matmatic, and all it means is to copy you must ask. All you had to do was ask. Those files (matmatic stuff) are only necessary to do advanced material conversion, something you've decided to skip. This was the area everyone expected me to do and I still may. Some wanted me to confine myself to that area, but I found the other areas sufficiently buggy and wordy that I was unable to stay in the materials. I rewrote most of the framework because I consider myself an expert at frameworks and I can't stand a broken one. I rewrote the light and camera converters so that they weren't buggy and were very tight code.

Meanwhile, although I made some material conversion progress, I found it is necessary to change the LuxRender shader system if we want procedural shader conversion to really work. I still might do that someday.

As for the modification I did to the geometry exporter, that couldn't be simpler. I swapped Y and Z, because that is a thousand times simpler than not swapping. Without the swap, it is too easy to make rotation bugs - precisely the kind you made with the infinite light. Literally, I did print x, z, y instead of print x, y, z - in a couple places.

In other words, my version was meant to swat all the bugs and minimize the chances of creating new ones.

count me in.............i cant promise i'm the best but if it can be broken, i'm your man lol

Quote - Update to Pose2Lux Pro 0.4.0 Changes:

Bugfix: Sun vector calculations reworked
Extended support for Poser's Skin node added
USE_SKIN parameter added to XML library options
Improved compatibility with Lux 0.7

Site download page updated - sorry it took so long. :blink:

Attached Link: Pose2Lux Pro 0.4.1

This is version 0.4.1

Changes:

Support for Luxrender's "write_png", "write_png_16bit", "write_resume_flm" and "restart_resume_flm" parameters. These can be found on the Export screen.

Bugfix: Fixed case where superfluous brackets were sometimes written out to the scene file when exporting emitters.

Site download page updated.

My latest :)

I think I need to come up for air...lol.

Laurie

fantastic render Laurie. raytraced hair and fur with plants with GI.

Just wanted to say a big thanks to everyone involved in the Pos2Lux project. Fairly new to all this, but this is my first attempt at a render (mainly to try out materials and lighting).

I hope you like it.....

http://www.renderosity.com/mod/gallery/index.php?image_id=2189111

An interesting observation, at least to me. 

I had tried the Hybrid renderer, and all of my renders would have a haze that would take over the scene and basically totally obscure what it was rendering.  So, just for kicks, I decided to try again with the latest Pose2LuxPro, and although the haze is still there, it does not take over the scene anymore.  it mostly now just looks like a faint haze in the air; although it is a blue haze.  But, I can see the render!

i thik now its time to start using lux with poser.

Hi all, is there also room for an exporter to octane in the luxpose architecture? Maybe as an alternative backend?

Luxpose? Yes. In my version there is, anyway. I don't know anything about Pose2Lux as Snarly did that himself.

I have some stuff I have to get out of the way, but I'm going to come back to Luxpose. I've been looking at how to export to YafaRay as well.

Ah, there are now many branches? Hm. Do you say "my" like "my private" Bill? Or is it something you think to be shared?

I shared it and the code is still there. I published it so other developers could pick up the ball, but nobody did. I even made it so that nobody had to do programming to build the GUI - just fill in the properties to define what is needed to edit the configurations. I made the converters so simple that they fit on half a page. And yet ... ignored.

http://sites.google.com/site/bagginsbill/free-stuff/luxrender-exporter

I wish I had time to work on this but I don't. One thing I know is that if you want to build a framework that can be used for multiple target renderers, you have to actually do it with multiple target renderers as early as possible. Otherwise you only theorize about the commonalities and differences and get them wrong.

Also I think that it would be really cool to modify the target renderers so that they are procedurally compatible with Poser shaders for pattern generation. To that end, people should be working on porting Poser's nodes to Yafaray, Luxrender, etc. If I end up doing that all by myself, then I'll charge for those changes.

I hoped to get a little wiser by learning how to translate shaders.  Or to find out whether it is not possible at all. I wonder, do you know if there is a way to let Poser "evaluate" the shader functions and access the output as a grid of values, so one could "render" into maps if the shaders are not translate-able? At least for 2d nodes...

If the code is on your free-stuff page, I will happily have a look at it.

What you describe is called "baking" the shader, and sadly Poser doesn't provide a way.

Actually, I never WANTED Poser nodes ;). All I wanted was a way of interpreting Poser's nodes into the native shader and therefore a conversion (and ultimately the better shader) of the renderer. In this case, Luxrender ;). Laurie

I agree we don't want Poser's version of specular, which is not as good as the unbiased true blurry reflections we get from Lux.

But - what we lose is procedural patterns. It is impossible, for example, to reproduce my fish scale shader, as seen in my avatar, in LuxRender or YafaRay. They simply are missing ordinary math - add, subtract, multiply, divide, power, root, log, sin, cos, tan, etc. Without these math functions, you cannot make arbitrary mathematical functions, and therefore you cannot make as many patterns.

We get hung up on the fact that shaders have two jobs - define the pattern of the material, as well as define the interaction of the material with light. Lux is hugely better at the interaction with light. It is painfully weak at defining patterns.

I'll agree with the procedurals part of it. That would make everyone's lives much easier...lol. But how do you find out how Poser's procedural functions work? If that could be done, then perhaps there is a similar Luxrender or Blender procedural that can be switched out for the Poser one. That would be great! :D. Luxrender is pretty light on the procedurals, but Blender has a great deal and Luxrender reads those as well. And Blender is open source. I think that perhaps we might need to go that direction rather than try and directly interpret Poser's. Laurie

I know exactly how the math ones work since they are well-known math functions with no secret parameters.

The noise nodes are less obvious. (Cellular, Fractal Sum, fBm, Granite, etc.) I know the algorithms for the most part since they are generally already published elsewhere, but the internal values that drive the randomness are not public. An easy way I could find out though would be to simply ask SM for the values.

Let's say for the sake of argument that SM gives you the values. How do you make Luxrender accept them? Understand them? Does each person need to do mathmatical equations for each material in order to do so? If that's the case, I think I'll just stick with LuxBlend...lol. Luxrender directly understands the output ;). I'm not trying to be argumentative, I'm just trying to understand...lol. The only way I can see it working is if you wrote your own version of Luxrender. Is that the idea? Laurie

I'm a software developer. Given enough time (which is actually saying given enough money) I can write anything. I can, for example, add enough code to LuxRender that it would read your Poser scene file exactly as is, with no exporter involved, much the way Vue does.

[Edit] I didn't notice your last question part until now - yes write a modified version of LuxRender. Since it is open source, that is pretty easy. Easier than writing an exporter, actually. The same is true of YafaRay - a modified version that correctly interprets Poser files is not out of the question.

I'm a software developer. Given enough time (which is actually saying given enough money) I can write anything.

So if i win the lottery you could create a new Poser program?

Yes.

Quote - I've been looking at how to export to YafaRay as well.

YEEEEEEES  

yafaray is a biased raytracer. this means  fast and 80% realistic. plus in the next months they will add subsurface.yafaray is like a simple free vray.juhu

bagginsbill i am not rich. but i would pay you money to make an exporter for yafaray.

right there could be a yafaray exporter.

moving back to the current Lux exporter...

is there a trick to getting IES files to apply? i've been trying 3 different ones (narrow, medium, wide) & it doesn't seem to make any difference. in the emitter panel, i browse to & select an IES for each emitter. am i missing a step?

MagnusGreel

you dont like it when i post on this forum right? you dont have a problem if other members go offtopic. only with me.

Attached Link: Pose2Lux Pro v0.4.4

Discussion of other exporters and other renderers is fine, but best done in another thread.

Here is the latest update to Pose2Lux: version 0.4.4

It is HIGHLY RECOMMENDED that you use this version with the Luxrender weekly build dated 10th April (or a later one). It can be downloaded here:

Luxrender weekly build 10th April

The v0.4.4 update includes extensions to the XML parameter options and some displacement optimisation which is dependent upon the 10th April Luxrender build for it to work effectively. 

Quote - MagnusGreel

you dont like it when i post on this forum right? you dont have a problem if other members go offtopic. only with me.

ok since you made this personal, if I had a problem with you posting in this forum as you put it, I'd be answering your every post in every thread. oh. and it would be every time you "go off topic"

since that is not happening, I think your in the wrong and being over sensitive. oh and did I mention YOUR name? nooooooo. I mentioned Yafarafy. so wrong again on that.

sorry if you have a persecution complex, but it's all you lad.

Quote - is there a trick to getting IES files to apply? i've been trying 3 different ones (narrow, medium, wide) & it doesn't seem to make any difference. in the emitter panel, i browse to & select an IES for each emitter. am i missing a step?

Are you clicking on the 'Apply' button to assign the IES file (and the other parameters) to the emitter?

If so, are there any error messages being generated in the Lux log pertaining to emitters?

You might also want to check the Lux scene file - search for 'iesname' and it should find a line similar to this:

"string iesname" ["L:/Poser development/Plop/Pose2Lux folders/IES data/erco_red.ies"]

ok, that did it--works now. i see it in the .lxs too now. thanks!

I just saw the .zips contain only .pyc, so is it closed source?

Quote - I just saw the .zips contain only .pyc, so is it closed source?

Yes, it is closed source for now at least. The reasons for this have been explained elsewhere in the thread so I won't go over them again, but suffice to say that it will be made open source in due course, certainly by version 1.0.

In the meantime, if you have an especial interest in the source then just drop me a PM and I'll sort something out.

Not sure if Robyn saw the update for P2L, will make sure to point it out to her.  Or get it updated myself later. 

Quote - Not sure if Robyn saw the update for P2L, will make sure to point it out to her.  Or get it updated myself later. 

:blink: Update? What update??? Which version are we on?? I've got this one...

On the previous page here, the newest update is 0.44. 

You know your software is in rapid development when...

Quote - Update? What update??? Which version are we on??

Now that is a quote for the ages... :)

I think we should put that up on the P2L site.  Side note, anyone see that the new RC3 release of Lux is out and has broken the only commercial Lux exporter (not mentioning names)....

We have yet to find an issue with it for P2L, 0.8 RC3 looks to be safe for us. :)

Quote - Now that is a quote for the ages... :) I think we should put that up on the P2L site.  Side note, anyone see that the new RC3 release of Lux is out and has broken the only commercial Lux exporter (not mentioning names)....

We have yet to find an issue with it for P2L, 0.8 RC3 looks to be safe for us. :)

Not being evil or anything, but Chevy Chase - face covered with a strange white substance - comes to mind: "ooooooooooooooooo yessssssss, I love it!!!"

Rhionon wrote;

Quote - Side note, anyone see that the new RC3 release of Lux is out and has broken the only commercial Lux exporter (not mentioning names)....

Only the material preview, don't get too excited. Besides, it's working now.

Coldrake