+- Wings 3D Development Forum (https://www.wings3d.com/forum)
+-- Forum: Wings 3D (https://www.wings3d.com/forum/forumdisplay.php?fid=1)
+--- Forum: Design & Development (https://www.wings3d.com/forum/forumdisplay.php?fid=6)
+--- Thread: YafaRay Plug-in - reviewing for Yafaray 3.0 (/showthread.php?tid=2053)
RE: YafaRay Plug-in - reviewing for Yafaray 3.0 - oort - 07-26-2016
I noticed that the render settings menu was slower to load after the addition of the passes menu....
oort
RE: YafaRay Plug-in - reviewing for Yafaray 3.0 - david.bluecame - 07-26-2016
Hello,
I agree, we could add a "render passes enable" checkbox and/or limit the number of passes to avoid the slowdown. 32 passes is just the maximum I've set Core for 3rd party plugins, but we can reduce them in the plugin as long as the users have enough. I suppose most people will use 1 to 10 render passes.
However if the slowdown is caused by the loading of the menu options showing the available passes, not much can be done.
RE: YafaRay Plug-in - reviewing for Yafaray 3.0 - micheus - 07-26-2016
It's not about load time. It's more about esthetic and usability.
RE: YafaRay Plug-in - reviewing for Yafaray 3.0 - david.bluecame - 07-29-2016
Hello, guys.
For your information, you can see the progress of my modifications in the YafaRay plugin here:
https://github.com/DavidBluecame/wings/commits/yafaray_v3
If you want to try the plugin, the latest version is always here:
https://raw.githubusercontent.com/DavidBluecame/wings/yafaray_v3/plugins_src/import_export/wpc_yafaray.erl
I hope you find this useful.
By the way, for the Params Badge position parameter to work, you need to remove the -pbp xxx options from YafaRay plugin preferences.
In fact, I think it's best to do this in the new YafaRay plugin preferences:
* Set the path to yafaray-xml (the one in v3.0.2-beta)
* You can leave the plugins path empty, as YafaRay v3.0.2 should be able to find them automatically (but make sure it's empty and no space marks are there!)
* You can leave the options field empty as well. YafaRay v3.0.2 should just work.
RE: YafaRay Plug-in - reviewing for Yafaray 3.0 - oort - 07-29-2016
David,
Thanks for the update. You have been busy. I hope to be able to test the latest version of the plugin soon.
I read the commit notes. Glad that Volumetrics no longer requires the Temytex name. Also, that would be great to no longer require min/max values for the volume. Micheus may be able to help you with coding that??? Not meaning to volunteer any more work for him...
Edit: Could you please post a compiled .beam file for testing.
Thanks,
oort
RE: YafaRay Plug-in - reviewing for Yafaray 3.0 - micheus - 07-29-2016
I away from home until Sunday morning. If there is anything that I can help just let me know.
RE: YafaRay Plug-in - reviewing for Yafaray 3.0 - david.bluecame - 07-30-2016
Hello,
I've uploaded the .beam of the work in progress (but working, I think) yafaray plugin:
https://github.com/DavidBluecame/YafaRay---unofficial-Builds/blob/dacafda3b310fd335c0a75f1af39e28ce9a55ab4/wpc_yafaray%20beam%20plugin%20-%20wings%20yafaray_v3%20-%20v2.0.5-17-gdf80c8e%202016-07-29.zip?raw=true
This beam is updated up to the commit https://github.com/DavidBluecame/wings/commit/df80c8e10e82e07d8925b4cf8d473954b9b121fb (inclusive)
There are many changes respect to the original, as you can see in the GitHub commits. An important change is that in the original, the AA processing was not really correct even for older YafaRay versions. This is how it should work:
* The first pass (rendering all pixels) renders the number of samples specified in "aa_minsamples". This was ok.
* You can specify additional passes with "aa_passes". For subsequent passes, it would only render the pixels detected by the AA Threshold, and it would render a number of samples per subsequent pass specified in "aa_incsamples". This parameter was missing in the original plugin, so even for old YafaRay or Bounty versions that would cause Core to assume aa_incsamples=1, and therefore it would only render 1 sample per subsequent pass even if you had set minsamples to 20, for example (only the first pass would have rendered 20 samples, and the subsequent passes only 1 sample/pass)
So, I fixed it adding the missing "aa_incsamples" parameter and I also added quite a few AA/Noise control new parameters I added to Core v2.1.1 and v3.0.2:
* Detect color noise: the original AA algorithm only detected noise based on the brightness of the pixel and surrounding pixels. I found this not good enough when color noise was present where the brightness was similar but the color was different. I added a "naive" color detection algorithm (very simple, but it seems to work ok) that you can enable to better detect color noise even if the brightness of the pixels is similar. I recommend this to be enabled.
* Dark AA Threshold compensation: I also found AA was unable to detect noise in dark areas because it was a "constant" threshold. So, I added two "variable AA threshold" options:
- Linear: the AA theshold is calculated per-pixel based on the AA threshold parameter, the pixel brightness and the parameter "Dark Factor" which is more or less the slope of the AA linear transformation depending on pixel brightness. If used, the AA Threshold needs to be increased a bit. For good results, I would suggest: Enable Color detection, Set AA Threshold Compensation to Linear, AA Threshold = 0.1, Dark Factor = 0.9. That should detect noise in dark areas nicely. For detecting noise in near-black areas, you can use Dark Factor = 1.0
- Curve: the AA threshold is calculated based on the pixel brightness and a fixed curve (in this case the AA threshold parameter is not used at all). I'm not sure if it works well or not, but it was a suggestion from one member of the YafaRay team and I thought it was worth implementing. In any case I've left it in YafaRay v3.0.2 so you can try it.
* Variance pixel detection: I noticed in the past that normal AA didn't detect well certain types of noise, where bright pixels are separated. Only the bright pixels were re-rendered but many of the pixels in between were not. I added an option called "variance" which is basically a "moving window" that counts how many pixels vary in that window more than AA threshold. If it reaches a certain value, it would render additional samples for the entire window and add more samples to it. So, there are two parameters: the size of the window (lenght of the edge), and the number of pixels over which it will trigger the additional samples rendering. If pixels = 0, this function is disabled. You can experiment for example with pixels = 4.
* Multiplier Factors: this was a request from a YafaRay team member. He said that to reduce Montecarlo noise we should increase the number of samples we render in each pass. So, if the multipliers are = 1, it will render the same (aa_incsamples) number of samples per each pass. If the multiplier is, for example, 2, then it will render 2x samples respect to the previous pass (exponential!). For example multiplier 2 and incsamples=1: pass2 : samples 2, pass3: samples 4, pass4: samples8 and so on...
The first multiplier factor would affect the aa_incsamples value in each pass. There are two more multiplier factors: one would affect the Lights samples and the other the Indirect samples (Final Gather in Photon Mapping mainly).
* AA Resampling Floor: this comes from a YafaRay team member request. He said that, the more passes you put, the more difficult to remove noise. I added a parameter I called Resampling Floor that is in % of the image total size. When the number of pixels rendered in a certain pass is lower than the "floor", it will automatically lower the AA_Threshold for the next pass to try to render a bigger amount of pixels. I think it's an interesting feature, but it's for you to test and explore.
Also I added the new v3.0.2 Parameters Badge, Logging and the new TXT and HTML log files. I think they are more or less straightforward, I hope you like them. Now you can control the verbosity of the Console and the TXT/HTML log files with parameters and no longer need to set them in the YafaRay plugin preferences options.
I hope you like these changes, but this is still a work in progress. Best regards!
RE: YafaRay Plug-in - reviewing for Yafaray 3.0 - micheus - 07-30-2016
A lot of work! It seems these changes related to AA van fix the problemas oort and I was discussing in the other thread. I can't wait for test it.
Thanks.
RE: YafaRay Plug-in - reviewing for Yafaray 3.0 - oort - 07-30-2016
David,
I did a few quick tests and everything seems to be working. The changes look good from what I have seen so far. I did notice that Wings3D does not know how to handle the viewing of the rendered image with the parameters badge turned on. No big deal just thought I would mention it.
I did not realize how important the aa_incsamples setting was, so never added it...
Micheus, I think that YafaRay does not like the way the model in the other thread is put together.... I still get the lines when I render it.
oort
RE: YafaRay Plug-in - reviewing for Yafaray 3.0 - david.bluecame - 07-30-2016
Hello,
With the GIT wings version under Fedora 24 it can handle the rendered image even if it has the badge at the top or the bottom. What wings version are you using? Windows version?