Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
That is good to know, thanks Kettu. I've spent the past few hours with a simple cylinder establishing a baseline. I had a suspicion that 3delight would just treat a simple cube as six quads and ignore any SubD values on the faces of the cube. Well, it looks like with smoothing on in the surface tab (the default setting for all three shaders), it also dose similar for round things, in the opposite way. Apparently the smoothing is adding more of something then what the base SubD is set to, making all the no-SSS test runs above SubD 0 all take the same amount of time (within ten seconds for each shader).
I'm also seeing a very interesting trend across all of the shader tests as well. Apparently having SubD applied to a surface and it set to Base is indeed faster then not having SubD at all on a cylinder. That is rather odd, and not something I expected to find.
The first run, was just Diffuse. No gloss, No velvet, no Sub Surface, No opacity, and no reflection. it was a simple 2ft by 2ft Studio Primitive cylinder with 32 segments and 32 sides (1,058 vertices, and 1,088 faces), rendered in my test chamber at 1024x1024 progressive mode for each render. The render times are directly from the 'log' file (M - Minutes, S - Seconds, Ts - Total Seconds) I did a few extra duplicate runs on the Daz Default to see what kind of variation was caused by the Operating system as well. From the looks of it, most of the tests are good to the 'Tens' of seconds, mostly.
Another oddity I noticed, was at no SubD and with subD at Base, the AoA shader had an odd effect on the top edge of the cylinder that the Omni and Daz Default did not have.
And by the way, lol
This is what a 32 sided cylinder looks like at SubD of 4.
(EDIT, and some times for reflection. mid gray diffuse, 50% reflection strength.)
Apparently I was wrong regarding SubD affecting the face-plant time of the AoA shader, so I'm not sure what is going on yet. I'm still taking measurements so it will take some time to get enough data to have a complete picture of what is going on. Tho it appears that the SubD has nothing to do with render time or Sub Surface Precompute delay, short of the difference between Base and "High Resolution" setting. Rather eyebrow raising results given the drastic difference in render times and Sub Surface Precompute delay of regular and HD figures. Fascinating (looks back into the console scope).
WARNING: QColor::setHsv: HSV parameters out of range
Hmmm. OmUberSurface apparently needs a tad bit of color to keep Sub Surface from dumping out, lol. I tried 50% strength, I tried different gray values, etc. I figured it had to be Sub Surface, because the warning went away when I turned it off. Another oddity, was a consistent one-second pre compute delay across the board with Sub Surface on, hmm.
I then tossed green in the color box to see if Sub Surface was doing anything at all, and it started working without any errors, lol. All right, green it is.
P.S. According to unrelated code from elsewhere with the same exact error text, "HSV" is short form for Alpha, Hue, Saturation, and Value (instead of Red Green Blue).
I redid the AoA measurements using the 'green' Sub Surface, and the times are rather consistent to before. Also as mentioned before, there is no variation of time as the SubD is increased as well. I'm thinking that perhaps something that figures have that the Studio primitives don't have is responsible for the rather dispassionate render times, tho I'm still working threw the possibilities.
One that I'm working on now, is that a Primitive is a single zone, where as figures have multiple surface zones on the mesh. I sent the cylinder to hexagon, and set up three zones, the bottom half, and the top half split in half.
However from what little I've tested on a three-zone version of the same cylinder appears to not be effecting times at all. At least not on the Uber shader, I'll test the AoA as well, just to be sure.
Another possibility may be with the mesh, the primitive is static, where as a figures mesh is weighted (rigged) in one of a few ways. I'm not sure how or if weighting a mesh would effects the render times of a surface shader, tho it is a possibility that at least needs to be ruled out if it is not causing the expediential render times.
Yup, exactly. When I was writing my SSS tutorial, I measured that for the free UberSurface SSS to start working, the difference in RGB values of the SSS colour swatch should be 20 points or more for two channels, otherwise it doesn't work. So R255-G255-B-234 will work, but R255-G255-B-236 will not.
It's obviously whacky, but that's the way it is. The paid-for UberSurface2 doesn't have this restriction.
There is a reason for it...but I can't eactly remember what it is. Something with the way US1 does SSS requires a non-grey (equal) value to work. But it should work with grey AND an image.in the SSS color.
But it doesn't =( Didn't work that way in DS3, doesn't work in 4.9 (just checked). Only the colour swatch difference kicks off the computations. Probably it writes the scatter/absorption attributes out of range otherwise.Way back, in one of the old threads, on the old (the one before the last forum software switch) forums, there was a long thread on SSS...about how Poser 'had' it and DS didn't. In that it was discussed that Ubersurface NEEDED a color. It may not have produced an error...but it didn't work as expected if it had an equal value grey (or white) for a color. And I think, from that same thread, it was found that the color and image in SSS color are multiplied to give the 'final' SSS color, so a map and grey(white) should work.
Unless it's doing some sort of funky colorspace conversion...
I obviously have no idea what it's doing with its encrypted scripts, but it just renders black when the swatch is grey/white/very-slightly-tinted, map or no map. When the colour is non-grey, it will multiply with the map and render correctly.
I was thinking about that...if there is a color conversion (like to HSV) then something isn't quite right.
Wow, that sparked off a good chat, lol. That 20 point thing is good to know kettu, and I only found a non gray to work as I was looking for a visual clue that it was actually doing something despite the error. The jump from 1.25 seconds to over ten seconds "Face Plant Time" was enough for me to have a clue that it was just dumping out (that and the cylinder was rather dark without the green SSS, lol).
I have no clue if it is converting RGB to HSV or not, however it is indicating an out of range variable, even if it is just a Value-Not-used indicator. The section of unrelated code I found the error test in was in a section of error checking functions, and I didn't look at the rest (I just wanted to know what the error was). Around it was functions for the same kind of error checking on RGB and CYM values, so that was enough to figure it out what the error was about.
https://github.com/impagina/core/blob/master/libraries/QtNoGui/qcolor.cpp#L1034
(lets see if that link works)
So, it looks like smoothing "on" in the surface tab dose improve the SSS times a little, tho it still is not causing the drastic times that HD figures cause, and it is so small it is almost not worth bothering with, hmmm. (atached number chart)
B.T.W. I think it is safe to say, smoothing vs SSS dose NOT cause drastic FPT. And I found that the Daz Default is indeed faster then Omni with simple reflective surfaces, by about a minute on the test cylinder.
Evn given that, much more to test still. (Diffuse in that 'velvet test' is 128R 64G 64B, good enough to get some times)
(looks back into the console scope).
Subdivision and HD morphs go hand in hand...
The simple tests I was doing with the cube does indicate that there is a difference.
Now, one possible way it matters...
Since 3Delight does NOT support Catmark subdivision, there has to be some sort of translation occuring. My guess is that Studio is simply fully tesselating the mesh and writing it out as a polygon mesh, not a subdivision surface (and yes, that is a very important distinction to the renderer). Without an HD morph 'on' there are no deltas to figure out and then write. But with the morph on, there are now hundreds of thousands of deltas to calculate (being split several times from a few thousand intial ones) and then write as mesh data.
And since we don't have access to creating our own HD morphs...there is no way to test it.
Also the small difference, when going with the process above would definitely be compounded. (for that matter...one possible way of doing the conversion...once for each level of subdivision applied. That would also mean an SSS precompute for each new 'mesh'...)*
*Just thinking of possible methods of making the translation to something 3Delight understands...and none of them are coming up with a 'quick' way of doing it.
That is a very curious idea, however there is a simple test to do (I already did it many, many times) to see if the 'Precompute delay' after all the maps are optimized, actually has anything to do with mesh density conversion (would that honestly take over half an hour for the "Face Plant Time"?). Drop the daz default shader on the figure with just diffuse, specular/glossiness, and a tad bit of ambient to replace SSS. If mesh conversion is causing it, then Face plant goddess should still take bloody ages without any SSS.
Now I confess, after three minutes of sitting here twiddling my thumbs, I cancel the spot render and drop on the Daz default shader so I can get something done today (some times I don't wait past 60 seconds), lol. Half an hour reduced to under three seconds is a tad much to blame it all on just mesh conversion. And if it was just mesh density, I think that 32 sides and 32 segment cylinder at subD of seven would take days to get out of Face Plant Time. At a SubD of 2, G3F is only 68,000 vertices vs that cylinder with 274,434 at subD of 4 (What is 1,058 vertices or 1,088 faces at a subD of 7?). There should be a 'Drastic' difference on all my test so far between subD1 and subD4.
Now, I may still have the wrong mesh type on this Studio primitive, and you may be correct. I still have a few more tests to doo before I attempt to rig up this 'overgrown soup can'.
BTW, Velvet may possibly add a second to Omni's Face Plant Time (possibly), and absolutely nothing to AoA. Total render time is also rather insignificant. That may possibly change with a map (I'm thinking simple checkerboard or "something simple" like that). Bump is also a possibility, I have experienced bump drag down with reflection, and it may possibly do the same to SSS "Face Plant Time", possibly.
It's rather trivial to subdivide a mesh with no deltas (no morphs)...just divide and write new coordinates. With morphs...you need to divide then decide how much each new poly moves, in realtion to the not divided change. With HD morphs, they operate on the subdivided 'cage', so in order to tesselate them into a polygon mesh there is going to be quite a bit of calculating where each new poly has to be.
And that's the part that can't be tested with simple geometry...no matter how many times it is subdivided.
OpenSubDiv has 4 ways of doing the dividing...single threaded, multi-thread, a GPU mode that just does the caculations and a full GPU mode. I'm guessing that neither of the GPU modes are used...so that means (I hope) it's using multi-thread. And if it's doing the HD conversion from subdivided OpenSubDiv to tesselated polygon mesh AND trying to do SSS precompute at the same time...(both would be very CPU intensive tasks).
So there are really 3 questions (maybe more)...
1. How exactly does Studio translate the OpenSubDiv mesh data into something that non-OpenSubDiv 3Delight can understand and use?
2. How is OpenSubDiv set up in Studio...what compute option is it using (single, multi, 'low level' GPU or full GPU)?
3. When does it start calculating the SSS precompute phase?
Simple geometry isn't going to help.
Logically, that dose add up. It's just the time factor that doesn't add up. Going from 2m 40s on generic objects to around five minutes is one thing. Yet some figures are literally impossible to work with, I just can't use them. Now if it is just the SSS consuming seven cores and that HD-mesh thing in single thread, or it really is all multi threaded, I don't know. Between the glowing meter outside and the thermal controlled fans in the computer, I'm sure it is using all eight cores with the pedal threw the metal at 4GHz, lol. I can only guess just how many processors the developers have in there micro-super-computers to be able make this stuff, it is so gridlock slow on a PC, lol.
ZDG - World of High-end game-'n'.
(Inspired by ZZ Top, World Of Swirl)
yea. Yea!
I got new graphics card, had a Game in mind.
It's look-'n' for a kill-a-watt, and the PSU died.
It's getting a little crazy, as the case is turn-'n' red.
Got to find a cooler for the inside outside.
Smoke-'n', from the melting fans.
Screaming, from the Power-supply.
In the world of High-end game-'n'.
Everything is smoldering, ten feet from the case.
Isn't it amazing, how it glows without any lights.
It's so unpredictable, when the breaker will explode.
Got-a escape the flames, coming out the side window.
Smoke-'n', from the melting fans.
Screaming, from the Power-supply.
In the world of High-end game-'n'.
(The extinguisher is empty again!)
Ramming in more cards, you gotta keep on gaming.
Heaping on that Halon, just to keep it running.
Beyond thermal, exceeding plasma.
Ready for fusion, if it had the pressure.
Tumbling, between Crossfire and SLI.
conflagration, inside the computer.
In the world of High-end game-'n'.
Morning. tad bit of Geek talk. I have a M5A97 (Not rev2 or other), with a CPU max of 140 watts on it's V-reg. So if I was willing to null and void the remaining DRM junk by upgrading the CPU, I can't. I'm up against the wall, I can not go any further. 4.0GHz is the end of the line, and planing heads and boring out the big-block V8 CPU is not an option either (it would exceed the watt limits), lol.
Now assuming I did go nuts with 3-phase power and had infinite funds, what would that FX-9590 get me... a measly seven hundred MHz (0.7GHz). Is that even worth it when I need five times the cores running at five times the clock, no, not even close. A few hundred more megahertz is not orders of magnitude more compute power.
In order to be able to set up scenes with G2F/G3F HD figures, I need something like that. Unfortunately Windows7 and Daz Studio will not run on a CRAY supercomputer.
Now MJC1016 is on to something, and without the ability to see what figures have more HD then others, it will remain an unknown quantity. There are other things I can look at to see just what else is wasting those cpu cycles. Not to say, testing some of this stuff also lets me know what is best for simple trinkets, lol.
So, I'm going to wake up to some coffee and look at things like opacity and gloss, as it is important for many things.
(sips coffee and looks at screen) Translucency? And Opacity up there
, two forms of opacity, that is curious.
Not to be confused with Index of refraction, a different form of opacity entirely.
The 'Trans' in AoA appears to only be part of some obscure switch of sorts, and the Opacity looks rather simplistic at that (probably intended to keep the CPU requirements limited to an extent).
(EDIT) One last note before I dive into Opacity stuff. Pree vs Post SSS.
I threw the dial back and forth, and got no difference in FPT or render times at all.
Random half thought, tho I need to set up Gloss to get a more accurate base before knowing for sure.
So, the absolute longest FPT (Face Plant Time) I measured so far, is two minutes and forty one seconds (Without Gloss), or 161 seconds. Some of these HD figures have a FPT in excess of half an hour (1,800 seconds). 161 / 1,800 is about 11.1 times. Is the SSS being recalculated over eleven times on HD figures. As much as I have some doubts about that, it would explain the complete (trying to think of a nice way to say this) of the entire HD figure subsystem to render in a reasonable time on a PC.
Why I have doubts. G3F at a base of subD2 is not that bad (about on par with the Studio Primitive tests), and eleven subD levels beyond that exceeds what the dials will allow, 7 max on the dial. Even if it is only eight times longer with Gloss in the mix, that is still subD of ten for the HD figure.
Also, with shadows and reflections of the HD figure in a scene, the shape of the mesh must be established before the light rays begin calculating. Clearly the 'Progressive' mode is not wiping the render field area clean eleven times for the other stuff in the scene. Instead it starts to show Atari pixels then stops when it gets to the HD figure, and sits on it's face until the SSS Precompute has finished getting "it's GUI out of it's back-end". So the mesh shape probably is calculated before that "Rendering..." progress bar begins at 0% for the final render step.
Also, clothing mesh smoothing needs to know where the mesh is, dose it not. Forget about G3F, we know that is broken a few ways. G2F works flawlessly with all kinds of G2F outfits, even the HD figures as well. If the mesh shape of the figure is not established when setting up stuff in the View field, then even G2F HD figures would have massive poke threw, and that is not happening at all. That appears to indicate that the HD mesh shape is at least partially figured out well before starting a render.
That is why I thought the SSS calculation delay had something more directly to do with the mesh density then any particular HD thing (like an illumination level per polygon face, or something like that). However It appears to be a tad more complicated. Another angle I may look at, is with base mesh of different densities vs SSS without SubD or smoothing (like a cylinder with 32 sides vs another cylinder with 64 sides, etc). Throwing the SubD dial was a simpler way to try it, tho it only differs between Base and anything High Resolution 0 and above.
That's what I suspect as well.
But there looks to be a translator hidden somewhere inside the mechanics: because HD morphs export to RIB and render perfectly.
Try this:
- load any Genesis figure and inject an HD morph into it. Something distinctly visible, like hand tendons from Zev0's aging pack addon.
- change subdivision to "Legacy" and render. Result: the morph is barely there.
- change back to Catmark and render. Result: the morph is perfect.
- export to RIB. According to the RIB, it's Catmull-Clark = "legacy". But if you render, the result will be a perfect morph.
If only we had a version of the standalone identical to the one built into DS, we could compare the time the renders take...
Translucency is like paper glowing when you hold it against the light, you can't really see stuff through it. It's sort of a cheat (very cheap SSS approx, but it's plausible for thin stuff like paper, leaves, hair etc.
This cheat is in Iray, too; this is the MDL spec: http://www.mdlhandbook.com/chapters/chapter3.html#3_4_diffuse_transmission
Transparency is an alpha mask. Using a map in this channel will generally decrease render times in DS because DS sets everything up so that with a map there, light shaders will use the "shader" hitmode: i.e. they will run the surface shader when its surface is hit by a shadow/diffuse ray, so as to determine where the map "is" and where it is "not" (and the gradients). Without a map, they will just ask the surface for its general Os value. The render will only get slower in this case because there may be objects now seen through the surface and not culled, and if they are expensive to shade... you get the drift.
IOR will kick off refraction, which is like this in MDL: http://www.mdlhandbook.com/chapters/chapter3.html#3_6_2_specular_transmission
// I really love that handbook, it explains a lot of renderer-agnostic concepts because MDL is like that //
In 3Delight DS shaders, refraction is paired with "opacity", but it doesn't have to be. A surface can be considered fully opaque (Os = 1 so the shadows are solid) and yet it can calculate refraction. This is the right way to get caustics (with photon mapping, of course; default DS shaders don't support caustics as you have figured already).
And there shouldn't be any. It's just a question of __when__ the colour map is multiplied: either before the SSS pre-pass (and it gets blurred by the SSS) or after the SSS is done (then everything is darker and the lines are crisp).
Sorry for the delay Kettu, I was absorbing some of that, and trying to find the stuff that went over my head, lol. OK, so Opacity is kind of like colored glass, and Translucency is more like tissue paper held up to a light. That's kind of cool.
That bit about the render times of surfaces behind an opacity object was foremost on my mind. I did a quick comparison between a reflective floor vs one with reflectivity off. I decided to go with no reflection on the floor to capture more of the effect of opacity on render time rather then the environment not blocked by the cylinder. I'm still getting a bit of increasing render time with decreasing opacity, and I'm not sure if that is from the environment behind the cylinder or not, yet. I did run a few more test runs to be sure it was not something Windows was doing, and they do appear to be consistent with the original measurements.
Perception and assumption vs actual measurements. I was under the impression that a 50% strength cheat may be possible in the shader to make it run faster, and thus had the 'Impression' that an opacity of 50% was faster then other values (Except on and off). The measurements on the other hand show that to be purely unfounded perception akin to waiting for the water to boil, lol. I made a statement some time in the past, speculating that Reflection strength may be faster at specific strength values (100%, 0%, then 50%, then 25% and 75%), After seeing this, I'm now doubting my impression of that. To night I'm going to run threw Omni and (if there is time) AoA, and then I'll do a similar test on Reflectivity. Again, maps may or may not have different render times.
(EDIT, Transparency errr Translucency. crummy spellcheck/typo, oops. lol.)
(EDIT2, typo on the list, It's Opacity, not Reflection. oops. Here is the Omni as well)
Opacity/Transparency is like colored glass, Translucency is like tissue paper.
I'm not sure there is a way at all to write a cheat like that! =D Strengths are just multipliers, the shading either happens or not.
On the other hand, in shaders that use multiple importance sampling (MIS) 3Delight can theoretically use fewer samples when the strength is low (if the shader is written that way), BUT there is no MIS in shaders that come with DS (they are too old).
lol. yea, I was thinking more inline with binary math tricks then just purely at the light ray shader level. I'm not sure it would work as well with opacity as other things. With things like reflection strength, it's simpler to divide by 2 (binary R-shift trick) rather then multiplying the percent by the colors. Deep down inside a processor, is a math unit ALU/FPU, and inside it there are some operations that are faster then others. Generally speaking fastest to slowest is Bitwise (And Or Nand Nor L-shift R-shift etc), then Add/subtract, then the slowest being multiplication/division. Different processors may also have more complicated calculator operations that may be much slower (like root, or other trig functions).
http://en.wikipedia.org/wiki/Division_by_two
I was rather naive to think that such tricks to speed up a program would be used in this day and age, lol.
There definitely are a lot of clever optimisations in the closed-source code, but nothing that evident =)
I'm beginning to suspect that AoA suffers from less optimization then the other two shaders. While some render time (as indicated in the log) may possibly be due to a lack of compiling the script/whatever into something a tad more efficient, I have difficulty explaining how real time conversion of the shader stuff can account for such drastic differences in render times. Every time a render is finished, and when a setting is changed, the AoA apparently is being recompiled (I find it odd the Daz default and Omni do not get such entries in the log).
After a few days of running test renders, I have accumulated barely enough samples to make a very small chart of the three shaders. Top to bottom is 100% opacity down to and including 0% opacity strength at the bottom. Each pixel is ten seconds starting at zero seconds at the far left pixel, and the black vertical line on the right is the 30 minute mark.
Immediately, or rather after a few days of tests, I noticed that the Daz Default and the Omni shader appears to mostly disengage when the opacity is at 0%, and the AoA for whatever reason is not (*1). Also there is a slight increase in render time as the opacity is decreased. I will attribute that to the shadows and illumination of the test chamber behind the test cylinder, and the times of the Daz Default and the Omni appear to both follow the trend with minimal impact between them. Again however, the AoA shader has a far more drastic increase in render times then the other two, indicating that something in the shader is amplifying the time to render compared to the other two.
While the results are indeed fascinating, it is only one set of tests and may not fully represent the full range of performances vs surface properties available in the shader. I have much more testing to do before a more complete picture of performance can be made.
*1, as for the Opacity Strength setting in the surface tab, Not the eyeball thing in the Scene tab that makes the object go away. The Eyeball thing dose indeed turn off the shader, the Opacity strength however only effects the visibility of surface and dose not disengage the shader calculating stuff at 0% opacity strength on the AoA shader. And yes, this was all on the same cylinder, on all three zones, with only diffuse and opacity active on all three shaders.
Wow, you even have charts made. Awesome!
This is actually to be expected because AoA Subsurface is not a "real shader" - it wasn't written in a text editor in the shading language like the default one or the UberSurface; AoA's one only exists as the spaghetti in the shader mixer window... and DS has to turn it into something code-like each and every time.
What's disconcerting is the opacity issue with AoA. Either something's wrong with the spaghetti, or...
lol. I would not call it an issue as much as a lack of taking advantage of a potential optimization. So far, the only conclusion I have, is puerilely for a diffuse surface with only opacity and nothing else, lol. Clearly, the AoA is a complete waste of resources for such a simple thing, yet what actually has such a surface, almost nothing, lol.
Looking at the numbers, I thought it was probably a quarter or third slower then the other two. However after counting pixels in MS Paint and plotting the times, AoA is almost twice as slow as the other two. Here is the same chart, doubled in size.
Another interesting phenomenon, can be seen between the very top line (100% opacity) where only one side of the cylinder is rendered, and elsewhere where both surfaces are calculated. 100% to 95% has a jump almost double on the AoA (8 minutes to 16 minutes), and not quite as bad for the Omni and Daz Default. Indicating that the AoA is doing everything twice, and the other shaders are calculating some stuff only once. Down at 0% opacity, it is clear that the Daz default and the Omni shaders are quite optimized, while the AoA appears to be calculating everything around three times for some odd reason.
wow.
All my other opinions about what is faster in each shader, is purely based on perception of waiting for the water to boil, lol. Thus I have much more test runs to do with other stuff. And yes, I was essentially unplugged the past few days so Studio had all of the computer to run the tests (I'm not ignoring the other 3Delight Laboratory thread, I just didn't have a browser open the past few days).
(EDIT) I figured it would be good just to triple check the 0% and 100% opacity tests. And sure enough it is taking about three and a quarter times longer to render it completely transparent (0% opacity), then to be completely opaque (100% opacity).
And as you can see, it is not there in the render. There is no gloss ghosting at all, no phantom reflections, and absolutely no SSS or velvet remnants at all in the render. And it still took 26 minutes 29.49 seconds to render the third time.
Compared to 8 minutes 33.54 seconds for the third 100% opacity run. And in contrast to the test renders I did a few days ago with no cylinder in the test scene to test the reflective floor ( 8 minutes 49.1 seconds) to no reflection at all on the floor (4 minutes 7.86 seconds). I've been doing all these opacity tests from the same camera with no reflection on the floor. Well, it takes about six and a half times longer to render the AoA as completely transparent, then the same test with no cylinder in the scene.
(EDIT 2)
Apparently, the "Spec/Reflect Trans Off - On" dial is doing nothing for the render times at all. I just got the same times with the dial in the on and off position, indicating that that stuff is still being calculated even if it is disconnected from the spaghetti mess. That is surprising, and I'm not sure just how far the ramifications are from this spontaneous test.
It looks like that On/Off switch dose nothing at all.
How much of that excessive render time is the AoA shader calculating stuff that is not used, that's a good question I don't know how to answer, lol. At the very least, that switch dose nothing at all.
In separate news, I can assure you, that all of the on/off buttons in the Omni shader do work.
I've been sitting here trying to set up some reflection test settings, and I ran in to another snag.
Well, there is a hint of reflection there, so I will just go with that for the tests. Daz Default and Omni have no issues at all with a basic mirror setting of black diffuse and 100% reflection strength. Apparently, the AoA shader included in Studio, is not made to be a mirror, and all the search results I found were either for the product that must be purchased separately, or there not answered. It is rather odd, as I think there are quite a few figures that have AoA on the eyes, and you need reflections of some kind on the eyes (They may all be maps instead of Ray Trace).
(EDIT)
OMG, you can not have a 100% reflective surface, that is impossible...
At about 9:21, that aluminum coating is probably around 97% reflective. There are other telescope mirror types that use multiple layers at 1/4 wavelength thicknesses that are much more reflective.
http://www.photonics.com/EDU/Handbook.aspx?AID=25501
I will say tho, the VLT mirrors are very nice units.
AoA Shader doesn't play well with reflection.