I didn't like what I saw and figured I'd show you how to do it.

If you have Poser Pro 2012 or 2014, or Poser 10, you can get the same results as me, and that's better by far than I saw in the tutorial.

Here is the shader. Key points:

The reflection is blurred. Unless you glaze the stone, it won't make sharp reflections, so you need the softness to be non-zero.

If you're using lights you also need to deal with the specular reflections from lights. I prefer Blinn because I understand it and it always does what I want. Can't say that about any of the others.

My Blinn eccentricity and Reflectivity here matches well with the Reflect softness. If you change one you have to change the other. The relationship is a little complicated so I won't write it out. Rule of thumb though: As blur (softness) increases, eccentricity should increase and reflectivity should decrease.

I combine the two forms of specular (Blinn and Reflect) by adding them. This is for 100% reflection, which is never the case, so it needs to be modulated by Fresnel_Blend.

Fresnel_Blend assumes 100% when viewed on edge. But that's only for perfectly smooth surfaces. For a blurred surface that's too much. However, Fresnel_Blend doesn't have a "strength" parameter, so I plug it into a regular Blender, and adjust the strength there. In this case, I did .8.

I made some slight variation in whiteness using the Clouds node. This is optional or can be replaced with other choices. Have fun experminenting with colors and patterns.

The "Scale" on the Scatter can be adjusted to make the stone more or less translucent. Think of it like putting the "breaks" on the light. Do you want it to stop quickly - use higher scale. You want the light to linger and bounce longer - use lower scale. I used .5 here making it more translucent than the default. Try different values.

Use Gamma correction in render settings. If you don't, you'll think the marble is too dark and you might start messing with lights or (shudder) mess with the shader values. That would be a mistake.

This was rendered with a single point light, inverse square falloff, white, intensity 15%.

The light is mounted in an upside-down bowl on the ceiling, about 83 inches from the floor.

The specular reflection of the combined point light + lamp bowl is created by the Blinn + Reflect - you can clearly see it in the bowl. (You can also see similar effects all over Andy, who is sporting a fun metal shader that I generated randomly from a Python script that creates thousands of materials, renders them, and then I pick ones I like. That's a topic for another day.)

The marble subject bowl in the image is from Poser Primitives folder called "Bowl". I turned on subdivision one level.

The surroundings include three walls, the ceiling, and the floor (Poser ground). The ceiling is white. You can see the walls and floor.

IDL is on. GC is on. These things matter. The video image was much worse than it needed to be.

I need more time for spell check editing. Sigh.

I meant putting the brakes on the light, not the breaks. Dang it.

Great demo, BB! I'd like to have the wall materials too. I HAD a good interior wall material but lost it when my last laptop died.

Nice tutorial and I sincerely hope that gorgeous brushed metal is part of your pack for EZMat. O_O

Wonderful tutorial.  A gold star for creating such a marvelous shader.  I can foresee plenty of use for this.

Cool ,Thanks a lot :biggrin:

Thank you BB. Since so long I was looking for such a great marble shader.

Thanks for taking the time to include all the set-up info too, good to see how to use the scatter node with marble.

Lovely! Thanks very much BB :-)

Looks perfect as expected, thank you!

Quite a nice shader, and quite a good render too, thanks.

However, when I google on Marble images, I see strong brightness contrasts in splotchy marbles, or very contrasting veins, while the one presented appears quite soft and cloudy to me. Also, the smoothness as presented is great for bowls but marble walls will be rougher I guess, while floortiles might be a compromise between those.

What adjustments do you suggest to get those nuances in?

Sadly, I have to get to work so I'll leave you this teaser.

I'll explain how to do it later.

kewl marble.  Thanks.

i spent my whole Monday watching the smith-micro video tutorials.

there's a big void in the lighting section.

BB, that's a bloody nice one! Compliments.

See, this shader is a prime example of why I can't get my bloody head around nodes in Poser!

At the far end there's a Reflect node, but ultimately it ends up feeding a Diffuse channel, and I just cannot get my head around that for some reason.  It's not like I'm stupid either (well not overly so).  I just can't grasp what's happening along that chain because what is feeding it is a reflection node.

I used to balance relfection with diffusion in Bryce, so I think I get the connection there, but I don't get what it is that is being supplied by the reflect node.  Like if you could see what is inside those wires between the nodes, what on earth is the reflect node sending that is of any use to the other nodes, that's what I don't get.

I wish you'd hurry-up with that missing manual, aRtBee, cause this stuff is driving me nuts.  Maybe it's because I'm too set in my ways from other software, I just can't grasp it!

yeah, I'm hurrying up. It just took a lot of time (and ditto complete rewrites, and asperines) to get it all sorted out in math and testrenders when transparency, gamma correction, reflection / refraction and (Fresnel)blends meet each other in one PoserSurface definition. Got it wrong so many times, in so many ways. Got it right now, one rewrite to go, then making pdf's and webpages. Coming soon...

Alternate_Diffuse doesn't mean Diffuse is here. It actually is "draw whatever you plug into this". They called it Alternate_Diffuse to help noobs. You're supposed to think you should put your alternatives to ordinary (built-in) diffuse into that channel, such as Clay, Scatter, etc. However, since it actually is the only channel that literally does what I tell it to do (by what I plug in) with no other hanky panky, it is where I put everything.

http://forum.runtimedna.com/showthread.php?44077-What-exactly-do-Diffuse-Specular-nodes-do

Quote - Anyway, as for the various inputs...
Unless you have transparency involved, the internals of the Poser Surface node are very simple. Each section does a little multiplying (X_color * X_value) and then everything is added together, period.
So if you turn off Diffuse_Value and Specular_Value and you plug X into Alternate_Diffuse and Y into Alternate_Specular, the result is simply X + Y.
If you plug R into Reflection_Color with Reflection_Value = 1, and you plug Z into Ambient_Color with Ambient_Value = 1, you would then have X + Y + R + Z.
If you use the built-in Diffuse and Specular, those just do their job and then get added. So if we called the built-in Diffuse D=Diffuse(Diffuse_color, Diffuse_Value) and the built-in Specular S=Specular(Specular_Color, Specular_Value, Highlight_Size) you'd get:
D + S + X + Y + R + Z
It's really that simple.
There is some wierdness with the switches Reflect_Lite_Mult and Reflect_Kd_Mult. These enable a couple additional multiplications, which are nearly pointless and have no basis in reality. But if your shader has those enabled, and you're using stuff on the Reflection_Color channel, you'd have to take those into account as well. The Reflect_Lite_Mult will multiply the Reflection_Color with the incoming light level. (Stupid - don't do it.) And the Reflection_Kd_Mult will multiply the Reflection_Color with the output of the internal Diffuse node (also stupid - don't do it.)
As mentioned, transparency includes some more wierdness with regard to the internal math of the Poser Surface node. In particular, Specular data is altered a bit. I don't want to bother explaining how unless you need it, as it is very complicated.

Since then some more weirdness has been added. Normals forward will affect things in unexpected ways depending on which of the inputs you plug into. Alternate_Diffuse is the least weird.

http://forum.runtimedna.com/showthread.php?26024-Diffuse-Clay-Skin-and-Velvet-nodes

Quote - CQ I think I'm going to continue what you've started here. A word of caution however, I wonder how you plugged these in? Do you know that plugging into the Diffuse_Color means that it is going through a Diffuse node as well? And that plugging into Alternate_Diffuse does not pass through another node? When you got the blowout on the Alternate_Diffuse, I suspect you had the regular built-in Diffuse_Color/Value still turned on?
The general idea is if you want standard Diffuse and Specular nodes - you don't need to add any nodes at all. Those two are built into the Poser Surface.
But if you want to use alternative approaches to either diffuse or specular, e.g. Clay for diffuse or Blinn for specular, you should turn the corresponding built-in component off completely. Then plug your node into Alternate_Diffuse or Alternate_Specular. Those two inputs assume whatever is plugged in has already done its processing and no post-processing should take place.

http://kobaltkween.deviantart.com/journal/Poser-Material-Basics-418487917

I like it

thx fr marble shader, bill.  works for jade as well!

**
@aRtBee**
I can imagine the work you'd have to put into that, and believe me, there really needs to be stuff like that and I really look forward to seeing it.  I've had a quick look at some of your other stuff and I hope you follow the same principle with the materials.

The problem with trying to learn this stuff is that a lot of it assumes you know how the nodes actually work, the basis of how they tick (what sort of data is travelling between the nodes and what sort of data is being sent out by specific nodes).  Without that, it's like expecting someone to understand how a combustion engine works if they don't understand that the fuel is flammable and vital to making it work.

@Bill
Thanks for that, seriously, I'm going to read that lot over until it sinks in once and for all.

I'm an embarrassment to myself with this Poser node stuff, because it should be a piece of cake to me.  I use node-based synthesizer development products all the time and have no problem with them whatsoever (I'm a wiz with them).  I might need to get the calculator out now and then, but other than that, I know how it all ticks.

What you just told me is how the nodes work together.  That would be the same as, for example, me teaching someone how an LFO can oscillate Amplitude in a synthesizer.  But the difference is, in synthesizer development node-based systems we have wires connecting nodes but those wires have a specific purpose whereas Poser nodes seem to be somehow generic.  For example, the wires are colour-coded to designate whether an Audio or MIDI signal is passing through them, or whether a signal is mono or poly.  We can hover our mouse over the wires and even see what data is being passed through them between the nodes.

That's the part I'm not getting with Poser nodes.  It's not so much the nodes themselves, it's just that I don't understand what sort of data is being transmitted between the nodes.  I understood that first reply up to a point, that it's basically summed-up, but what I don't get is how, as it doesn't matter what node you stick it in, how does the renderer know whether what you plug into a specific node, is for reflection or diffusion or whatever else?

If it's just a balance that is summed-up and it doesn't matter where you stick it, how does the renderer know?  Hopefully, what I'm getting at here is explained at those links otherwise I still won't get it.

Either way, that Marble looks bloody awesome!

All Poser node wires are carrying either just a single number or a bundle of 3 numbers (also called a tuple or a vector or a color or a position or ... depends on your intent of how you plan to use the 3 numbers).

A number inside the shader is always a floating point number, not an integer. It is not restricted to any given range like 0 to 255 or whatever. It can be -808.34873847 or 2 or 1.0000001 or 5.757457495 * 10 to the 30th power. (I honestly don't know the internal size of these numbers - they could be 32bits, 64 bits, or 80 bits, or something else. If we really cared, I bet I could come up with a test that would reveal how many bits are in them.)

A node is asked to produce an output of whatever kind is natural for it over and over again. How many times it is asked to evaluate a number or tuple depends on how many pixels you have in your picture, what the shading rate is, how many reflective or refractive surfaces there are, IDL passes, SSS passes, etc. But when designing a shader, you don't need to care about those things at all.

Whether a node produces a single number or a 3-tuple depends on that nodes job, and does not depend on what you plug into it, nor on why you're using it. Every node is either a scalar (single number) or a 3-tuple. Blender is a tuple. Math is a number. Clouds is a tuple (and usually interpreted as a color, but it could also be converted to a number and interpreted as a displacement to make a rocky terrain.)

The output of one is carried to the input of the next, until all the numbers flow into the root node. The output of the root node is a tuple, and it is used to color a pixel in your render. (If you are subsampling, then several root node results will be combined by weighted averaging to decide the color of a pixel.)

Inputs to nodes usually expect a number or 3-tuple as well and they have a parameter on them you can edit that gets multipled with whatever you plug in. If you plug a number into a number, or a tuple into a tuple, you probably can understand what happens without me telling you.

But if you plug a number into a tuple? Simple - the number is cloned into all three elements. So if you plug the number .5 into Diffuse_Color, that would get cloned and become the "color" tuple .5, .5, .5.

If you plug a color into a number? Simple - the three parts of the tuple are averaged. So if you plug the tuple 1, 1, 0 (yellow) into a number, it becomes (1 + 1 + 0) / 3 = 2/3 or .666666667.

This means that you can freely plug colors into numbers and number into colors. It does not mean that always makes sense. But I can show you so many situations where it does make sense that you'll quickly come to realize how convenient it is that Poser doesn't make us run the data through some stupid converter node like so many other renderers do. It just quietly takes care of the conversion.

If you do not like the conversion from tuple to number, you can write your own wherever you need to. The Component node will pull out any combination of the 3 elements of a tuple and assemble them by weighted sum, or just give you one of the raw numbers which you can then use to do numeric stuff. I use this tactic in skin shaders to pull the red channel value out of the texture and detect hair versus skin.

Numbers and tuples coming out of a node are decided by that node based on its inputs and based on information passed to it from the renderer - the latter are render variables and they change on each iteration of the shader. Much of the information variables passed from the renderer includes stuff we do not have direct access to in the materials - only programmers who make new nodes can reach that info. Some of the information the renderer passes is directly accessible to us as material room shader developers - these are the "variable" nodes such as U_texture_coordinate, V_texture_coordinate, N(ormal), P(oint), etc.

As shader developers, we're only able to perform operations that are offered to us as a node. We can compose and assemble these as we like, but we can't directly reach every feature of the renderer. For example, I can't tell what kind of light is being applied during a render - I can only indirectly sense lights by using lighting nodes such as Scatter, Hair, Diffuse, Clay, Blinn, etc. I am bound by what those nodes do. If I want to do something altogether different that cannot be done by composing existing nodes, I'm stuck.

Many of the nodes have nothing to do with lighting nor with variables. They are simply pattern generators that shader authors find convenient for mimicking natural things. Among these are Clouds, Fractal_Sum, etc.

Other nodes are pure math - they don't have anything to do with generating anything at all or reacting to lights or whatever. They just do simple arithmetic with the inputs and compute an output that, like all nodes, is simply a number or a tuple. How you use them depends on what you're trying to do. For example, if I am making a pattern out of a couple other pattern nodes and I'm blending those, I use a Blender node, and so that node's job is to make a pattern. If I'm combining a Diffuse and a Reflect to create a custom modulated material that has some pixels that are clay and others that are metal, then I also use a Blender, but now its job is a new kind of lighting model, not a pattern generator.

That's enough for now - chew on that for a while.

This freedom is what made it possible to make my light meter.

In the light meter, I use a Diffuse node and the tuple it produces represents the diffuse reflection at that point on the object, based on available incoming light color and direction, the angle of the surface normal, and the angle to the observer (camera). This value is a color that normally gets used to color a pixel or at least adds to the color of a pixel.

But in the light meter, I convert that to a number, and I use that number to decide HOW BIG A DOT TO DRAW!!!!

I also use that to decide to replace the dots with yellow (almost too bright) or red (definitely too bright) - the diffuse node in this shader has little to do with diffusely reflecting light. So just because that's its official job, doesn't mean I have to use it that way.

The freedom of Poser's materials is what keeps me from fully committing to Reality; procedural materials have just become too big a part of my workflow.

I like poser, as it lets us render what we want, as opposed to lux, which dictates what it allows.  eternal struggle of man vs machine.

**
@Baggins**
That's more like it, I understood that a lot better, big-time thanks for that

Right, so the data passing through those wires is either a number or tuple.  The decimal format of a number isn't important and the system is rigged so that conversion isn't necessary due to the built-in averaging of a tuple into a number.  That conversion part is one of the main things that was throwing me.  With synth development nodes we need that conversion because the designs can be built in real hardware, but with 3D rendering, I can see the advantage of not needing conversion now you explained it.

I'm still struggling with one thing though.

So a procedural texture outputs a tuple, I get that, and I even get why it's a tuple and not just a number.  But what happens to the original tuple of that texture node if you output that tuple into a node designed to accept a number, and then that node is connected to the root that aways accepts a tuple?

From what you told me, I see it as starting with a tuple, it then gets averaged into a number when it hits a number-based node, then that number-based node outputs the avaraged number into the root nodes tuple input.

And here's the thing; how on earth can the tuple input on the root node make any sense of the original tuple?  It started out as a tuple, but it's not one by the time it reaches the root node, it's just a number cause it got averaged by a number-based node along it's journey to the root node.  How does the root node get at the tuple data when it's been avaraged into a number by the time it reaches the root node?

Before I chew on that stuff you posted, please explain that one to me in as basic manner as you possibly can, because once I get that part as well, I should be able to absorb the other stuff!

Actually, I think I get it now.  I was assuming the root node would somehow have to represent the texture node at all, but of course the answer to that one is that it doesn't have to do any such thing.

I just have to change the way I'm thinking.

Ah - you beat me to it - I kind of thought you would.

Nevertheless, I have prepared some demonstration to make the point more visual.

First - in words:

The output of a given node is what it is. Conversion doesn't happen there - it happens on the other end of a wire when the value (number or tuple) is consumed by another node. At that point, the value is taken as-is (because it's the right kind) or it is converted on-the-fly for use as input to the node that wants to consume the value.

As I said earlier, the output of any given node is going to be a number or a tuple based on that node's job, regardless of the kinds of inputs you feed it. If you feed a Math node with colors (tuples) it will first convert them to numbers BEFORE it uses them. Thus, no matter what you're thinking of in terms of structure, the math node only sees numbers, manipulates numbers, and generates numbers - period. The Color_Math node only sees colors, manipulates colors, and generates colors - period.

The Poser root node has inputs for lots of things. The Diffuse_Color input deals with color and if you plug in something that is a number, it will be converted to a color. If you plug in something that is a tuple but not actually a color, such as a surface normal vector, it will ignore that little difficulty and pretend the vector is actually a color. It can do that because vectors and colors are structurally identical - a 3-tuple either way. Thinking of the tuple as a color or as a 3-d vector is a matter of interpretation, not a matter of representation.

Meanwhile, the Displacement input expects a number and even if you plug in a color, it will only deal with a number, so it first converts it to a number. It doesn't matter how it started or evolved though a bajillion nodes, by the team it feeds into displacement, it's a number.

The bottom sheet is translucent green and passes very near but slighly below the origin of the world - point 0, -.001 inch, 0.

The top sheet is translucent pink and passes through the point 0, 5 inches, 0. Thus it is 5 inches away from (above) the green sheet.

The white sheet is positioned at 0, 0, 0, but currently I've applied a 3-inch displacement. Thus it is between the green and pink sheets. It's neutral position (without any displacement) would be 1/1000 of an inch above the green sheet.

The middle (currently white) sheet is going to be the subject of some experiments. The purpose of the pink and green sheets is to help us visualize the position of the middle sheet.

The surface color of the middle sheet is receiving 3-tuples from the Clouds node. Since Diffuse_Color expects colors and we're sending colors from the Clouds node, no conversion of the input is happening. The color of the Clouds node is multiplied with the white color chip of the Diffuse_Color input, which actually does nothing to it. Then it is multiplied with the Diffuse_Value. That's a number. The number is first converted to a color 1, 1, 1 - if you're tracking well, at this point you recognize that is the tuple represention of the color white. Then that color (white) is multiplied with the cloud color - again doing nothing at all to it. (1 * x = x, 1 * 1 * x = x, 1 * 1 * 1 * x = x)

Then the internal Diffuse node does its work reacting to my light (which is an infinite) and computes a color which appears in our render. Since the infinite light is at a high angle of incidence, and its color is also 1, 1, 1, the resulting rendered sheet looks a lot like the Clouds node itself.

The color value going to Diffuse_Color is unaffected by this.

But the value sent to the Displacement is converted from a tuple to a number. The clouds node is set up with pure blue (0, 0, 1) and pure white (1, 1, 1). The in-between values are interpolating between those.

Pure blue, converted to a number, is (0 + 0 + 1) / 3 = 1/3.

Pure white, converted to a number, is (1 + 1 + 1) / 3 = 1.

So - interpreted as a number, the Clouds node is producing a cloud pattern that varies from 1/3 to 1.

The Displacement is set to 6 (inches) which is multiplied with the Cloud's numeric value.

6 inches * TheRange(1/3 to 1) = TheRange(6 * 1/3 to 6 * 1) = TheRange(2 to 6)

Thus, the middle sheet Y coordinates are now somewhere in the range 2 to 6 inches.

As I have placed the pink sheet at 5 inches, we see a few places where the pure white value is poking out over the pink sheet. And all the blue is 2 inches from the green sheet. Wherever the color is between blue and white, the middle sheet slopes up between 2 and 6. Awesome - everything makes sense.

The cloud output, numerically, is TheRange(1/3 to 1).

Using a math node I have established a manipulation of the Clouds like this:

Clouds * 1.5 - .5.

Substituting the range of values, I can conclude that the output of the Math_Functions node is:

TheRange(1/3 to 1) * 1.5 - .5

= TheRange(1.5/3 to 1.5) - .5

= TheRange(.5 to 1.5) - .5

= TheRange(0 to 1)

Yay! I converted the original range to my target range 0 to 1. Boom - the middle sheet stretches from 0 to 6 inches exactly now.

All of the manipulations along the Displacement chain of nodes has NOTHING to do with the Diffuse_Color chain. They are unrelated even though they eventually both consume data from the Clouds node.

Cheers Baggins, I appreciate all the time you put in and guess what?

I get it now, I proper get it.  The only problem I'm left with, and this is entirely down to me not the system, is where math is involved.  I get that aspect of it as well, but it's not something I'm ever going to be able to do at a leisurely pace.  I absolutely hated maths at school and used to twag as much of those lessons as I could get away with.  These days, the only reason I hate maths is because I'm not efficient at it, and unless it's basic stuff, I just reach for a calculator by default.

That said, at least I understand the system now, so again, thanks very much for that

Now that I'm not thinking blindly, I should be able to absorb what I see, and even the fancy stuff, I'll get that after a few looks.  One of the reasons I've suddenly become so interested in the nodes is because I was going to model my sequencer as a way to get practice in with both Wings3D and the Poser Material Nodes.  It's got one of those blue monochrome backlit LCD displays, and I wanted to be able to mimic how it fades and inverts depending on the angle it's viewed from.

Definitely a job for some nodes, although even understanding the system, I'm going to have to do a fair bit of playing around before I can do something like that.  On the one hand something tells me it might be quite simple to do, but then I think no, hang on, that might not work or even be possible.

Haven't attempted it yet, but to do it I'm guessing I'd need two planes: one for the graphics and one for the background.  That they both need to react to the camera in an opposite way (to get the inversion effect depending on angle), and that the data collected from the camera controls the effect on each plane or something like that.

I have long amused myself with synths, too. (Since the 70s)

I know that synth sounds can be designed without knowledge of math. So can Poser shaders. However, getting good at it, with realism - well that's a different story.

I used to tweak my synth piano sound, by ear alone, for hours and then play it for ordinary people, who would inevitably tell me I still failed to match the sound of a piano. My musician friends agreed I had done good work in getting it closer, but my non-musician friends only had scorn for the large gap between what I was trying to achieve and what I'd actually done.

Shaders are like that, too.

Eventually the synth tech got so good that all the sounds I wanted were literally recorded and available. There wasn't a lot to do in "creating" a sound, and I got bored with it and took up 3D. I still play the instruments (both real and synth) but I don't spend any time tweaking sounds. There is still work to do as an artist, but not so much as a craftsman.

The 3D equivalent would be assembling a render by pasting photos into a collage.

QUOTE:
"The 3D equivalent would be assembling a render by pasting photos into a collage."

Yeah, but to be fair, I'd only attribute that to most sample-based synths or ROMplers.  I never really saw those ROMplers as true synthesizers because they're just playing back a recording, sort of cheating.  I prefer Analogue Subtractive, FM, and Additive synths (and the various takes on them) - they are true synthesizers in every sense of the word.  That said, I've no interest in making synths sound like real instruments.  A good Trance lead is an good sound in it's own right and wasn't meant to sound like any real instrument.

I was in love with the KORG M1 when I first heard one (and it's a cool piece of kit), but after having a similar synth, the novelty soon wore off ROMplers.

Comparing what's difficult for me with Poser nodes to what's difficult for me in synth design is pretty much the same; it's the math stuff I hate the most, but I love it all the same because it's mainly the structures of synthesis that interest me so luckily I don't have to concern myself with the heavy math too often.  Whenever heavy math crops up in synth design, it brings me to a crawl until eventually I work it out and can shove it into a module, where hopefully, I won't have to bother with it too much again.

I get what I want (eventually), but no doubt the way I do the math can be done in a more efficient way.

Anyway, like I said, I'm going to have a go at that sequencer, and the display comes first because if I can't get that right then the rest would be a waste of time.  Expect a thread featuring stange, totally messed-up node setups coming to a forum near you soon!

:woot:

"I like poser, as it lets us render what we want, as opposed to lux, which dictates what it allows.  "

Not a LUX user here but the above quote is not a really Fair Characterization of LUX
if you are referring to any limitations of the various poser to LUX plugins
including "Reality 3" .

Poser lets you "render what you want"(NATIVELY) as long as what you "want" is within the limitations of poser current render system.
(Any Flickerless GI animation clips on the SM website yet??)

Apparently it is the opinion of some (myself included obviously),
that posers current  native render system does not let us render what we subjectively "want" and "dictates what it allows" hence the small market for other solutions that render poser content
examples, vue, reality IPP for C4D etc etc.

"eternal struggle of man vs machine."

or  more like, the eternal struggle of man trying to render purpose built CG content
in an outside render/shading system for which it was not intended.

Nothing wrong with that of course ,but any limitations encountered are not necessarily an indictment of the third party renderer we have chosen  in lieu of the native poser one

what if the bowl was filled with pebbles as idl light sources of various colors. and a translucent water plane to let the light up.  and pretty fish. :)

Quote - I wish I knew how to make videos. I think many would have enjoyed watching me do over 100 variations in real time.

I spent most of the tutorials I've ever made with just voice, a slideshow of the steps and some minor video. I'm pretty sure you could find a free program that could allow you to put the stuff together to make a video.

I use After Effects but I paid for that (pretty much through the nose).

Paul

(mix_mash)