No no, you're thinking of this from the ubergeek persepctive.  Think of it from a user perspective.  This is why people buy MS Word instead of writing all their text documents from command line console input.  The current workflow (correct me if I'm wrong):
Step 1:  Run the matmatic script against your scene file, which applies these shaders to specific material zones with parameters set by the script.
Step 2:  Run Poser, open scene file.
Step 3:  Go to materials room and manually tweak values for specific shader nodes on separate material zones, and be careful not to screw anything up or mis-match color values.  From what I can grasp, cut/paste will not be a good idea for this step (outer ring -> middle ring -> inner ring).  I'm expecting that either this shader layout will be applied to Sclera + Iris + Pupil, or the Pupil zone will be transparent (correction: black) and the edge of the Iris will properly blend with the edge of the Sclera (I'm curious to know which).
Step 4:  Cross fingers and render.

You are comfortable with Step 2.  I'm fairly comfortable with Step 2 as well, even if I don't understand the math.  Most Poser users (if you're looking at making this a marketable product) are not, and won't be bothered to learn.  So, consider adding a poserPython menu front-end to change the shader values, a la OcclusionMaster.

Step 1:  Run the matmatic script against your scene file (frankly this could be streamlined as well, I think, but that's a different item).
Step 2:  Run Poser, load scene file
Step 3:  Start poserPython menu script, or alternatively Wacro (as Face_Off has done it)
Step 4:  Graphically fiddle sliders without even entering the Materials room; slider values are translated to numeric values, possibly split across different shader nodes fo Sclera/Iris/Pupil.  Also have an option for direct numeric input.
Step 5:  Render with high confidence because the menu has strong data validation.  Possibly even a small poserPython subscript to create a camera and "preview" render just the eye/iris with some high-speed render options.

Sure, all of these things can be done manually.  Why does Face_Off bother to sell OccusionMaster and other products?  Ease of use.  I'm not talking about bundling up all of Matmatic, really just about this eye shader business.  I seriously think this particular use of Bill's shader work has a lot of marketability, just with some comfort features added.

edit: heck, alternatively make it completely independent of matmatic.  many people with no interest in matmatic would likely be interested in this application.

Quote - Shader effects show up in the preview. You change something, it refreshes (optionally automatic) and you see the difference.

The problem is, mostly, they do not.

Quote - my preference would be for changes to the shader tree to have an effect on the actual actor affected in the viewport under full shaded display with software or hardware assist.

Shader effects show up in the preview. You change something, it refreshes (optionally automatic) and you see the difference

::::: Opera :::::

You already have this when using Bagginsbill's "Parmatic".
Matmatic creates the shader, Parmatic adds dials for some or all values of the shader.
You twist the dial or enter a new value, Parmatic picks up on it and changes the shader
intantly. 
If it's something that's visible in preview mode, you'll notice the change right away.

Martin

Okay, what msg24_7 said...

Most are running from within Poser, so...
Step 1: Run matmatic to generate materials from the scripts in the designated location
Step 2: Go into the material room and apply new materials to the specific item (also good time to generate thumbnail for the newly created material).
Step 3: If the script was Parmaticly enhanced, some parameters of the material will be able to be adjusted with newly created dials on Poser's parameter widget.

AFAIK, neither Matmatic or Parmatic apply materials to anything. Of course, this varies if you've generated pose files instead of material files. Still, you have to apply them.

I'm really busy with real life this weekend and can't post another long response, so I'll be quick.

My pupil msg24_7 has given you the answer. The program Parmatic gives you Poser dials on props and figures. These dials change the parameters of shaders on that prop or figure. You can have a single dial that changes ALL the mat zones of a figure. For example, you want to darken all 10 mat zones of skin? One dial. And you don't go into the mat room.

Parmatic works for any shader no matter how produced. It does not have to be a matmatic shader, although matmatic is probably the fastest, easiest way to  make a parameter dialable shader. Go download Parmatic and read the script - the comments tell you how to make any shader respond to dials.

There is still merit in a GUI, especially one that can do better preview. Ever use photoshop "variations" tool? What I would like to build is some way to visualize a shader in a large (600+) preview, surrounded by little previews. You select a parameter, say a number. The little previews show that number increased and decreased by various amounts. You pick one, and that becomes the big preview. Then you pick a color - the little previews show changing the color in various amounts. Click the one that's heading in the right direction. And so on.

This has to be instant. I agree that picking colors and brightness that balance is hard - even I get it wrong about a 100 times a day. I need this tool too so I can explore a shader.

The thing is, I don't have the algorithms for all the nodes (EF keeps them secret) so I could never mimic them perfectly in a standalone program. Doing it in Poser would be too slow - my cloth shader takes 5 seconds to refresh in the mat room preview.

What I'm thinking of doing is keeping a pre-rendered image of every node offline. The matmatic GUI-based adjustment tool generates your shader and sets up the previews as I described, but using all these pre-built images it would be INSTANT update. It might not exactly be the same pattern as the real shader, but it will be really close - close enough that you'll get the colors right.

I've already built something similar for lights, never released it. Say you're doing an indoor scene and you really must have 6 spot lights pointing down from the ceiling, plus an IBL, an infinite for sunlight through the window. You have 8 lights to balance, and there is specular and diffuse to think about too, so there are 15 values to adjust. If the render takes a minute, you could be looking at 1 to 2 hours of tweaking.

Instead I render each light by itself using the Render Passes script - that takes about 10 minutes. I now have 8 renders, plus an AO shadow render. I load them into my light-balancing tool, along with the 15 parameters I started with. Then I use sliders to adjust the strength of each light component or shadow strength in the tool - with instant update. Usually it takes about 3 minutes to find the perfect settings. Then I read off the new specular and diffuse and shadow strength values to put on my lights and do the final render. It's very handy but not slick enough to distribute yet.

You have a real life? ;)  Me too it seems - putting a culvert at the end of my driveway before having it paved (yes, it's currently a long dirt drive).  This is mainly to facilitate the passage of my new 40' rv bus which didn't fair too well on first entry.  Thus not much getting done on my programming either. :)

This is all very fascinating.  The shader interface, while being very powerful and flexible, is very daunting and confusing.  bagginsbill and face_off have gone a long way towards removing the latter part of this.  If you can't do everything in the Poser preview, it might be good to do what other software does and use a proxy primitive (sphere, cube, ...) on which to build a preview - think Vue et al here.

I'm not being more than a cheerleader here - as my mind is more on that 'real life' work to be done (in order to place the 28' culvert, first a 4x30' slab of concrete has to be removed - about three tons or so) while continuing to churn the current programming endeavors in my mind as well (solving Poser's JP bulge algorithm - if anyone has any insights?).  I will be peeping in once in a while to see how this is developing.

Let me give you all my "meta" idea why I am interested in shaders affecting the preview mode as impactfully as possible, as real as possible.

Animation.

Think about it. If your goal is to produce semi-realistic animation (not hyper-real animation, but not "toon" either)........

You can make your final raw frames by rendering not with Firefly, but with Preview. Get some good color, some good skin shading, some semi-realism in preview mode, 'make movie' with anti-alias set on, and your render time for a 720x480 frame is 2-4 seconds.

You then open the folder of frames (your image sequence) in After Effects or Photoshop and apply filters.

I am just beginning to fool around with this idea. Here is my test animation.

http://jrdonohue.com/anna1.mov

There is a velvet shader on the dress and of course skin shaders on the skin. Please forgive "film grain overload" in this animation; it is only a test, and once I proved out the idea I did not attempt any refinement of the Photoshop filter(s).

1. Biggest challenges: getting dynamic hair to render in anything but black.
2. no shadows.

This animation was rendered in preview mode, render time 3 seconds per frame, Photoshop filter applied to all frames under "automation."

NOTE: while you might think  the great benefit is 'hardware assisted render of preview mode under OpenGL", I actually had my preview set to SreeD. Why? Well, it's the hair. First of all, dynamic hair under this plan must be clicked "show populated". Well, under OpenGL the hair does not look as good in preview; it looks much better and fuller under SreeD. More experimentation to come. One interesting avenue: kicking up the hair population from, say, 15,000 to 40,000. It affects render time a little because of the resources necessary to render the preview of each frame; but not much. Overloaded hair like that does not increase hair sim time, since you calculate the sim with "show populated' off, then turn it on before render.

::::: Opera :::::

so... if a GUI was attached to Matmatic, you'd be looking say, a Poser version of Darktree?

Quote - so... if a GUI was attached to Matmatic, you'd be looking say, a Poser version of Darktree?

Now that's something I can relate to, and would love to see.

Darktree? No I don't think so. I've not used that prog but it looks like the Poser material room - assembling nodes into a tree. That's not cool - too slow. After you put about 120 nodes in, you're totally lost. And you can't give even a 50 node shader to someone else who didn't watch it being made - they don't have a clue.

No what I'm saying is I use matmatic to build a monster shader with 500 nodes in it. Then I give you a GUI to modify the 25 key parameters. I already have that, using Parmatic. You never look at the script or the shader. But you don't get a real-time preview unless you go into the material room, and then that's really slow.

I'm talking about giving you the 25 dials, a nice BIG preview, and one that updates instantly. As well, it would have parametrically nearby neighbors previews as well, so you can ignore the parameters and just point at which one you like best. Then it makes more variations and you point at the one you like best. You keep repeating that until you get something you like a lot. And you have no need to know how the parameters got there.

I can't imagine anything being easier.

Master card: 5352 2234 9999 9999 expires 12/12/2020

Ok I'll get to work on that.

LOL @ operaguy - hey charge mine too!

It almost sounds like the old fractal designer in Kai 3

Quote -

No what I'm saying is I use matmatic to build a monster shader with 500 nodes in it. Then I give you a GUI to modify the 25 key parameters. I already have that, using Parmatic. You never look at the script or the shader. But you don't get a real-time preview unless you go into the material room, and then that's really slow.

I'm talking about giving you the 25 dials, a nice BIG preview, and one that updates instantly. As well, it would have parametrically nearby neighbors previews as well, so you can ignore the parameters and just point at which one you like best. Then it makes more variations and you point at the one you like best. You keep repeating that until you get something you like a lot. And you have no need to know how the parameters got there.

I can't imagine anything being easier.

  How Darktree works : once you've complied your tree,(yes that is like the mat room just a lot lot faster),  you save it out and the user just sees the results with modifaction dials in Symbiont (the program interface part of Darktree).. so we can say Matmatic = Darktree and Parmatic = Symbiont...

bagginsbill, Let me know if you could use my color chart. I will sent it to you. ^^ bB

BB it may be desirable to just have a subscript actually create a camera and run a render with some specific options.  Since (one would hope) this would be something you'd do at scene creation time, or at character development time, and then it will be largely left alone for that scene or that character - e.g. I don't go tweak sclera/iris settings much at all once I've gotten to a stopping point with a character.  An instant-update preview would be ideal, but not exactly a make or break feature.  If it turns out not to be practical, or if preview quality isn't acceptable to you, doing a scripted render may be a good Plan B, if poser 6 (at least) can invoke the render engine from poserPython.