Re: OctaneRender® for Poser beta - build 1.01d [TEST]
Posted: Fri Dec 07, 2012 1:47 pm
Oh, and in general, thanks for the nice toy you're giving us to play...
Community Forums for OTOY Customers
https://render.otoy.com/forum/
Wow - nice render! I'll post that on the facebook site if you don't mind.Oh, and in general, thanks for the nice toy you're giving us to play...
2.62128 should convert a human figure into metres, which is the units for Octane. So light fall-offs, etc should match the real world. SSS doesn't really have absolute distance values (that I can tell). For SSS it's the ratio of the scattering version absorption multipled by the scale. I need to play around some more with the ratio, but am currently using 0.5/0.5 (for scattering/absorption), then tuning the amount through the scale (5-10 seems right if you use the skin material as the transmission).I noticed in the OctaneDefaults.py that you use a scaling factor of 2.62128.
Is this independent from the internal Poser settings (units, meters, inches) or should I use a certain setting in Poser to get a 'real world' scaling to Octane?
That might be important for settings like SSS...
Please doface_off wrote:Wow - nice render! I'll post that on the facebook site if you don't mind.Oh, and in general, thanks for the nice toy you're giving us to play...
Well, I'm still trying to find my way round this topic, but if I understand this correctly:face_off wrote:2.62128 should convert a human figure into metres, which is the units for Octane. So light fall-offs, etc should match the real world. SSS doesn't really have absolute distance values (that I can tell). For SSS it's the ratio of the scattering version absorption multipled by the scale. I need to play around some more with the ratio, but am currently using 0.5/0.5 (for scattering/absorption), then tuning the amount through the scale (5-10 seems right if you use the skin material as the transmission).
Paul
then this definitely refers to real world scales. In this example it would mean that light gets scattered most near the surface and less and lesser into the medium until at 4.5 cm there's no more scattering at all.The unit for absorption and scattering is m^-1 (or 1/m). If you have a measured value in cm^-1 you can convert it to m^-1 by
multiplying it by 100. For example: suppose you want to enter 4.5 cm^-1. This equals 450 m^-1. You can enter this value by
setting the scale to 1000 and the absorption texture to 0.45.
From my experiments, the scale definitely refers to a real-world metric, however it is also heavily dependant on the transmission. And with 0.18 in scattering, what are you putting in absorption? I found putting the scattering color in the transmission, and using floattextures for the scatter an absorption worked best for me. And the scatter/absorption ratio was important (ie. 0.5 scattering & absorption * 10 scale = 1 scattering & absorption * 5 scale).then this definitely refers to real world scales. In this example it would mean that light gets scattered most near the surface and less and lesser into the medium until at 4.5 cm there's no more scattering at all.
I don't have the slightest idea, how deep light can travel into a humans skin, but considering that you can see the effect nicely on back-lit earlobes I would guess a value of 1.5 - 2.0 1/cm might be realistic?
So - if the figure is correctly scaled, a setting like absorption:0, scattering:0.18, scale:1000 should work, no?
I haven't seen a case where saving a render would reset the render samples. If you adjust any of the Octane settings, the render will restart (just like in OctaneRender Standalone). The only time this doesn't happen is with resizing the viewport if the resolution lock button is active, or when adjusting "imager" settings. All other changes will result in a render restart (which is what should happen).just tried the new version, i works well but it seems to be a problem with the octane viewport refreshing ( ie when you save a picture, the render resets, and in some other case too apparently, like with materials operations, viewport window dragging, or GPU selecting). I don't remember the previous version behaviour but i gather it didn't do that.
If you ever have a problem like this again, copy a node, then check the octaneplugin.log file, and you should see the tree path of the copied node as the last entry. Then if you paste, you'll see more debug info in the log, so you can see what's happening behind the scenes. That might help work out the issue you are having.I had some trouble with copy/paste ( with mouse) materials but not sure it is a plugin failure, it worked, but not every time... strange... prehaps a the scene i worked with...
Yes, the spacebar is clunky. It was the most functionality I could cram into a small amount of time I had available, so I can refine it over time. It would be easy to spend days tweaking the color picker, but I'd rather work on other functionality it this point.For color picking, it would be perhaps interesting to smooth the process, actually it is still a little bit confusing with the spacebar system but the principe is good to my opinion ( an overlay colored panel with instant refresh would be so great, i know you know)
For the mouse tweaking, i'm not absolutly convinced but there is a good way to dig: the most-fastest acces tweaking appears to me still the strenght to optimize, perhaps another way is possible...should it be possible to directly open the first level of a material when poser--viewport clicking: a gain of 1click... (like the 3 clicks rule for web-site creation...)
This already happens - if you go into the Poser Material Room, and select a Poser material, it automatically selects the Octane material in the Material tab. Is that what you meant?Do you still plan to include the copy/paste material ?
I implemented Ctrl-C/V for copy/paste, but it was confusing to the user, so I have removed it for the moment. At the moment, if you click a tree item, the text entry (in the lower box) is automatically selected. So the Ctrl-C gets picked up in that box - so did the user mean to copy the node into the plugin clipboard, or the edit text into the Windows clipboard? Then for Ctrl-V, if it's a material it needs another menu to determine whether to copy texturemaps or not. For pasting, you have to select the node anyway, so rightclick does the select and brings the menu up with one click.Do you still plan to include the copy/paste material ?
I only did studies with frontal and side lights - not back lights. In those cases, I didn't find any difference between -1, 0 and 1 for direction. However the reflected light should be as important as the backlight - so I thought 0 would be the best for the direction.Direction goes more to +1 because we want the light to travel through and not reflected.
I found with absorption at 0, there can be a buildup of light inside the mesh - which is what is happening in her nose. Again, I'm not expert, but I found you need the absorption near the scatter value so that the light doesn't scatter forever.absorption:0, scattering:0.09
Yes, transmission is vital. Either pure red, or the diffuse texturemap. I havn't used an SSS map yet - but yes, I think it's needed. I had a lot of trouble where the correct SSS settings for V4's face make her hands glow bright red if there was a side lightYes, the transmission is crucial, and I found, I even need a SSS map because not all areas of the skin have the same transmission (lips, ears - more, legs, arms - less, you get the picture).