documentation volunteer (English and German)

[heretic]

Good to see you got started, thanks!

I've made some minor changes to the page regarding formatting and spelling and have a couple of remarks:

1. division between general and exporter specific information

The wiki consists of pages that describe LuxRender's functionality and features, and of pages that describe how to access this functionality through exporters. This way, one can get an overview of LuxRender's functionality without having to go through information that is not relevant for the modeling program that is being used. In your page, you make a similar distinction, but in its current form the page doesn't fit in the existing wiki structure. Sections 1 and 2 should be integrated in http://www.luxrender.net/wiki/index.php ... r_Lighting or form a separate page, section 3 should be integrated in http://www.luxrender.net/wiki/index.php ... nvironment.

On the other hand not showing how to enter the info makes it a hypothetical text? Imho its needed to show where to enter which info after we got it?

2. introduction text

When starting to read the page, it first looks like there are two separate ways a hdr file can be used (for example when writing "both maps"). Only afterwards it turns out there is no distinction between the two.

Actually there are three ways and LuxRender could be used for each alone. Unfortunately background is an issue with LuxRender. Ideal would be a combination - a 3 slot environment design: HiRes-LDR to show the background without providing lightning (on parts not covered by the geometry), HDR to make reflective surfaces and lowres HDR to light the scene.

Problem with HDRs up to 3K is usually the occurence of "lit spots" in the HDR happenign in a lit part (eg caustic) on a high contrast surrounding (eg a dark table with low diffuse and reflection). Those issues dont arise with low res HDRs for lightning - thats why they are so blurry. Alas this would be perfect for using sIBL in lux.

Anyway we dont have it in lux, so I didnt elaborate there. Still for people used to the "normal" naming I thought it important to clarify.

I think the notes about fitting in background images should form a page of their own; a tutorial might be the most suitable format. By moving this section, the topic will not derive too much in the LuxRender lighting page.

On the other hand I bet several users think about using environment map that way. I wouldnt spread this info over several wikis as long as there is no specific wiki for background (see below).

Regarding the notes: I have never heard of a win-mapped image. Also I have some doubts that a spherically mapped background would work in combination with LuxRender's hdr lighting.

Blender example <click>

Win - Window: The rendered image window coordinates. This is well suited to blending two objects.

Other render engines call it sticky-Window or sticky-Camera texturing (even though all those are different techniques suitable for distinct issues).


Spherically? You mean the SkyDome I figure?

3. background/preconsiderations

The text "LuxRender offers to compensate such issues, but this can be tricky" leaves me with more questions than with answers, could you specify how this works?

Overall poor lightnign can be adjusted with "gain", in some scenes (eg a night scene) the tonemapping options in LuxGUI can fix some issues after rendering, in more extreme cases one could adjust the Gamma of the LDR in LuxRender or even create the materials to "cooperate" with the weird lightning. Overall lightnign groups also help to compensate a poor LDR for lightning by aligning lights with the background (tricky), adjusting rendering (more tricky)... (those are the first few options which come to my mind - am sure there might be some more).

Still I felt that wiki is the wrong place to elaborate - this fits to a future "background wiki". (Preferably if someone would add sIBL support ). Sorry but sIBL is plain cool for a good background so I tend to mention it.

4. image
The projection image is nice! If you made it, great! Otherwise, are you sure we can use it under the GNU Free Documentation License?

I modified an existing one and extended it. The license of the base image is CC non-commercial (which luxRender is - non-commercial). Personally I have the authors written permission to use his images even commercially. All that by including his site URL on each page where his images appear (which in fact happens to be the link at the end of the wiki).

Pheww Looking forward to your answer.

[heretic]

ahh thx just wnet through your changes - I missed all those wiki descriptors and thought those are disabled - got em now

[Abel]

1. division between general and exporter specific information

Of course we need to show people how to apply information about lighting principles. But as there is quite a number of exporters, all with their own instructions, pitfalls and exceptions. Trying to include all this information in one page will lead to a very long page. Of course we could do that and then split the very long page in multiple sections (like one for point lights, one for area lights, one for hdr etc), but then I'm afraid the overview will get lost.

The general LuxRender documentation is not only available on the wiki, it's also part of the main website so that people get an idea how the program works: http://www.luxrender.net/v/manual_lighting.

I understand that there are multiple opinions about the best way to categorise information, but at the moment there are 140 pages that follow the current system. Trying to change things by doing things differently on new pages will not make things any clearer. I'm open to suggestions how to improve things, but if you're serious about it, please start a separate topic.

Ideally, in the general documentation section there should be links (maybe icons) that link to the relevant sections in the exporter manuals. This is one of the many tasks on the todo list that is just waiting for somebody willing to spend time on.

2. introduction text

I fully agree that this information should be presented. My comment is just about the way of formulating it: instead of first saying there are two ways, then saying there is only one (while apparently there are three), we could say something like "In LuxRender HDR files can be used as a light source that influences lighting, reflections and the image background. As opposed to some other rendering engines, a single file is used for all these functions."

Regarding the IBL file feature request, it's best to start a thread about it or even file a report in the bug tracker. I've been wishing for ways to separate lighting and reflections myself.

2b. background images

About all topics are related. HDR lighting may or may not be an important enough part of lighting to have a page of its own, but background compositing tips do not belong in a page that is supposed to give an overview of lighting types. Of course in a tutorial multiple topics can be combined and relevant links can be placed in the lighting page.

I would almost go so far as to say that putting information in the right place is about as hard as generating information.

2c "- self made sphere in the hosting 3d-application around the scene"
When putting a sphere around the scene, how is the HDR lighting supposed to reach the scene?

3. poor lighting improvement
I wouldn't call adjusting image gain a method of improving an image. The gamma trick may be worth mentioning, in particular when it would be accompanied by a good example image. In any case, if you're referring to tricks but don't think those tricks have a place in the wiki, I think there is little point in mentioning that they exist.

3b. lighting/lightning
Please check the meaning of those terms. The word lightning gets abused a lot.

4. image license
CC-non commercial licenses are not compatible with the GNU FDL as the FDL does not restrict commercial use and we cannot control if the links will be present. Could you please check with the authors that they're ok with publication under the GNU FDL, even without a link? If not, we can't use the image.

5. LuxBlend section

"Any other adjustments (dark moody lighting, switching to night-like lighting from a sunlit image etc.) should be controled in LuxGUI upon the final render."
At the moment, adjusting light groups in the GUI lowers the rendering efficiency as sampling takes the original light groups into account, so I would not recommend this workflow.

[heretic]

4. image license
CC-non commercial licenses are not compatible with the GNU FDL as the FDL does not restrict commercial use and we cannot control if the links will be present. Could you please check with the authors that they're ok with publication under the GNU FDL, even without a link? If not, we can't use the image.

Ok one cleared with the author (its German, still its an answer):

Hallo Martin,

Ja, klar kannst das Bild da gerne verwenden so wie es im Wiki steht.

<snip>

Viele Gruesse,
Christian

Hello Martin,

yes, of course you are allowed to use the picture in the way it is used in the wiki.

<snip - reference to different topic cut>

Kind regards

Christian

---
Where Christain is the author and Martin my name.