I'd share my binaries, but can only compile things for Linux, not Windows or Mac. So that won't help most people here.

Adventurous sould could try the "Weekly Testing Builds" forum on the Lux site (http://www.luxrender.net/forum/viewforum.php?f=30). Or maybe someone else can help out with a Windows build?

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

For me the ready-to-go packs worked. Linux and Windows.

You can't do anything wrong. If it does not work for you, replace it with your backup.

I wasn't able to use the weekly binary for Linux. But I think that was due to some Ubuntu-specific problem. It may be time for me to upgrade to 10.4 or go look for a better distro.
[/OT]

Quote - I wasn't able to use the weekly binary for Linux. But I think that was due to some Ubuntu-specific problem. It may be time for me to upgrade to 10.4 or go look for a better distro.
[/OT]

10.4 with Gnome is running fine here. If you use KDE Suse may be a better choice.

I haven't upgraded yet because 10.4 didn't work so great with my ATI graphics card. It might be time to see if that problem has been fixed in the meantime.

I found the problem with camera export to be as follows:
Using width>height (landscape), the camera will look zoomed out.
Square and portrait look right.

So to fix the problem, one has to do
if width>height: fov=fov * height / width

Quote - So to fix the problem, one has to do
if width>height: fov=fov * height / width

Not quite! What's called fov ("field of view") is actually an angle.

odf: Well, I have no idea about that, I have to admit, but it worked for the few camera settings and image sizes I tried it :-)

Good morning (for me anyway).

I just put 2+2 together and got 6.

odf, you just talked about newer builds that don't present fireflies.

Two days ago I bought a new computer and started seeing the camera be positioned incorrectly. For the new machine I downloaded LuxRender - did not copy from my laptop.

On my laptop with an older LuxRender on it, the camera is perfect all the time.

Possible conclusion - LuxRender fov changed in the last two weeks?

Untested, because I couldn't be bothered to decide how to best get the viewport dimensions into the camera export function. But I think one would have to replace

        fov = 360 / pi *
atan(12.75 / focal)<br></br>

with something like

       if width
> height:<br></br>
           f =
height / width<br></br>
       else:<br></br>
           f =
1<br></br>
       fov = 360 / pi * atan(f
* 12.75 / focal)<br></br>

Your version should be a pretty good approximation for the range of focal lengths and image formats most people would use, though.

Edit: that was answering Dizzi, obviously.

The viewport dimension does not go into this function - why do you guys refer to that so often?

Viewport dimension is not a factor in the field of view calculation.

If we are working around a new Lux bug, that bug should be removed in Lux, instead of messing with the exporter.

The field of view contract can't keep changing every week.

Yes, if the Lux code is wrong, that code should be changed.
But to keep people able to use the alpha exporter the best possible way, it should work with what people get from the LuxPage. That doesn't mean that existing code should be changed, so no one remembers the correct code later on. Maybe add a parameter to query for every workaround.

In Lux, the field of view refers to the longer side of the viewport. In Poser it always refers to the width. That's why for images that are wider than high, a correction term is needed.

Quote - Yes, if the Lux code is wrong, that code should be changed.
But to keep people able to use the alpha exporter the best possible way, it should work with what people get from the LuxPage. That doesn't mean that existing code should be changed, so no one remembers the correct code later on. Maybe add a parameter to query for every workaround.

I'm fine with that but let's be really more careful about specifying dates of download and/or very specific LuxRender version numbers.

I downloaded 0.7 at two different times, and now I have two different behaviors. If we change LuxPose to compensate for today's version, it breaks the version on my laptop that was from two weeks ago, that has the correct fov at all times.

And the firefly problem will force people to stay behind. If I had been a LuxRender user in the days of 0.6, and then I saw how badly 0.7 behaved, I would have stayed on the older version.

I think that I'll add a parameter right now that specifies the LuxRender version you're going to export to and what date you got the code (or binary) so that if there are weekly differences (as I expect there will be on such a project) we can put all the different logics in the exporter and leave it to the user to choose which to use.

Quote - In Lux, the field of view refers to the longer side of the viewport. In Poser it always refers to the width. That's why for images that are wider than high, a correction term is needed.

odf - look above, you're dealing with

if width > height

width being the longer side

Clearly the interpretation HAS CHANGED.

You and I tested this extensively two weeks ago. It was PERFECT.

Quote - > Quote - In Lux, the field of view refers to the longer side of the viewport. In Poser it always refers to the width. That's why for images that are wider than high, a correction term is needed.

odf - look above, you're dealing with

if width > height

width being the longer side

Clearly the interpretation HAS CHANGED.

You and I tested this extensively two weeks ago. It was PERFECT.

Sorry, I got slightly confused! The longer side is what the manual says, but my version (and Dizzi's, apparently) seems to be using the shorter side.

My point was that Lux does not measure the angle of view like Poser does. You may be right that different versions of Lux do it inconsistently and we should be careful.

I think it would be a very very good idea to include some "reference scenes" in LuxPose.

Many of them. And they must not use external OBJ so they cannot use Poser Primitives. Poser Primitives have changed from one version to the next.

To start, we should have a reference scene RIGHT NOW that helps us judge camera position and aspect ratio, that all users can run, and we all know what to expect, and we also will all learn and easily recognize specific kinds of problems. I imagine, for example, in a few weeks we'll all know right away to ask "did you download LuxRender in mid August?"

I just did a quick test. Regarding the angle of view, my (supposedly) official Lux 0.7 download seems to behave exactly like the version I built from the sources. It always refers to the shorter side.

Anyway, if indeed the Lux developers changed the download file without updating the version number, they deserve to be spanked.

I'm going to assume that I made a mistake in testing. It's not uncommon when I'm dealing with unfamiliar software that I do things or change things without being aware of doing so. Then my mental model of what I tested for and what I saw gets all screwed up.

My recollection, which I do not trust, is that odf raised the question about aspect ratio influencing field of view, and I tested for that, and found it behaved the same as Poser.

But what I acually tested was 400 by 400, then 400 by 800, and I concluded that it is always width. I did not test 800 by 400 - had I done so I would have noticed that it is always the shortest side, opposite to Poser. Later I'm sure I did 600 by 400 but did not notice fov because by then I was looking light positions and shadows.

I looked more closely at the vimeo movie showing the GPU rendering of the Audi R8.

The rendering speed was around 1240 K samples/second, with what looked like 4 bounces (it was doing about 5000K rays/second.)

I have now the same CPU, the Intel I7 860, as was used in that video. After making a couple casual setting changes, I get 750K samples/second in CPU ONLY - NO GPU!

Looks like there is a teeny bit of smoke and mirrors in that demo. If you have a blazing fast CPU, the GPU is only a tiny incremental improvement, if at all.

I've tried to use the mattetranslucent material type (mixed with glossy) to get some fake SSS going, but I'm not sure that had much of an effect except in slowing down the render. More experiments later. If I had the time, I would start writing a material editor right about now, but I don't.

Attached Link: http://blog.cudachess.org/2010/06/debunking-the-100x-gpu-vs-cpu-myth-an-intel-paper/

Well, Intel thinks so, too. See link.

hey.. I'll take any boost I can get.... GPU, CPU, Networking, trained monkey's with abacuses... anything to get the render times down...

Luxrender (CPU): 11 min. 34 sec. - 0.09Ms/s
Octane (GPU) 20 sec. - 3.24Ms/s

We got any comparisons Octane vs LuxGPU? I think I had about 6x increase LuxCPU vs LuxGPU but only tested the included helloworld scenes yet.

Didn't know there was a LuxGPU. You have a link ?

Its a bit hidden, and still in alpha state I think.

http://www.luxrender.net/wiki/index.php?title=Luxrender_and_OpenCL

Most of the magic is happening in the forums (including download links)

http://www.luxrender.net/forum/viewforum.php?f=34

You need to register I think.

Appearently they released v1.7beta1 just today. Yay.

That's only for Blender, right?

on a side note:

Would someone be kind enough to just keep an eye on the wiki page just to make sure I don't add any wrong information? I sure ain't perfect...lol. Just sitemail me if you see a problem and I shall fix it forthwith ;o).

Thanks!

Laurie

There are several exports mentioned, blender, max and sketchup.
But I assume the input formats are bit different, because I do not see any of the lx* files in the example folders. Its rather a .scn and multiple .ply files.
But I cannot really comment on the things, did not look at anything closely yet due to lack of time :(

**Exporter Updated **

Includes new code from odf. Mainly fixes and speed-up while exporting geometries.

Because the light intensity is raised, I have to use a very high fstop now in Lux if I use kernel: linear.
Better make sure all lights together don't exeed 100%   in your Poser light setup.

Quote - on a side note:

Would someone be kind enough to just keep an eye on the wiki page just to make sure I don't add any wrong information? I sure ain't perfect...lol. Just sitemail me if you see a problem and I shall fix it forthwith ;o).

Thanks!

Laurie

Looks fine for me.

Thanks adp :o).

BTW...I tried the latest weekly build of LuxRender (Windows) with a scene I was getting a huge amount of fireflies in. So far, I'm getting none :o).

I'll post when it's done.

Laurie

Laurie I am getting huge amounts of firefles also, do I just go to the main  page for Lux, to get the latest build? Thanks

What you want is here.

I used SSE2. I'm not sure what the difference is. Make sure you back up your installation of the current Luxrender. Thankfully, you can run the newest build from the unzipped folder ;o).

Laurie

Quote - **Exporter Updated **

Includes new code from odf. Mainly fixes and speed-up while exporting geometries.

Because the light intensity is raised, I have to use a very high fstop now in Lux if I use kernel: linear.
Better make sure all lights together don't exeed 100%   in your Poser light setup.

adp this is bad advice, keeping under 100%. The sun light must be 4 to 8 times brighter than any "bulb" type of lights. If you want a living room or kitchen light on, as well as outdoor lighting for looking through the window, you will need the kitchen light at, for example, 75%, and the sun light outside at 600%.

The total light amount is irrelevant precisely because you can adjust exposure in the target renderer. You can expose for out the window, or you can expose for in the kitchen.

Think like a camera. Do you, when using a camera, tell the sun to stop radiating at full power?

No.

If you're really thinking about accuracy, look at the EV value shown by the renderer, at the bottom right. If you are outside at noon on a sunny day, it should be EV=16. That is 256 times brighter than indoors.

Thanks Laurie :)

Quote - > Quote - **Exporter Updated **

Includes new code from odf. Mainly fixes and speed-up while exporting geometries.

Because the light intensity is raised, I have to use a very high fstop now in Lux if I use kernel: linear.
Better make sure all lights together don't exeed 100%   in your Poser light setup.

adp this is bad advice, keeping under 100%. The sun light must be 4 to 8 times brighter than any "bulb" type of lights. If you want a living room or kitchen light on, as well as outdoor lighting for looking through the window, you will need the kitchen light at, for example, 75%, and the sun light outside at 600%.

The total light amount is irrelevant precisely because you can adjust exposure in the target renderer. You can expose for out the window, or you can expose for in the kitchen.

Think like a camera. Do you, when using a camera, tell the sun to stop radiating at full power?

No.

If you're really thinking about accuracy, look at the EV value shown by the renderer, at the bottom right. If you are outside at noon on a sunny day, it should be EV=16. That is 256 times brighter than indoors.

Right, yes.

But we are in a stage where lots of people do a first try with their existing Poser scene. A Vickie, some props and 3 or more point-/spot-/infinite lights. If they don't get a result by pressing a button, they tend to reject Lux. Because for most people here a renderengine is fun, no science :))

I agree that most Poser users will need a lot of, um, "re-education" in order to get a good render out of LuxRender ;o). Most will be resistant. Some will be all for it...lol.

Laurie

Quote -
Right, yes.

But we are in a stage where lots of people do a first try with their existing Poser scene. A Vickie, some props and 3 or more point-/spot-/infinite lights. If they don't get a result by pressing a button, they tend to reject Lux. Because for most people here a renderengine is fun, no science :))

It may be better to just set the default tonemapping to reinhard.

Right at the top on the page with weekly Lux builds we find:

*The LuxRender team is pleased to bring you the third (and last?) pre release of the upcoming 0.7 version.

Based on feedback from the first 2 pre releases, we've fixed a whole lot of bugs and polished the GUI and LuxBlend exporter. I want to thank the whole dev team for its commitment to improving LuxRender. We're not aware of any major bug left, please report any in Mantis. 

So we can assume the way how Lux works now is "the last word" (especially this camera problem)

So, am I to assume that they've been fixing the main download version and yet not changing the version number? How confusing....

I did download LuxRender and installed it before the last weekly build was posted, so I guess if I download it again and reinstall it's going to fix the fireflies problem...

Laurie

Quote - So, am I to assume that they've been fixing the main download version and yet not changing the version number? How confusing....

I did download LuxRender and installed it before the last weekly build was posted, so I guess if I download it again and reinstall it's going to fix the fireflies problem...

Laurie

They did not change the official download version. If the weekly build fixes your fireflies problem, stick with it.

Quote - > Quote - So, am I to assume that they've been fixing the main download version and yet not changing the version number? How confusing....

I did download LuxRender and installed it before the last weekly build was posted, so I guess if I download it again and reinstall it's going to fix the fireflies problem...

Laurie

They did not change the official download version. If the weekly build fixed your fireflies problem, stick with it.

Right. I'm confused...lol.

Laurie

Quote - So, am I to assume that they've been fixing the main download version and yet not changing the version number? How confusing....

I did download LuxRender and installed it before the last weekly build was posted, so I guess if I download it again and reinstall it's going to fix the fireflies problem...

Laurie

No No No -  build (0.7RC3) is NOT the official version. It's a release candidate (RC). It's published to find errors. If no more errors are reported they will make this build the official one.

Quote - > Quote - So, am I to assume that they've been fixing the main download version and yet not changing the version number? How confusing....

I did download LuxRender and installed it before the last weekly build was posted, so I guess if I download it again and reinstall it's going to fix the fireflies problem...

Laurie

No No No -  build (0.7RC3) is NOT the official version. It's a release candidate (RC). It's published to find errors. If no more errors are reported they will make this build the official one.

Gotcha :o).

Laurie

Quote - Right at the top on the page with weekly Lux builds we find:

*The LuxRender team is pleased to bring you the third (and last?) pre release of the upcoming 0.7 version.

Based on feedback from the first 2 pre releases, we've fixed a whole lot of bugs and polished the GUI and LuxBlend exporter. I want to thank the whole dev team for its commitment to improving LuxRender. We're not aware of any major bug left, please report any in Mantis. 

So we can assume the way how Lux works now is "the last word" (especially this camera problem)

Now you have completely confused me as well.

LuxRender 0.7 RC3 was published June 6. Well BEFORE 0.7 was released.

LuxRender 0.7 (official) was published July 9.

http://www.luxrender.net/forum/viewtopic.php?f=12&t=4209

I could be wrong, as I don't have time to chase down everything that looks wrong to me, but your info about RC3 looks wrong to me.

The 0.7 official July 9 announcement also says (confusingly)

Quote - Changes since v0.7RC3:

• bug fixes (mostly to reduce fireflies)

I say confusingly because it looks like you're telling us RC3 is newer than the released 0.7, while the Lux site tells us the opposite.

Quote - > Quote - Right at the top on the page with weekly Lux builds we find:

*The LuxRender team is pleased to bring you the third (and last?) pre release of the upcoming 0.7 version.

Based on feedback from the first 2 pre releases, we've fixed a whole lot of bugs and polished the GUI and LuxBlend exporter. I want to thank the whole dev team for its commitment to improving LuxRender. We're not aware of any major bug left, please report any in Mantis. 

So we can assume the way how Lux works now is "the last word" (especially this camera problem)

Now you have completely confused me as well.

LuxRender 0.7 RC3 was published June 6. Well BEFORE 0.7 was released.

LuxRender 0.7 (official) was published July 9.

http://www.luxrender.net/forum/viewtopic.php?f=12&t=4209

I could be wrong, as I don't have time to chase down everything that looks wrong to me, but your info about RC3 looks wrong to me.

The 0.7 official July 9 announcement also says (confusingly)

Quote - Changes since v0.7RC3:

• bug fixes (mostly to reduce fireflies)

I say confusingly because it looks like you're telling us RC3 is newer than the released 0.7, while the Lux site tells us the opposite.

Agree with BB here. When choosing what to download a while ago I looked at the files quite carefully. Official 0.7 seems to be the latest build with the weekly release moving on from there.

agreed. RC = Release Candidate

sorry.. but 0.7RC3 was the last version before 0.7 was released!

also I was using Rc3 with Sketchup before .7 !!