yep, that was the first problem i found with my equation.  sorry, i thought that was my error, or i'd have mentioned the correction.

oops, cross-post!

yeah, that's basically what i have now, just not so compactly expressed. 

oh!  and that first if is wrong because step is reversed. so you have to have

def IF(test, tv, fv):
    return test * fv + (1 - test) * tv

Hmm. You think the false value should be multiplied with truth of the test?

Why? If the x value is below that threshold, you want the linear expression, not the exponential one.

Also, I may have gotten the constants wrong. Looking over my library, I have 3 different sets of equations. I may have grabbed an earlier one where I had not yet discovered that some of the constants published in certain sources are wrong.

Sorry about that if I got the wrong constants.

Using clouds for data.

Step detects dark parts, below a certain threshold.

I multiply that with blue - b for blue, b for below.

That which is below the threshold should be multiplied with the true case, since that was what I originally wrote, where true was "it is true we are below the crossover point".

Right.

So, I'm trying to learn Shader Mixer, Daz Studio's answer to the Material Room. Purpose of the exercises: to determine whether one can draw on Poser Material Room node behaviour understoods or not.

It's probably: or not.

In any event, I'm trying out the BB setups from scratch: an excellent exercise, really. Trying to remember what the heck we were trying to understand with these shader setups. Like this one:

In Bagginsbill's words:

We start on the right with some color map - whatever original texture.

The middle Color_Math:Subtract is finding out how the texture map differs from some reference color. Here I actually sampled a color from the texture itself.

So the subtract is producing positive and negative delta colors (colors that represent the difference between two colors). The more the texture is different from the reference color, the more positive or negative the delta color will be. We cannot "see" the negative delta colors, but they are there, for sure.

The next step, on the lower left, is where I multiply the delta with a factor. If I use a factor less than 1, I decrease the delta color intensity. If I use a factor greater than 1, I increase the delta color intensity.

Finally, in the upper left Color_Math:Add node, I add back the reference color.

When the same color is used in both the subtract and the add, this serves to simply control the intensity of color variation, around that reference color.

However, when I add in a color that is different from the subtracted color, then I can actually shift what color this produces in the final output.

Which I understood this way:

The first point of this exercise is in this part of the explanation:

the subtract is producing positive and negative delta colors (colors that represent the difference between two colors)

...which can be hyper- or hypo-colours, which we can't appreciate visually, but just subtracting the control colour from one sample (dropper) of your image and chances are you're going to end up with a number below 0:

123, 149, 56
minus
127, 163, 72
equals
-4, -14, 16

Here's my version:

Then, your control bit is the Math_Function(Add) value, with which you regulate just how much of the colour you're going to add back. Which is going to affect those deltas, isn't it? Never even really thought about it (although I should have, since that was the point!), but since the deltas are pretty much an unknown, making that value something other than 1 is going to produce some interesting (read: unpredictable) results, isn't it?

Anyway, here's the deal in DS. Whether or not I did this accurately is another matter, but I've tried to reproduce the node-set in bricks:

Not the same results. Interesting.

I don't  understand what you're seeing that's wrong.

(I'll number the bricks/nodes 1 - 4 starting at the left for ease of writing.)

4 is the source image, right?

3 removes 128 of the green element of the source image.

2a multiplies the green-subtracted result by 1 (the value provided by 2b).

1 adds in 128 of the green element.

Result? The same as the source image since all you've done is remove 128-green, multiply by 1, then add 128-green.

Did I miss something obvious there?

EDIT: Ah, it's the in-between delta colour you're pointing out is different. I was concentrating on the result and not the working-out that led there, sorry!

But even then, there's nothing out of the ordinary, since the Poser node set-up is not subtracting pure 128-green. The colour tile in the colour-subtract node is a combination of all RGB elements, so the result of subtracting it from your source image is going to be different compared to subtracting just 128-green.

The subtracted color is arbitrary and whatever you want it to be, since the goal of this shader group is to alter the contrast around a particular color, whatever that may be. But it is a control parameter that decides how to anchor the contrast adjustment in color space. By choosing a different control color, you get a different calculation.

Even in Poser. See above image.

In this network, the reference color you subtract and add is the ONLY color in the source image that remains the same in the final image. It is not altered. That's because the delta color is 0, and 0 cannot be altered by multiplication.

Other colors are altered, and the degree of alteration depends on how far away those color are from the reference color.

Quote - Then, your control bit is the Math_Function(Add) value, with which you regulate just how much of the colour you're going to add back.

Not quite accurate. It controls how much of the difference from the reference color you're going to add back.

Quote - Which is going to affect those deltas, isn't it? Never even really thought about it (although I should have, since that was the point!), but since the deltas are pretty much an unknown, making that value something other than 1 is going to produce some interesting (read: unpredictable) results, isn't it?

The deltas are not known to you but the manipulation is known to you. So the results are not at all unpredictable.

I predict that regardless of the multiplier, the reference color will not be modified. Colors near the reference color will be modified only slightly. Colors that are very different from the reference color will be modified a lot.

If the multiplier is more than 1, color differences will be magnified. If the multiplier is between 0 and 1, color differences will be minimized - resulting in less contrast and giving a stronger overall sensation of the reference color. If the multiplier is less than 0, differences will be reversed. A color that has more red than the reference color will then have less red than the reference color, etc.

I can say even more about what I can predict, but I have to go to work.

I tried to faithfully reproduce the bricks to match the Poser nodes functionally. Brick for node. If you look at the preview of brick one and the preview of brick 4, they are different. Functionally identical to the Poser node set, shouldn't they produce the same result, regardless of what colour you pop in there?

I'll do it again, but I'm pretty sure that I used exact the same colour to subtract in the Poser shader as I did in the SM shader (0, 128, 0).

I'll try again and get back to you.

Quote - I'll do it again, but I'm pretty sure that I used exact the same colour to subtract in the Poser shader as I did in the SM shader (0, 128, 0).

But but but I can see the color of the green is different. How can you say you're pretty sure they are the same when just looking at your two screen shots the color values are clearly different shades of green.

Yes the outcome between the Poser and the SM versions should be the same, and they are. The final result looks the same as the input color map. I thought we were talking about how the intermediate value is different. The intermediate value is not going to be the same because you're using a different color.

f(x) = m(x - k) + k

Where you used m = 1.

The result is

f(x) = (x - k) + k = x

Clearly the output of f(x) is just x, regardless of what value of k you use, but only when m is 1.

Anyway, you have m=1.

So the middle node is (x - k).

That is NOT the same unless k is the same.

k is your reference color green. You used two different colors. So the middle value is two different outcomes. The final value is the same in both.

However, if the multiplier, m, had not been equal to 1, but equal to something else, then the outcome would be different as well. The output would no longer be exactly the same as the input.

The only time the f(x) = x is when m=1.

Given f(x) = m(x - k) + k

We can examine under what conditions f(x) = x, i.e. when does f do nothing.

f(x) = x

m(x - k) + k = x

mx - mk + k = x

mx - x = mk - k

(m-1)x = (m-1)k

There are two ways this can happen.

(m-1) = 0

i.e. m = 1.

The other way is:

x = k

Which is to say when the input texture is entirely made of the one color k - then m doesn't matter.

Quote - How can you say you're pretty sure they are the same when just looking at your two screen shots the color values are clearly different shades of green.

I suppose it is possible that Shader Mixer doesn't accurately create a colour based to what you type in in the Microsoft Colour Picker, so that the actual colour in the Value 2 channel of the Subtract brick (Math 2 (7)) would be different to the Value channel of the Add brick at the end (Math 2 (5)). Which strikes me as a bug.

And which is why I'm wondering why the previews of that first node (Image (6)) and the last node (Math 2 (5)) aren't identical.

Not why the outcomes of the Poser node set isn't the same as the outcome of the SM output... I should clarify.

Uhoh - you completely misunderstood what we meant.

Not two different colors in shader mixer.

Two different colors between the Poser nodes and the DS bricks.

In the poser shader you used a different green. Functionally the nodes are the same, but you did not use RGB 0, 128, 0 in POSER.

So back up - rewind.

When you said "not the same results" please clarify. We've been addressing the magenta preview of the middle node. You're not talking about that are you.

You're talking about Brick Image (6) is not identical to Math 2 (5)?

Is that what you're talking about?

We thought you were talking about that fact that the Poser nodes and the DS bricks look not the same.

So we have to approach the question by testing assumptions.

The most important assumption is this - does SM keep hypocolors (less than 0) or does it clamp them at 0?

This is a fundamental thing I talked about early on in this thread - that Poser allows us to manipulate colors as arbitrary numbers, even if the intermediate results cannot be "looked at" on a computer monitor.

This is easy to test.

Start with the original texture. Use a brick to subtract white. Then use another brick to add white.

This is (x - k) in the first brick.

Then (x - k) + k in the second brick.

If you do not see x, the original image, then something non-linear happened in the middle. If it is completely white, the intermediate value was clamped.

If SM clamps intermediate results (no less than 0, no more than 1) then you are screwed and cannot make the same things as we can in Poser.

(NOTE: Had to edit - earlier I sad completely black. I meant white.)

On the top we have what Poser normally does.

If SM is doing the bottom, you'll get white instead of the original texture.

If you get something resembling the original texture, then it's not clamping.

If it's not white but not exactly the same as the original either, we'll investigate something else. Probably just a preview issue.

So, RobynsVeil, it's not the intermediate stuff you're talking about. Correct?

I've spent an eyestraining half-hour colour-picking colours from one preview and another, and the change from the source is not making much sense except if it's as bagginsbill says and it's a preview issue. It's difficult to see what exactly is taking place because the source texture is (I would guess) much larger than the shape it's been previewed on so it's not being displayed 1:1, making a direct pixel-to-pixel comparison impossible. Some solid colours would be better to see what changes are going on in your brick network between source and output.

Further: If I sample (not very accurately, I must admit!) the colours that occur in one area of the preview and then sample (again, very approximately) the colours from the same area on the other preview, it appears that something is changing in the red and blue components, too. Which is strange if all you're doing is subtract 128 of green. You'd expect the clamping to show up (if that's what Shader Mixer does) in the green component and leave the red and blue alone. But that's not happening. Every component of the source image is changing.

Quote - So we have to approach the question by testing assumptions.

The most important assumption is this - does SM keep hypocolors (less than 0) or does it clamp them at 0?

This is a fundamental thing I talked about early on in this thread - that Poser allows us to manipulate colors as arbitrary numbers, even if the intermediate results cannot be "looked at" on a computer monitor.

This is easy to test.

Start with the original texture. Use a brick to subtract white. Then use another brick to add white.

This is (x - k) in the first brick.

Then (x - k) + k in the second brick.

If you do not see x, the original image, then something non-linear happened in the middle. If it is completely white, the intermediate value was clamped.

If SM clamps intermediate results (no less than 0, no more than 1) then you are screwed and cannot make the same things as we can in Poser.

(NOTE: Had to edit - earlier I sad completely black. I meant white.)

Precisely what I was thinking...

And I apologise for not being clearer in what I was trying to say.

What I'm trying to establish is where SM bricks differ from Poser node in behaviour... what they do beneath the surface. There's no Bagginsbill for Brick behaviour... well, perhaps the developers themselves, but they ain't talking.

So, I'm using your testing methods to make sure what I think I see is actually what is happening. The Microscope/magnifying glass approach. So, I'm re-doing all the exercises we did in this thread both in Poser, and then setting them up in SM.

Sorry for wasting your time, Bill, because I was unclear... and thank you again for all the help you have given over the past years! Your patience and tolerance does you credit! Not to mention your generosity with your time!

Just finished a bit of housework, so I was away from the PC... thank you all for pondering this question and responding!

Quote - Start with the original texture. Use a brick to subtract white. Then use another brick to add white. This is (x - k) in the first brick.

Then (x - k) + k in the second brick.

If you do not see x, the original image, then something non-linear happened in the middle. If it is completely white, the intermediate value was clamped.

If SM clamps intermediate results (no less than 0, no more than 1) then you are screwed and cannot make the same things as we can in Poser.

Yep, this is what I'm going to generate in SM... and thank you for the recipe. Once again! If SM does clamp values and doesn't deal with hyper/hypo colours, then true: I'll be limited in a lot of things I do. And I mean, a LOT!

Quote - Further: If I sample (not very accurately, I must admit!) the colours that occur in one area of the preview and then sample (again, very approximately) the colours from the same area on the other preview, it appears that something is changing in the red and blue components, too. Which is strange if all you're doing is subtract 128 of green. You'd expect the clamping to show up (if that's what Shader Mixer does) in the green component and leave the red and blue alone. But that's not happening. Every component of the source image is changing.

That's a very good point. Another reason why a bit of documentation as to what the maths bricks actually do with colour math would be helpful. One of the wiser heads on the Daz forum opined: "Your recreation of BB's network looks to be acting as advertised - it's pulled in the extremes of the variation in colour to my (highly unreliable) eyes. However, it's true that the previews often seem to be less than wholly helpful."

Might it be an issue with how the previews are generated? Makes them patently useless, then.

Quote - One of the wiser heads on the Daz forum opined: "Your recreation of BB's network looks to be acting as advertised - it's pulled in the extremes of the variation in colour to my (highly unreliable) eyes. [...]

But that would only happen if your multiplier (in brick 2b) were not 1. It is 1 in the brick set-up as shown, so it should leave things the same as it found them.

I agree. It's not acting as advertised. I don't believe that the aforementioned wiser head is completely au fay with the actual inner workings of the actual bricks, and wants to dismiss the variance in colour output to limitations of the preview pane.

Which I don't think is correct at all, and I intend to use Bagginsbill recipe to prove it.

Thank you, John, for following along here.

I'm actually finding the SM system fairly workable - despite the fact that documentation is scant - and intend to make it a bit less of a mystery to Daz users (as I do my experiments and publish them) whilst I do so for myself.

I must say: a completely different environment prevails there to here. I haven't really got that many people interested in these experiments: neither the developers themselves nor any of the DS3Adv users.

Pity.

Quote - and wants to dismiss the variance in colour output to limitations of the preview pane. Which I don't think is correct at all, and I intend to use Bagginsbill recipe to prove it.

I wouldn't discard the "preview is hopeless" hypothesis just yet. From my tedious 30 minutes looking at one preview and the other, I could detect no real pattern as to the changes taking place in the red and blue components (which is where the real puzzle lies). If it were something mathematically precise going on in the brick arithmetic, I'd expect some kind of predictable pattern to emerge. But as far as I could tell, there wasn't anything but seemingly random fluctuations. Which suggests it might be a preview-display issue. Of course, further tests will add some extra info to work on. I'm even tempted to download a trial of DSA and install it, now!

Quote - I must say: a completely different environment prevails there to here. I haven't really got that many people interested in these experiments: neither the developers themselves nor any of the DS3Adv users.

Pity.

Generally, the folk at Daz are proud of their lack of interest in technical matters. I've tried to help out over their on occasion, but usually one idiot or another complains that I'm making their head hurt for no good reason.

There's also the occasional brain fart who says I don't know what I'm talking about. Either way, I have not made 10,000+ posts at Daz.

I highly doubt that a preview of a texture (image) is done the same as the preview of a math node. One is going to involve image reduction (averaging), the other isn't.

An easy test would be to simply compare x with x + 0. If they look different, well then don't trust the details of the preview.

Quote - > Quote - and wants to dismiss the variance in colour output to limitations of the preview pane. Which I don't think is correct at all, and I intend to use Bagginsbill recipe to prove it.

 

I wouldn't discard the "preview is hopeless" hypothesis just yet. From my tedious 30 minutes looking at one preview and the other, I could detect no real pattern as to the changes taking place in the red and blue components (which is where the real puzzle lies). If it were something mathematically precise going on in the brick arithmetic, I'd expect some kind of predictable pattern to emerge. But as far as I could tell, there wasn't anything but seemingly random fluctuations. Which suggests it might be a preview-display issue. Of course, further tests will add some extra info to work on. I'm even tempted to download a trial of DSA and install it, now!

Or, you could just see if you could find a copy of Eilir, which is what Shader Mixer is all based on.

Either way, I'm convinced you'd make infinitely more headway with this - and at a much faster rate - than I am at the present.

If their preview pane is going to be so unreliable - brick to brick - it makes that pane fairly useless, doesn't it? BTW, I did change the value of that Math 1... OH! I think I've discovered what might have been the problem!

BRB

So, in my typical bungling way, I stuffed up again. The Math 1 node isn't an Add node at all, by default:

Now, it's right. So, all the speculations that SM was doing a clamp etc were wrong. It's doing maths corectly.

My apologies.

Going to need to pay close attention to these bricks and not assume anything. Also, it might help to do this work on the big screen instead of the laptop where screen real estate is limited.

I promise to go over every detail of my shader before I post again! :blushing:

You mean, you weren't feeding 1 into the multiplication? Oh my.  Well, it was an interesting diversion, and might have sparked my interest in looking into DS. So it wasn't too bad.

Quote - You mean, you weren't feeding 1 into the multiplication? Oh my.  Well, it was an interesting diversion, and might have sparked my interest in looking into DS. So it wasn't too bad.

That's correct. I was feeding Sine of 1 (float). :blushing: So do I feel the priceless ass! But, undaunted, I shall henceforth be infinitely more careful in publishing my work, both when it appears to work and particularly when it appears not to.

I initially found the over-ride channel-input methodology/behaviour insufferable, but now as I play with it more, this shader system appears to have more redeeming qualities than annoyances. SM and Shader Builder appear to be mostly designed for procedural (vs enhancing image texture) work.That's my take on it so far.

And yes, you can leverage Poser MAT room knowledge, to some degree.

Meanwhile, I just published matmatic 1.2.0. RV, you can now set image gamma.

Thank you, Bill... I've seen and downloaded. Doing the happy dance!

Being lured back to Poser (away from SM) aren't I?... building shaders brick by brick is tedium incarnate. And I'm not about to try to get my head around RSL: Python's plenty challenging enough.

Quote - ooooo, yay!  PM sent!

RobynsVeil and i have been emailing back and forth to share our understanding of Matmatic scripts.  it's been very enlightening.

That was over two years ago, this was written. I'm taking up this thread again with first a heartfelt thank you and then some observations.

The thank you goes to KobaltKween. When she said "sharing", she was really doing the bulk of the sharing, to be honest, particularly the last few weeks. What I do now understand about class/method/property/value behaviour and usage I owe directly to her, particularly since she gave me this information in the context of Matmatic, which is now a completely different tool to me. Whilst she gained much from BB's showing us his Mix() script, I confess that there were massive holes in my understanding with I'm sure my lame implementation of the script must have glaringly exposed.

I do want to say that KobaltKween is the most patient, kind, steadfast friend I have... I am deeply in her debt for bringing something to me I so desperately wanted: a better grasp of writing re-usable code using classes.

Now, to the observations.

There is no question to me at least that writing procedural code (poorly, but I sort-of knew how to use parameters and stuff to kind-of make functions that could be used again) for 15 years was really a hugely inhibitory factor in getting my head around classes. There is still much about classes I don't understand, but several things have finally shuddered home, finally. I mean, anyone who has tried to explore OOP has heard the "blueprint" metaphor: yet, those of us coming from procedural have to let go of the fact that code that is written isn't active in memory just because it's there... it's just a definition. Nothing's happened yet. That took me ages to get my head around, for some reason, and caused a lot of errors to happen, some of which didn't really describe the problem, well, to me. :blink:

Now that some of this has finally sunk home - some the the basic behaviour of this stuff - design is becoming somewhat more interesting. Like, where do I do my error-trapping? for instance.

I know all this is a bit oblique, but that's by design. The more I work with Matmatic, the more I appreciate the brilliant tool BB's given us (you probably thought it was gathering cobwebs on a hard-drive somewhere, didn't you, Bagginsbill? ) but also, the greater the challenge to write clean, re-usable code with decent design.

What do I use it for? Well, I'm not going to be particularly discrete when I say I clean up (and customise) shaders with it. I'll be honest: I haven't gotten a grip on using VSS with hair, for example, and besides, it's an additional series of steps that I avoid by just writing a quick collection (in, say, a AllHair.py, for example), then with a few lines of code I can add that hair to my growing hair shader script... and generate an mc6. With a setting change, I can go from making a simple non-GCed version (for PP2010 or for export to Lux) to a material-GCed version to a corrected-sRGB version.

So, Matmatic is an integral part of my workflow making a scene for Poser, or indeed, even Lux. And classes have made that workflow excitingly more flexible, powerful and cleaner (well, design enhancements will effect that, I'm sure).

Be curious to know how others are using Matmatic these days...

Thank you!

I've been riveted to this practcally all day, and read from first word to last word, and I will read it over and over and over again, yet already the mysteries seems graspable, as I read on, just in this single day I became increasingly familiar with the termanolgy and general concepts that had been a seemingly impossible barrior to me.

and I'm hoping to really explore Poser's material 'room', can't thank you enough!

You'll enjoy Poser Pro significantly more as a result... well done, reading this thread! Oh, and Python/matmatic is not as hard as it sounds. It's really quite straight-forward. That's where the real fun is!

I have been using matmatic extensively for the hundreds of materials I include in the products I do with DreamlandModels. I made a couple improvements I will publish.

One of the design choices I made early on regarding material collections was based on the premise that I would be doing the same collection over and over (a figure) and so it was important to establish automatic rules so that in the script I only had to set a couple zones.

For example, I could assign to both fingernails and toenails by saying

c = Collection()

c.nails = Glossy(RED * .25) # assuming Glossy is a function that creates a shader

But this turned out to make life more difficult when one had to deal with a different prop or figure on a daily basis. In that situation, setting up rules for implied material assigments turns out to be more trouble than it's worth.

So I added a new method to matmatic's Collection object - apply. No rules or smarts, you simply give it a material and a list of zones to apply to. If you forget one, it will do nothing to help you, but it is easy enough to make your lists once and use them again.

So now my approach is like this:

c = Collection()

c.apply(Glossy(Red * .25), "fingernails", "toenails")

Another decision I made long ago that is not so great is that the name of your matmatic script appears in the name of the materials it generates. I made a new option to stop that - if the name in the outputs list begins with the equals sign (=) the script name is not added. It will just use the name as is.

Also, I need to create and use subfolders, and these are allowed in the output name as well. So for example, if I want to put a Blue.mt5 file in a subfolder called Paints, I can say:

outputs += [ "Paints/=Blue", someMaterial ]

In the shaders I use for Furniture Set One, I have four wood zones I need to populate over and over again.

woodZones = ["Panels", "DrawerFaces", "Top", "Feet"]

And I often make lists of colors, like this:

paintColors = [

  (IColor(.4, .05, .05), "Dark Red"),

  (IColor(.5, .7, .6), "Some Green"),

]

And I have a loop like this to make mc6 files for the wood zones as well as a single material file, one each per color:

for clr,name in paintColors:

  material = Glossy(color=clr)

  fileName = "Paint %s" % name

  outputs += [ "Singles/=%s" % fileName, material ]

  outputs += [ "Wood/%s" % fileName, Collection().apply(material, *woodZones) ]

Another workflow thing I improved has made a huge difference. I do not write a material file if it isn't different.

This doesn't sound like much but it really is. Matmatic now generates the material and if the file exists already, it examines the contents to see if what it just generated is the same or different. If it is the same, it does not write over the file. The reason this matters is that the file's modification time stamp remains the same.

By itself that sounds like a "who care's" thing, but for the fact that I also have another script that automatically generates thumbnails by doing renders of every material. When a material and its thumbnail both exist already, it examines the modification time stamps to see which is newer. If the PNG file is newer than the material, it assumes (usually correctly) that the thumbnail is up to date and can be skipped.

So now I have a script that generates 200 to 300 materials. When I make a tiny change - perhaps a color change to one paint - only a few are affected. Then the thumbnail generator runs and only a few renders are done.

These changes have saved me many hours.

Quote - I have been using matmatic extensively for the hundreds of materials I include in the products I do with DreamlandModels. I made a couple improvements I will publish.

So, I'm assuming the Feb 2nd release (1.5.0) is not what you're referring to, here, BB?

Sheesh, it's been a bit since I've done much in Poser, but that's soon to change: I'm looking at doing scenes/sets at the moment. Working on a 221B Baker Street Victorian era set at the moment, which will definitely not be a for-sale item, since I'm using it as a Blender modelling learning tool. But there will be extensive material management needs for this set, which your improvements to matmatic should address nicely.

Quote - > Quote - I have been using matmatic extensively for the hundreds of materials I include in the products I do with DreamlandModels. I made a couple improvements I will publish.

So, I'm assuming the Feb 2nd release (1.5.0) is not what you're referring to, here, BB?

Sheesh, it's been a bit since I've done much in Poser, but that's soon to change: I'm looking at doing scenes/sets at the moment. Working on a 221B Baker Street Victorian era set at the moment, which will definitely not be a for-sale item, since I'm using it as a Blender modelling learning tool. But there will be extensive material management needs for this set, which your improvements to matmatic should address nicely.

Sounds like a very nice idea for a set Robynsveil

Have you got Sherlock Holmes / Watson characters already?

I've still failed to play around with matmatic much yet... too many readymade BB shaders now to play with in my runtime from those BB/Dreamland products

I've been getting to grips with the mat room itself though some more... and wiring up some shaders manually with some success...

Cheers