Quote - As promised, here is that render I was working on.

I replaced the infinite light in Poser with the sun and sunsky setting from the example lux file included with LuxRender. I left the position as it was.

I like the lighing in this and the shadows as well, but I am having that problem with "fireflies" and I have no idea what that bright line is up the right side of the diagonal piece of the building with the doors. If you look behind the planter on the right side of the door it's where it's most noticeable.

I had to shrink this to get it small enough to upload, but the fireflies and that line are very noticeable on the larger image.

Rendertime: 9 hours.

Laurie

That's a beautiful render, at this resolution I don't really notice the fireflies. Wonder if the bright line is a seam running through the model of the building.

Quote - > Quote - While that might be important in real life for biology, physics, etc..

It will not matter much when creating an image, you won't feel the heat, your leaves won't be synthesizing sunlight, you won't be imaging ultraviolet or infrared. ;)

So the equation will be close enough for image rendering.

It will depend on the physical properties of the object. For a silver mirror or a good quality crystal glass the image error will be insignificant, but if you deal with a plastic you are in trouble.
Of course for Poser or Vue users the error will be also not so important, after all we don't care too much with Phong that is physically wrong.

And the programmers will cross that bridge when they come to it. We aren't there yet. So let's just concentrate on what is rather than what isn't, yeah?

Laurie

Quote - > Quote - As promised, here is that render I was working on.

I replaced the infinite light in Poser with the sun and sunsky setting from the example lux file included with LuxRender. I left the position as it was.

I like the lighing in this and the shadows as well, but I am having that problem with "fireflies" and I have no idea what that bright line is up the right side of the diagonal piece of the building with the doors. If you look behind the planter on the right side of the door it's where it's most noticeable.

I had to shrink this to get it small enough to upload, but the fireflies and that line are very noticeable on the larger image.

Rendertime: 9 hours.

Laurie

That's a beautiful render, at this resolution I don't really notice the fireflies. Wonder if the bright line is a seam running through the model of the building.

That could very well be, but it's not something I notice in Poser. I thought maybe the texture maps were very close to the edge of the uvs in that particular spot and it was actually catching maybe a pixel of white on the edge of the uv right there, but I really don't know what's doing it ;o). Looks fine in Poser for the most part...lol.

Laurie

Quote -
I like the lighing in this and the shadows as well, but I am having that problem with "fireflies" and I have no idea what that bright line is up the right side of the diagonal piece of the building with the doors. If you look behind the planter on the right side of the door it's where it's most noticeable.

Just guessing - but maybe the mesh is splitted on the corner to get a sharp edge. This is often done with Poser objects.

Fireflys are normal with this type of render engine. Most often it's how light is traced, With very intensive light the render engine concentrate on certain parts sending not enough rays to this parts where your fireflys are. Another render strategy may help - try "path" insteed of "bidirectional" for example.

Quote -
Strictly alpha maps are not the same as transparency maps, alpha maps only modulate the overall transparency for all colors. A transparent map can modulate each RGB component.
Poser only use alpha maps.

My C4D materials have seperate settings for alpha and transparency. Other Modelers too.

But Lux seems to act like Poser: There is no alpha-channel we could use (I couldn't find something). So, indeed, your right. For Lux transparency == alpha.

Quote - > Quote -

Strictly alpha maps are not the same as transparency maps, alpha maps only modulate the overall transparency for all colors. A transparent map can modulate each RGB component.
Poser only use alpha maps.

My C4D materials have seperate settings for alpha and transparency. Other Modelers too.

But Lux seems to act like Poser: There is no alpha-channel we could use (I couldn't find something). So, indeed, your right. For Lux transparency == alpha.

LuxRender also separates between transparency and alpha.

Transparency is meant for materials like glass, driven by physical properties like reflection, transmission, IOR etc and not with a map.

Alpha is done in LuxRender using a mix material, where an alpha map can be applied to each layer.

Quote - > Quote - yes I am...

must be that marine figure..

I'm downloading the figure now, but I'm off to work in a minute, so I can't do anything more before tonight. I'm surprised you're still getting that error.

found the issue on the figure.. it's the kneepads on the armour. once they are removed, 5 seconds to convert. problem is, you do need them lol

Quote -
found the issue on the figure.. it's the kneepads on the armour. once they are removed, 5 seconds to convert. problem is, you do need them lol

Can you give me the last 5 lines or so off the error message?

here we go

Traceback (most recent call last):
  File "D:PoserSmith MicroPoser ProRuntimePythonposerScriptsScriptsMenuLuxPosePoserLuxExporter.py", line 166, in ?
    ExportScene(scene, globalParameters).write(f)
  File "D:PoserSmith MicroPoser ProRuntimePythonposerScriptsScriptsMenuLuxPoseworkersPoserLuxExporter_workers.py", line 336, in write
    ExportFigure(fig, self.globalParameters).write(file)
  File "D:PoserSmith MicroPoser ProRuntimePythonposerScriptsScriptsMenuLuxPoseworkersPoserLuxExporter_workers.py", line 107, in write
    params).write(file)
  File "D:PoserSmith MicroPoser ProRuntimePythonposerScriptsScriptsMenuLuxPosepydoughgeometry_export.py", line 351, in write
    Subgeometry(self, indices).write(file)
  File "D:Program Files (x86)Smith MicroPoser ProRuntimePythonposerScriptsScriptsMenuLuxPosepydoughgeometry_export.py", line 103, in write
    self.fix_texture_seams()
  File "D:PoserSmith MicroPoser ProRuntimePythonposerScriptsScriptsMenuLuxPosepydoughgeometry_export.py", line 48, in fix_texture_seams
    tverts = [tpolygons[i][j] for i,j in corners_for_v]
IndexError: list index out of range

Laurie,

Quote - [
Fireflys are normal with this type of render engine. Most often it's how light is traced, With very intensive light the render engine concentrate on certain parts sending not enough rays to this parts where your fireflys are. Another render strategy may help - try "path" insteed of "bidirectional" for example.

 This is what I've found in the Lux faq:

path tracing is only usually better for exterior skylight rendered scenes.
bidir is better for any type of interior scene.

If you do renders with "sunsky", use the GUI, tab "Render Settings", and change the "Integrator" from Bidirectional to Path.

If you don't use the GUI, open file AIR/LuxPose/data/dataOut.bbml and change "bidirectional" to "path" manually.

@kaibach: Ah, you're not using the current version. I just downloaded ADP's latest package, and for some reason it includes an outdated pydough which does not have my workaround for the bad UVs yet.

If you feel adventurous, you can go to http://github.com/odf/pydough and click on "Download Source" near the top right corner. That will give you a ZIP or TAR file (your choice, but you'll probably want ZIP). Unpack that and replace the pydough folder from ADP's code (within workers, I think) with the folder you get (which is named something like 'odf-pydough-xxxxx', so you'll need to rename it to pydough).

Uhhhhh - to mutch played here. I'll update it in a minute.

Updated 

bingo! it converted!

thanks guys :)

Quote - bingo! it converted!

thanks guys :)

Unfortunately, the current workaround is a bit drastic in that it throws away all the UVs for the material zone in question. So if you've got any kind of texturing on the kneecaps that depends on UVs, don't be surprised if the mapping is not correct. I'll look into that later.

in the mean time tho, it tells us where the issue is.. that's useful in itself. 5 seconds to find it compared to the 10 minutes of stripping the model back (damn there's alot of smart props on it) one by one and testing...

a lot of new posts are here.

can someone in one post explain to me what is now inside the exporter? 

Most important:

Geometry export is even FASTER!
 
Material conversion does not interrupt the script anymore if a node could not be converted.

Spotlight works with "point-to".

Pointlight is converted to an arealight. Scaling the "Point" in Poser makes to area geometry in Lux as big as you see the "light-circle" in Poser. This is nice for soft shadows.

I'm almost done with my new framework. I'm exhausted, though and have to sleep. I'll post it tomorrow.

As an example, this is the Camera exporter in its entirety.

outputFile ='*.lxc'

def prepare():
 cam = scene.CurrentCamera()
 focalLength = getPP(cam, 'Focal')
 data.Camera.Poser.focalLength = focalLength
 

def emit():
 cam = scene.CurrentCamera()
 pos = cam.WorldDisplacement()
 camFocalLength, r, p, y = getPP(cam, 'Focal', 'roll', 'pitch', 'yaw')
 up = rollPitchYaw((0, 1, 0), r, p, y) # up vector
 la = rollPitchYaw((0, 0, -1), 0, p, y) # look-at vector
 focal = choose(overrideFocalLength, focalLength, camFocalLength)
 fov = 360 / pi * atan(12.75 / focal)

 lux('LookAt %s %s %s', pos, add3(pos, la), up)
 lux.typeof.Camera = cameraType
 if cameraType == 'Perspective':
  lux.fov = fov
  if fStop > 0:
   lux.lensradius = 0.0175 / fStop
   lux.autofocus = autoFocus
   if not autoFocus:
    lux.focaldistance = focalDistance
 

Here is the Film exporter

outputFile = '*.lxf'

def prepare():
 w,h = scene.OutputRes()
 dim = data.Film.Poser
 dim.width = w
 dim.height = h

def emit():
 lux.typeof.Film = 'fleximage'
 src = choose(overrideDimension, Dimension, metadata.Poser)
 lux.xresolution=src.width
 lux.yresolution=src.height
 lux.displayinterval=displayInterval
 lux.writeinterval = writeInterval
 lux.haltspp = choose(enableStopSPP, stopSPP, 0)
 lux.halttime = choose(enableStopTime, stopTime, 0)
 setattr(lux, 'write_' + saveAs.lower(), 'True')
 tm = ToneMapper
 lux.tonemapkernel=tm.kernel
 if tm.kernel == "Linear":
  lux.linear_sensitivity=float(tm.linearSensitivity)
  lux.linear_exposure=float(tm.linearExposure)
  lux.linear_fstop=float(tm.linearFStop)
  lux.linear_gamma=float(tm.linearGamma)
 
 
 

Here is the Renderer exporter

outputFile = '*.lxr'

def emit():
 lux.typeof.Sampler = sampler
 if sampler == 'Metropolis':
  lux.usevariance = useVariance
  lux.maxconsecrejects = maxConsecRejects
  lux.largemutationprob = float(largeMutationProb)
  lux.mutationrange = float(mutationRange)
 elif sampler == 'Random' or sampler == 'Low Discrepancy':
  lux.pixelsampler = pixelSampler
  lux.pixelsamples = pixelSamples
 elif sampler == 'ERPT':
  lux.initsamples = initSamples
  lux.chainlength = chainLength
  lux.mutationrange = mutationRange
 lux.typeof.SurfaceIntegrator = integrator
 lux.typeof.Accelerator = accelerator
 lux.typeof.PixelFilter = pixelFilter
 lux.xwidth = float(pixelFilterXWidth)
 lux.ywidth = float(pixelFilterYWidth)
 

this must be a slap to Daz since those scripts are out before Reality is even realesed.

hahahahhahaahhahaahha

Quote - this must be a slap to Daz since those scripts are out before Reality is even realesed.

hahahahhahaahhahaahha

Agreed, this is pretty funny, looks like we'll have a functional exporter before Daz gets around to releasing theirs. :D

Quote -
Yes, adp is right. The leaves transparencies are just an alpha map, applied in Poser....converted over to Lux just fine. White includes, black drops out.

Laurie

I just tried Smay's Mavka. Her eyes were coming out just white in LuxRender.

Quote - this must be a slap to Daz since those scripts are out before Reality is even realesed.

hahahahhahaahhahaahha

ok lets not start that ok?
we're not gonna start a pissing contest with this.

The image was rendered for only ten minutes

Please ignore the color and angle of the sun, because it's different than that of the render I'm going to post next, but that's unimportant to the quality of the lighting in the next one I'm gonna post...

Original render here

Laurie

Attached Link: http://www.renderosity.com/mod/gallery/index.php?image_id=2100712

Just followed instructions, added nothing, altered no files for lights,etc.
You can see what I got.

Not bad. Character's head got cut off, but that may be on my part as stated in notes on image. (Sorry to drag you folks from the thread.) I'd like to contribute by (with Flenser's permission) adding to the Getting Started text.

I'd also like to suggest for the final base package, a starter Poser scene/.pz3 with colored primitives be added (i'll post a sample image) so folks can jump right in following the Getting Started text, see what the fuss is about (if they don't frequent this thread) and then they can play around if they want to.

Somehow, we need to tell Lux to replace a Poser infinite with it's own sun and point and spotlights with it's own. Otherwise it won't be of much benefit IMHO.

Laurie

Quote - Now, in this render the Poser infinite has been replaced by Lux's sun and sunsky. They are vastly different and this one is greatly improved. Tell me what you think ;o).

Somehow, we need to tell Lux to replace a Poser infinite with it's own sun and point and spotlights with it's own. Otherwise it won't be of much benefit IMHO.

Laurie

Massive Improvement Laurie !!!!!
Great render

Cheers

Let me add to the wishlist ;o)....lol.

A way to replace Poser's infinite (essentially the sun) with Lux's own sun. Probably the points and spots to Lux's attributes as well.

A way to change the angle of Lux's sun before rendering.

I think after the material conversions are done, this might be the next and maybe last (?) hurdle. Then I think we'll have a freakin' awesome alternative to Firefly :o). After all, it's Lux's lighting that most of us really like, right? :o).

Just my two cents.

Laurie

Quote - > Quote - Now, in this render the Poser infinite has been replaced by Lux's sun and sunsky. They are vastly different and this one is greatly improved. Tell me what you think ;o).

Somehow, we need to tell Lux to replace a Poser infinite with it's own sun and point and spotlights with it's own. Otherwise it won't be of much benefit IMHO.

Laurie

Massive Improvement Laurie !!!!!
Great render

Cheers

Thanks :o). I can't tell you how bowled over I was when I saw the difference...lol. Like night and day (so to speak...lol).

Laurie

Quote - Now, in this render the Poser infinite has been replaced by Lux's sun and sunsky. They are vastly different and this one is greatly improved. Tell me what you think ;o).

**Somehow, we need to tell Lux to replace a Poser infinite with it's own sun and point and spotlights with it's own. Otherwise it won't be of much benefit IMHO.
**
Laurie

the problem in your first render was not the sun. you didnt hae a sky to light your ambient lighting.

in your second render your sky is lighting the scene with the sun.

did you guys know that you can save your render in progress and reopen it later and render ?

this is insane..........!!!!!!!!!!!!!!!!!!!

I will do the sun or sun+sky option.

I'm in the middle of calibrating the regular infinite, though and I've run into something really strange.

If I use just one infinite (lux's "distant") light, and calibrate it to match the luminance of the Poser infinite light, it looks just exactly right, but only with certain render settings.

When I use metropolis/bidir, it looks like what I expect. When I use lowdiscrepancy/directlighting, it is 1000 times brighter. Perhaps I don't understand the universe, but changing the sampler and integrator should not alter the luminance, should it?

Also, I have some concern about coordinate transformation (or the current lack thereof). When you use the sun+sky built-in feature, it selects sun and sky colors based on the elevation of the sun, so as to properly represent how the sky looks with the sun very high versus close to the horizon.

But in Lux, "up" is Z, not Y. So I think any testing you're doing with sun+sky is off by 90 degrees.

I will set up the sun+sky export and check it out. If it looks wrong, I'll try adding a world transformation that rotates the whole scene. There should be no need to modify any of the other exporters - just need to rotate globally. While I'm at it, I'll probably add the conversion of Poser Native Units into meters in the world transform.

in luxblend it is the same when you change render settings. with some settings you get a brighter scene then with other. then you need to use the tone mapping.

i also noticed that mattetranslucent looks different with different render sampler. strange right?

Quote - I will do the sun or sun+sky option.

I'm in the middle of calibrating the regular infinite, though and I've run into something really strange.

If I use just one infinite (lux's "distant") light, and calibrate it to match the luminance of the Poser infinite light, it looks just exactly right, but only with certain render settings.

When I use metropolis/bidir, it looks like what I expect. When I use lowdiscrepancy/directlighting, it is 1000 times brighter. Perhaps I don't understand the universe, but changing the sampler and integrator should not alter the luminance, should it?

Also, I have some concern about coordinate transformation (or the current lack thereof). When you use the sun+sky built-in feature, it selects sun and sky colors based on the elevation of the sun, so as to properly represent how the sky looks with the sun very high versus close to the horizon.

But in Lux, "up" is Z, not Y. So I think any testing you're doing with sun+sky is off by 90 degrees.

I will set up the sun+sky export and check it out. If it looks wrong, I'll try adding a world transformation that rotates the whole scene. There should be no need to modify any of the other exporters - just need to rotate globally. While I'm at it, I'll probably add the conversion of Poser Native Units into meters in the world transform.

You know, I've been playing with some of the sliders in Lux. And some of them do things I didn't expect either. When you increase the Fstop distance, the whole image blows out. You have to readjust with exposure and/or light gain. I didn't expect that changing fstop (which is a camera setting, is it not?) would affect light brightness ;o). But then, I'm not the most sophisticated 3D person in the world either, so I really don't know much in the scheme of things.

Laurie

The camera sliders in Lux are set up just like a real world camera.  Changing the sensitivity is like changing the film speed (faster film is more sensitive to light).  Exposure is shutter speed and tells you how long the film is being exposed to light in fractions of a second.  F-Stop tells you how wide the lens aperture is open.  In that one the numbers are reversed, as the f-stop number gets smaller more light is let onto the film.

F-Stop also plays a big role in DoF, if I remember right smaller f-stops give you deeper areas in focus and larger ones make it much more shallow.  It's been a while though so I'm not 100% sure of that one, besides we've got lots of time to figure out how Lux will handle it yet.

On an unrelated subject, is anyone having exports crashing Lux?  I've got a couple of scenes I was trying that export fine back crash Lux during the loading process.

In the case of film speed, the higher the number, the more light sensitive it is. 

The F-Stop does indeed affect DOF in real world cameras, not sure about Luxrender.  The bigger the number, the smaller the aperture.  (Not really, it is really reversed but most cameras drop the '1/'xx' from the display.)  The smaller the aperture, the more of the scene is in focus.  However, the smaller the aperture, the less light is used.

There are two different F-Stop parameters in Lux. One is for the "perspective" camera and affects depth-of-field but not sensitivity. The other is for the linear tone mapper and affects the apparent luminance of the image. The tone mapper F-Stop can be changed on the fly while rendering, while the camera F-Stop cannot.

The F/stop on a camera controls the lens aperture: the smaller the number, the bigger the aperture and the more light it allows in.  You calculate it by divding the size of the lens by the diameter of the aperture: so for a 50mm lens, an aperture 25mm wide will be an f/2, a 12.5mm aperture will be f/4, and so on.

If you reverse it so you divide the lens size by the f/stop, you get the size of the aperture.  Knowing the diameter, you know the radius and thus can calculate the area of the aperture using the old radius multiplied by pi R-squared equation that everybody should have learned in school.  Again using a 50mm lens, f/2 gives you an aperture of 25mm (radius of 12.5mm), and an area of about 491 square millimeters.  Setting it at f/2.8 gives a aperture of 17.9 mm and an area of about 250 square millimeters, or roughly half the size.

The amount of light gathered by the film/CCD/virtual thingie that calculates the rendered image is directly proportional to the area of the aperture: twice as much area, twice as much light gets in, which means that everything you see gets twice as bright as it was.  If the settings were already set up to give you a good range of illumination in the rendered image from the brightest to the darkest portions, twice as much light will blow out the parts that were toward the upper end to begin with.

The joy of the f/stop is that it doesn't matter what size lens you have on the camera: since it's the ratio of lens size to aperture, you know that setting the lens to f/2 will always allow in about twice as much light as f/2.8  It's also the reason why f/stops have been standardized on the vast majority of cameras to those odd numbers you see: each setting is roughly twice the area of the next highest number, and thus, everything else being equal, the exposed image will be twice as bright overall.  So f/1.4 is twice as bright as f/2, which is twice as bright as f/2.8.

But if the integrator is anything other than bidirectional, the light doesn't work correctly. Shadows are fine, but specular highlights are inverted - they appear darker instead of lighter.

This is really weird. Well I'm wasting a lot of time. I'll move on to the sun light and we'll figure out distant light later.

First experience with this script- I followed the instructions in the Getting Started read me that was included, followed intructions and only get a black viewport when Lux is rendering..obviously I missed a step somewhere but it wasnt included in the instructions.
I can probably find it in this forum but have 40 pages to sift through.

cant wait for the final version guys, keep up the good work!!

You asked a question in the other thread....did you see my reply? ;o)

If it's black, try playing with the exposure and gain....a little goes a long way...lol. Try and keep it to very small measurements.

Laurie

You didn't necessarily do anything wrong, per se.

Did you set up any lights in the scene?  Not the default Poser distant lights, something else like a point light or spot light. 

Also, you can change the sliders in Luxrender while rendering to get better results sometimes.

Quote - There are two different F-Stop parameters in Lux. One is for the "perspective" camera and affects depth-of-field but not sensitivity. The other is for the linear tone mapper and affects the apparent luminance of the image. The tone mapper F-Stop can be changed on the fly while rendering, while the camera F-Stop cannot.

Ok, well that would make sense of my experiences then ;o).

Laurie

Quote - You didn't necessarily do anything wrong, per se.

Did you set up any lights in the scene?  Not the default Poser distant lights, something else like a point light or spot light. 

Also, you can change the sliders in Luxrender while rendering to get better results sometimes.

I can't wait until we can get the Envirosphere transferred over (which I use in almost every outdoor render I do now...thanks BB ;o)). If that can mimic the sunsky, I'll be in seventh heaven...lol.

Ok, time to try an indoor render now, which means I'll have to set up portals. Wish me luck ;o).

Laurie