I would think that the bump should not change, at least it worked for me without changing the bump so far. And yes, I know that my script does not handle reflection and refraction

For V4 and other figures, I use VSS PR3 at the moment. Reflecting and refracting shaders are still things which I have to do by hand, that kind of stuff needs fine tuning, almost always. 

If you would put up a better script for sale I surely will buy it. Heck, I would pre-buy everything you put up, simply because I know which kind of quality I have to expect. 

Ice-boy, if I want it to be perfect, I will have to touch every shader. But since this is my hobby and my time is limited, I try to automate things as far as possible.And even if I fine-tune a shader, it helps to have the GC module automatically added to a material instead of plugging the nodes inside by hand. Especially in big scenes, with dozens of materials. 

Quote - I would think that the bump should not change, at least it worked for me without changing the bump so far. And yes, I know that my script does not handle reflection and refraction

For V4 and other figures, I use VSS PR3 at the moment. Reflecting and refracting shaders are still things which I have to do by hand, that kind of stuff needs fine tuning, almost always. 

If you would put up a better script for sale I surely will buy it. Heck, I would pre-buy everything you put up, simply because I know which kind of quality I have to expect. 

**Ice-boy, if I want it to be perfect, I will have to touch every shader. But since this is my hobby and my time is limited, I try to automate things as far as possible.And even if I fine-tune every shader, it helps to have the GC module automatically added to a material. Especially in big scenes, with dozens of materials. 
**

i like that people play in poser and with scripts. i am happy that they are trying to experiment.

i just dont want to see people pushing a button ''make GC'' and its done. no its not done.
i am watching some renders and they look of because the cloth shaders are not matching with the skin shader.

But even then I like the CG-part to be added via script. 

edit: yes, I know the clothing still is to bright here. That's the model I'm working on at the moment, and the render I had ready. 

Thanks for all your replies. This was more like what I was looking for.

We have to look at ice-boy's concept of the necessity for tweaking a valid one. And for those who like that sort of thing - me being one - I'd like to see a discussion-group dedicated to how to incorporate colours and reflection/refraction/conservation of energy and all the rest and develop shaders that then make the most of that material. Out of this are going to come sophisticated solutions and some not so clever. Doesn't matter, as long as people see that GC is important and try to do something about it.

The one-button script to fix simple materials has a lot of merit, particularly for the double-click / render crowd. Yes Bill, I believe if it were marketed correctly, you would sell it quite well. Let's not forget we are addressing a niche market, here, one that will evaporate as people migrate to Poser Pro, so make it simple and soon. The resultant shaders will no doubt produce a better render than not having done anything to the material at all.

However, for ultimate realism, some of us more pedantic artists are going to want to learn techniques and avoid pitfalls associated with GCing some of the more shader-rich materials out there... and there are a fair few.

Which brings up a point...

Quote - It occurs to me that while my technique is fine for shaders authored by me via matmatic, it's not particularly a good workflow if you're trying to take an existing shader build by someone else with a crapload of nodes and all you have is the material. In such cases, you're forced to reverse-engineer the shader and make an equivalent Matmatic script. That's a pain in the butt.

Yep, gone that route, Bill. It's an education in shaders... I can pretty much recreate in code most manually-strung-together shaders I run into. Your 52-node leviathan skin shader would not be one of those, since it's created with a very sophisticated maths that I am struggling to get my head around - note the work "struggling", which denotes effort being expended. However, I've been fiddling with Matmatic and other people's shaders long enough now to come to the realization that some material developers went into the material room and without any understanding of the actual physical properties of the materials they were trying to recreate mucked around until things "looked right". Which means that they set reflection and diffuse values in nodes and on PoserSurface unrealistically high, which was analogous to setting your lights too high... they were kinda on the right track, but weren't really addressing material optimization correctly. So, what you end up dealing with is a bogus shader.

Now, to fix it. You could go in just about any direction you want to with a shader... develop a completely new look which I'm not completely certain even the original developer had in mind. I recently GCed a very simple item - the Hongyu Jersey dress, default colours - and turned it into a much lighter grey (as opposed to a dark brownish colour) and ooohhhh, didn't the underlying pattern suddenly come out beautifully. Was this Hongyu's original intent, though? Who knows? End of the day: who cares? Well, some might... some want that colour, just corrected, not something completely different.

So, we're going into a very interesting area here, and we haven't even looked at tricky areas like reflective / specular aspects to our objects.

And THIS is why I saw a crying need to discuss this concept further. I saw myself writing Matmatic "solutions" that would faithfully recreate a GCed version of the original shader, but whoa, was that really what I want.

So, a topic of exploration could be: what constitutes a "valid" shader? What things do we need to watch out for to prevent violating the laws of nature? The Kerkythea Materials Manual discusses conservation of energy quite thoroughly, but can one faithfully apply all of those principles in Poser?

dont get me wrong.
i want you to do this. it will be practical

Once you use a GC shader of BB in a render, the rest of the render will look off if you don't correct everything else. I got sick of it, and broke down and got poser pro, should finish paying for it some time after poser 8 comes out.

But is GC each object enough? No. BB's shaders take use more than GC, there's that whole conservation of engery thing. Easy enough to understand on a physics level, but to impliment it in poser is another thing. Again when you halfway an image, the non BB shader part stands out again.

Even if BB ever comes out with his 1000's of shaders in a pack (which I wish he would), you'll hit something missed.

In bussiness there is the whole ISO debackle, and that's what I'd like to see function in a real function way for poser. BB aproved shaders.

Now a database of shaders, both general to be applied and specific to avaible props, would be great time saver. But they would all have to have the same quality.

Quote - dont get me wrong. i want you to do this. it will be practical

If that remark was with reference to what BagginsBill and Bantha are proposing, I agree. Either proposed script has a valid application. I'd love to have a go at Bantha's script to simplify what I'm doing (and probably show up mistakes I might - probably am - making). For those more pedantic artists, Bantha's script could be a good starting point to get the more obvious stuff out of the way.

Bill's script sounds like a solution for the one-stop, double-click and render crowd. Yes, there IS a market for it... NOW. As time moves on and the economy shifts and improves and people upgrade to Poser Pro that utility will lose marketing appeal. But it is a very valid product now.

My MAIN question has really not been addressed, though. My experience with Poser users has been thus: if they are new to the product, they tend to be overwhelmed by features such as parameter dials and render settings and tend to avoid the material room. If they are seasoned users, they've come up with their own kludgey nuclear-level-lights solutions to the material issue and see this as a too-hard-basket project. What, convert my entire RUNTIME??? No freakin' way! For those users, just even getting them to understand what the problem is and what needs to be done is far beyond their interest level: "I know what I know... don't confuse me with facts!" Getting a buy-in would involve some very aggressive marketing well beyond the scope of a forum, and would also implicate the Poser product itself has having a defect, something an artist would hate to have to acknowledge after having plunked down hard cold cash for the thing.

So, we're facing some challenges on that front. If we could, however, do a before-and-after render shoot with recognized artists endorsing this process we might see a turn in public opinion and an increased interest in obtaining a solution.

Quote - Once you use a GC shader of BB in a render, the rest of the render will look off if you don't correct everything else. I got sick of it, and broke down and got poser pro, should finish paying for it some time after poser 8 comes out.
But is GC each object enough? No. BB's shaders take use more than GC, there's that whole conservation of engery thing. Easy enough to understand on a physics level, but to implement it in poser is another thing. Again when you halfway an image, the non BB shader part stands out again.
Even if BB ever comes out with his 1000's of shaders in a pack (which I wish he would), you'll hit something missed.
In business there is the whole ISO debackle, and that's what I'd like to see function in a real function way for poser. BB approved shaders.
Now a database of shaders, both general to be applied and specific to available props, would be great time saver. But they would all have to have the same quality.

The notion of having to convert an entire runtime's worth of material is daunting, isn't it? So, you've been doing it too, have you? But gave up? What if you were able to obtain the GCed version of your materials somewhere... as a free download? Would that interest you?

There are going to be different levels of quality of GC, General. Not everyone can develop as elaborate a shader as can BagginsBill. However, your last point is essentially what I'm hoping to see happen: a sort of database of shaders for different materials. Or a trading zone, kinda like the freebie section on here, except for GC.

This can happen on a grass-roots level, but only if enough people 1] see the need for it and 2] have the skill to GC their materials and 3] are willing to share the product of their work with others. A question that begs asking here is: are we looking at potential copyright issues? Taking someone's work and merely adding some nodes to it to make it render better... is this going to be an issue?

My understanding is (from doing alternate hair textures for published hair models) you can reference the original artist's transparency map in your PZ2 file... but you cannot use in any way the original artist's colour map. Correct me if you know differently.

So, are we kinda looking at the same issue, here? Does that place sharing GCed materials into a no-fly zone?

Quote - Actually I planned to release a small script which plugs this GC-module in the actual shader. The script plugs the original diffuse input in the first node, plugs the specular input in the second node, multiplies the original diffuse value with .9 and puts it in the diffuse node, transfer the specular values to the specular node and puts zero in the original specular and diffuse value.
It does that for every material which does not have a node connected to alternate diffuse, all in a given actor.

I noticed that often-times the only shader is the colour in the PoserSurface Diffuse_Color channel. This colour needs correcting... would your script take that colour into account, Uwe?

I've been copying that colour into the first colour_Pow value_1 channel... then leaving the PS Diffuse_Value at 1 and *don't change the colour in that channel to white, but attach a math_Functions add node to the diffuse_Value channel which adds 0 + 0, thus rendering that node group ineffectual for the renderer (a BagginsBill trick - see, I am learning some things, Bill!). I leave the textureMap node attached to the diffuse_color channel as well. So, the user can see the textures but that info doesn't go on to the renderer: it gets all its info from the Alt_Diffuse channel using properly-processed colour and textures.

Quote -

The notion of having to convert an entire runtime's worth of material is daunting, isn't it? So, you've been doing it too, have you? But gave up? What if you were able to obtain the GCed version of your materials somewhere... as a free download? Would that interest you?

Yes it was for GC, and I had started. Unfortunately when I got pro I got rid of those files, didn't think anyone would be interested in it. Had a few of the DM's sets done, many clothing sets and bits of other sets done as well. Basically I would do them as I went and save them to the runtime for future reference.  

Well I have pro now so the GC versions would not interest me, but the many other options would. Hair, metallics, glass, to name a few. What about bill's work on lights, with lighting sets made for GC for prop sets, as well as RsquaredLaw.

Would a free node site interest me, of course it would. Heck I'd like to help in someway if I could.

I'd like to see the material sets made up in GC, AO on and off.

How about an open source community of Materials and Nodes, someone might add displace maps for sets, transparency maps for effects etc. With each person able to take what someone else has done and add to it, making it all better for the community as a whole.

Of course this all goes on the assumption, that it's legal to reference someone's maps, when referred to a copyright map.

Brilliant idea, General! Love the way you are thinking. I'm hoping some of the forum moderators are also reading this - someone who knows a bit more about the legal side of sharing stuff and what is and what isn't cool to share.

You came up with some concepts that I hadn't even considered: alternate transparency maps, improved displacement maps, perhaps HDRI-based IBL lighting, who knows? There's heaps we could do (and share) without edging towards copyright issues. And, I suppose if I create a texture (colourMap) file of my own and add GC to it, I can do with it as I please. It's just using the original textureMap that might be dicey...

But, referencing the original shouldn't be an issue. I think the dicey part might be if they had a unique shader set up you modified. But when does a shader become unique and copyrightable? I think most artists would allow there material sets to be modified as it would add value to the original. 

That is a valid point, General.  However, it might not be as sticky as one would think.  It is apparent that more vendors are leaning towards enhancing their textures with shaders.  And, although, specific settings and node arrangements become unique for their particular produce, what is not to say that I would like to apply such to another vendor's set.  As long as the artist's creative base work is not exchanged in the process, other individuals stand to learn and benefit.  It is getting so that one node arrangement looks much like another; the novelty is gone, lets start creating something with what we have.

I believe this what the Node Cult on RDNA was about, but sadly a lot of the links are dead, now. I'm perfectly willing to use whatever forum (this or RDNA or one of our own - setting up a forum's no biggie... done it before) to share our GCed materials... but I do want an official word on the legal aspect of this.

Get clearance, and boy-howdy, am I ready to share! And what a concept... suddenly converting your runtime wouldn't be such an overwhelming task, after all.

Mind you, I have a partition dedicated to Poser, and on it, a runtime in a folder called PoserGC. It is growning leaps and bounds. What is amazing about this is that in the process of converting the material, I'm seeing all these neat ideas (some even valid!! heheheh) to make materials look more realistic. And, I find myself tweaking settings and jeez, this is unleashing a whole new beast!

I'm sure it is ok to put the name of a known image in a shader - you're not copying the pixels in any way and the user has to already have a file with that name.  I used to do that, but lately I deliver shaders without any file names in them (use VSS to populate of course) so there's no question about it.

The issue of shader copyright itself is interesting. I have been careful to avoid even the hint of non-originality. For example, I have seen face_off post his favorite settings for Blinn parameters and a couple edge blends to go on it. I have never copied that, even though it looks good to me. I found other (perhaps inferior) ways to deal with skin specular, but they are different.

Now in most cases, I've given obvious and explicit permission for people to use various of my shaders in their products, but never given them permission to re-distribute my shaders as shaders per se. Can I even do that? There are some who argue I cannot.

This is a very interesting intellectual property issue. Can I copyright (Diffuse + Specular) ** gamma? How about can I copyright my conservation of energy trick Diffuse(Diffuse_Value = 1 - Specular) + Specular?

These little tricks they don't seem to be sensible as individual pieces of intellectual property.

But what about my Loom shader that is 140 nodes? Clearly that is in the realm of copyrightable, no?

There seems to be a belief that shaders are math formulas and math formulas cannot be copyrighted. Before anybody brings that up, let me dispel that notion. All computer software expresses math formulas (Boolean algebra and predicate calculus may be unfamiliar to some, but it is math). I have been involved in the development and use of techniques to create provably correct software via mathematical modeling. Just because some math underlies an implementation of something, does not make that implementation freely unprotected.

So - making a GC version of my Loom, by taking my 140 nodes and adding a couple Pow nodes, is that copyright theft or not? I think it is for sure, because it is so freaking big and so impossible to claim there is no intellectual property there.

But what about a RebelMommy skin shader, with say 9 nodes? Is that fair game for you to copy and tart up with GC? 

How about 3 nodes?

Where is the line?

I sure some marketing company that passes it's self off as a software company would like to claim a simple "hello world" program should be copyrightable. I think that's a load of non-gamma corrected render. 

The only sure way to find out what node set up is and is not copyrightable is to have it go to court in many different countries. But it would be nice to have a quick simple cheap solution on this first.

Where does Bagginsbill draw the line, or any of the other node gurus?

I know from days of writing VBA code that that code in its entirety can be copyrighted. Your loom, Bill, would fit into a similar category. Yes, it's math formulas, but VBA code is basically Basic code arranged with a specific purpose in mind. Your math formulas are arranged in a Python script with a specific purpose. Whether you wish to copyright this and how stringent you want the copyrighting upheld (what you will and won't permit within the terms of the copyright) is pretty much up to you. Personally, I like the terms of Open Source software copyright, which I feel you've tacitly applied to your shaders and code. Basically: free, use where and what you want it for, don't claim as your own. Makes sense.

Indeed, Bill, when you handed me the essential recipe for what later developed into the shader in use for a product I'm hoping to put on the market in the very near future, you - in my view, anyway - retain copyright to that shader... and credit is given, in the Python script. Not that you'd want ownership, necessarily, but you basically gave me the darn thing so it is pretty much yours. Just like when I see a brilliant shader set (tree?) and re-create it in Python, I still see it as belonging to the person that originally strung those nodes together to achieve that effect, so in my view I should at least give credit to the originator, depending on how elaborate the shader was and how unique it was, I guess.

What we've got now is excellent opinions on what's permissible. Depending on what 3D artists use as their copyright guidelines - whether the OS movement matrix or some other model - I'd like to propose that if anyone has anything salient to add to this discussion, please do so.

Here's what I'd like to do - sort of to kick this off: submit to the freebie area a GCed version of a popular V4 clothing item. So, my question is:
--Is the freebie area the appropriate venue to do this?
--Does Rendo see potential problems with this?

Opening the floodgates....

Quote -
...
This is a very interesting intellectual property issue. Can I copyright (Diffuse + Specular) ** gamma? How about can I copyright my conservation of energy trick Diffuse(Diffuse_Value = 1 - Specular) + Specular?

These little tricks they don't seem to be sensible as individual pieces of intellectual property.

But what about my Loom shader that is 140 nodes? Clearly that is in the realm of copyrightable, no?

There seems to be a belief that shaders are math formulas and math formulas cannot be copyrighted. Before anybody brings that up, let me dispel that notion. All computer software expresses math formulas (Boolean algebra and predicate calculus may be unfamiliar to some, but it is math). I have been involved in the development and use of techniques to create provably correct software via mathematical modeling. Just because some math underlies an implementation of something, does not make that implementation freely unprotected.

So - making a GC version of my Loom, by taking my 140 nodes and adding a couple Pow nodes, is that copyright theft or not? I think it is for sure, because it is so freaking big and so impossible to claim there is no intellectual property there.

But what about a RebelMommy skin shader, with say 9 nodes? Is that fair game for you to copy and tart up with GC? 

How about 3 nodes?

Where is the line?

No idea. Mathematical formulars aren't copyrightable here in Germany, I think they aren't copyrightable in the US either. You would need a patent for that. 

So, your loom shader most probably is copyrighted. But I may re-create it. As long I make something different, it would no longer be the same shader. If I use matmatic for generating the shader it may even look eactly like your shader, even if I used my own source file. IANAL, but this does not sound like there is a simple way to draw a line.

We would need compiled shaders to really be able to protect them suitable. But then, you could no longer fiddle around with the parts of it, just with the parts which the creator wanted you to. IRC, that's the way most shaders for D|S work. 

Suppose I take a color map and draw a shamrock tatoo - can I distribute that as my own IP? Nope - it's illegal.

 (or compare to)

Suppose I take the Daz V4 shader and I add a shamrock tatoo USING NODES - can I distribute that modified shader?

Suppose I take a color map and change one pixel - can I distribute that as my own IP? Nope it's illegal.
 
 (or compare to)

Suppose I take the Daz V4 shader and I change one color parameter. Can I distribute that modified shader?

Shaders are like code, there are only so many ways (sometimes only one) to do certain things, meaning that part isn't eligible for copyright protection (see -> http://en.wikipedia.org/wiki/Scenes_a_faire).

The question of how do you tell if two shaders are the same after you've eliminate non-protectable aspects, the answer to which is compare the tree structure but ignore things which are irrelevant like the node names/labels (this is know as abstraction and filtration, see -> http://www.groklaw.net/articlebasic.php?story=20040715212732854).

I doubt any of the stores are setup to compare shaders (at all, let alone properly), and even if they were they'd have their own arbitary limits on similarity just as they do for poses.

i dont exactly know how this works. but IMO making the specular 0,2 can not be copyright.

but i guess writting some code can be copyright.

I'm not sure about that. Consider...

Do you know the famous photographer, Ken Rockwell? He is like a Bagginsbill - always reviewing and researching and explaining everything.

One thing he does for every lens is he posts what values to use to compensate for barrel or pincushion distortion - particular values to be used in Photoshop. According to him, arriving at these numbers is not easy, and the fact that he posts the number to use (just one number!) is copyrighted.

For example, on this page

http://www.kenrockwell.com/nikon/1755.htm

he says this after telling us what number to use to fix this lens's distortion:

Quote - I offer these figures as the results of lengthy research to help you get great results. Use them all you want for your photography, but this research is all copyrighted it is forbidden to make any other use without explicit permission.

According to him, I am forbidden to make any publication where I communicate the particular number +X.Y in conjunction with advising someone how to avoid barrel distortion on a particular lens.

So consider after I experiment for 1000 hours in Poser and I tell you (as I have told you) that 7 is the optimum number of AO samples to use in an AO node. You may use 7 in your work, but you must not publish this number, 7, to anybody else. It is possible that the result of some terribly difficult, expensive, and time consuming research is intellectual property. And nobody would argue if such research led to a copyrighted 100 page document, right? But what if the result of the research (remember, thousands of hours) is just one number, or a few numbers, or 30 numbers? Where do you draw the line?

Quote -

So consider after I experiment for 1000 hours in Poser and I tell you (as I have told you) that 7 is the optimum number of AO samples to use in an AO node. You may use 7 in your work, but you must not publish this number, 7, to anybody else. It is possible that the result of some terribly difficult, expensive, and time consuming research is intellectual property. And nobody would argue if such research led to a copyrighted 100 page document, right? But what if the result of the research (remember, thousands of hours) is just one number, or a few numbers, or 30 numbers? Where do you draw the line?

before i post everything else i hope you are aware that we are thankfull to you what you all did here. and if you would start selling VSS people would buy it.

but now back to the post. how can you proove that you worked 100 hours on AO? how can a setting in AO be copyright? its a number that you type in a window.
i could now say to someone hey i also worked hours and i think 7 is correct.  an example of course.

You answered my question with a new question.

Suppose I can prove it, like I have video tape of all of it.

What would you say? Is one number copyrightable if arriving at the knowledge that it is the optimal number to use is original? Meaning, before I said it, nobody knew what the optimal number was?

How many numbers (or put it another way, if we talk about a recipe) how many ingredients (nodes) and how many words with instructions how to prepare the ingredients (connections, parameter values) until the recipe is copyrightable?

I know a list of ingredients alone is not copyrightable. But how to assemble them (a recipe) is copyrightable according to the US copyright office.

But of course there are recipes nobody can copyright, like how to make a hard boiled egg or a soft boiled egg. (Same ingredients, nearly the same process, but one parameter is different) It's too simple - everybody knows it - or is it simple - is it really something everybody knows without research or teaching?

Before I showed how, nobody knew how to do gamma correction in Poser 5-7.

As far as I know, the information (the idea) that it was necessary has been around a long time.

The nodes have always been there - no great invention behind the Pow node.

But it never occured to anybody other than me to do it. Isn't that the definition of originality? Now that you've all seen it, of course it is obvious, and that's the only way to do it (Pow node). So why, then was I the ONLY person, in many thousands of man-years of people playing with Poser, to have come up with that?

Why should I not copyright the Color_Math:Pow node with Value_2 connected to 2.2 (or 1/2.2 depending on which way you're going)?

i think those are just settings in a software. i think you can not do that.

matmatic is yours. VSS is yours. paramatic is yours. you created all of this. from scratch.

You think that assembling nodes is just settings in a software?

I have run into this before and it is a very interesting question.

Did you know that the nodes represent a visual metaphor, but that the material room is a programming language, pure and simple? The nodes are built-in functions in that language, or built-in operators like +, -, *, /. So now when I write a "program" in Renderman Shading "Language", I can do it visually with nodes, or textually with RSL, or textually with matmatic which produces nodes with then produces RSL.

Is this clear? There is no difference between a "program" or "software" written in a visual or textual language that is interpreted by another software (the compiler or interpreter), just because the language is visual or textual. The Poser material room is an interpreter and a compiler.

Do you believe that software written visually is not subject to the same protection as software written textually?

Is there something intrinsically more copyrightable about 10 lines of Python code, or 10 lines of RSL, that is different than 10 nodes?

This is a very interesting subject for me, not just about shaders, but about everything.

I have a lovely trap I've been wanting to set for a while. Maybe now is the time to do it.

I believe I can prove (prove!) that one of the two following statements is true to you (not at the same time, but one of them is true)

• There is no such thing as copyrightable material of any kind.

• There is such a thing as copyrightable material, but every image ever made is a copyright violation of ever other image ever made.

Right.

Let's consider that connecting a maths add node with a 2.2 in Value_1 to the Value_1 parameter of a color_maths pow node is copyrightable. You spent a lot of time and thought coming up with that solution and so you have the right to retain copyright if-you-wish. And, that's the pivotal point, isn't it? What do you want doing with this information? You want people to start using it, of course. Use it in their materials to compensate for (5-6-7) Poser's shortcoming in order to arrive at a vastly improved render.

Am I guessing wrong, or is this what you want to see happen?

It's about intent. This entire exercise is about compensating for a software shortcoming. Adding this feature to material for Poser Pro won't make renders better... it will muck them up. Daz Studio doesn't have this issue (to my knowledge) and besides: they can't use Poser nodes. So, this effort is targeted at a specific subgroup: Poser 5-6-7 users.

Now, going into the material room and adding some nodes so that my version of Poser 7 sees a material properly is not a problem. I can do whatever the heck I want to do with my stuff, even if I bought it from someone else. No one needs to know. I guess I'm too much of a Linux-mind to ever think otherwise: I'm a firm believer in the Open Source movement for exactly that reason. I purchase this piece of hardware to do something specific. Open Source software allows me to extend and refine that functionality to my needs, which the non-open source model doesn't support. Well, it does, to some degree (with apps like VBA for Excel and like that) but I'm not given the source code so I can't modify specific functions to my liking. We'll not discuss whether or not I want to or have the skill to - that's really irrelevant, here.

My question is this: is referencing an existing colourMap in a shader in a pz2 you intend to distribute copyright infringement? I know from having done work on hair (alternate hair colours) that referencing an existing transparencyMap is not an issue, but referencing a colourMap is - assuming, for instance, that all you wanted was to change some of the outer hair colour but didn't want to do anything to the skullcap.

Let's say I want to add a bunch of nodes (not GC stuff) to make some material appear different... say some flash specular stuff or whatever. I don't change the colourMaps or anything... just add this node set. What are my rights in terms of distributing this enhanced version? Is it up to the individual original vendor to decide whether they approve of this happening to their stuff or is there a guideline that governs what may be distributed?

Whilst I'm a firm believer in OS, I also want to protect the rights of those who have spent so much time and effort on a product, and whose livelihood depends on that product selling. I know, this sounds contradictory, but it isn't. My focus - as I said at the outset - is: what is the intent of the developer / originator / artist? I've given out heaps of freebies... all I ask is that no claim is made as to originatorship (if that's a word). I've also sold software (written in FoxPro) and had people share it around and even have the audacity to ring me up for support.
I do see some potential pitfalls in sharing material sets, however. Let's say I buy Hongyu's Jersey dress. I GC all the materials and wow, what a difference. Then, I buy a texture add-on for the Jersey dress. Well, heck, I'll go ahead and GC all those materials as well. Now, being of a generous nature, I want to share this all with other artists.

Oops. Do I need to go one? The texture add-ons (gamma-corrected) are a product on their own. They are a bunch of pz2 files: no obj or cr2 or anything. So, what is to keep people from waiting until someone buys a copy of the texture add-on, GCs it, and shares it? That poor artist that made the original texture add-on loses out.

So, what do we do? Is this a valid concept (based on this scenario) to share this sort of thing? I don't think so...

Of course, referencing those colourMaps won't do any good unless you already have those colourMaps...

Quote - Let's consider that connecting a maths add node with a 2.2 in Value_1 to the Value_1 parameter of a color_maths pow node is copyrightable.

Oops, meant to say "to the Value_2 parameter of a color_maths pow node" ... only just having my first cuppa... is that an excuse?

I'm following all this with passive interest (I mainly use PPro), though I would be interested in a generic "inject-GC-into-this-shader" product, if such a thing could be made.

But I would like, if I may, to ask a question about the following text that you (RV) posted a page or two back:-

Quote - .... I *don't change the colour in that channel to white, but attach a math_Functions add node to the diffuse_Value channel which adds 0 + 0, thus rendering that node group ineffectual for the renderer (a BagginsBill trick - see, I am learning some things, Bill!).

By "ineffectual", do you just mean it will give a zero result? Or do you mean that using a math node zero plugged into the value channel will cause the internal node calculations to be skipped; whereas simply setting the value to zero, or the colour to black, will not?

Also:

On the subject of providing GC versions of shaders in commercial products, surely there would never be any need to distribute modified shaders. All that's required is the Python script to modify them to include the GC nodes.

Even if some product shaders are too complicated to have GC injected by a 'generic' GC injector script, a specific injector script for these shaders could be written by someone who has the product and can see the node structure and names. 

To take this one stage further, a single injector script could GC a complete texture set for an outfit, or whatever parts of it are actually being used.

No?

Quote - This is a very interesting subject for me, not just about shaders, but about everything.

I have a lovely trap I've been wanting to set for a while. Maybe now is the time to do it.

I believe I can prove (prove!) that one of the two following statements is true to you (not at the same time, but one of them is true)

• There is no such thing as copyrightable material of any kind.

• There is such a thing as copyrightable material, but every image ever made is a copyright violation of ever other image ever made.

gets popcorn

Quote - I have a lovely trap I've been wanting to set for a while. Maybe now is the time to do it.

I believe I can prove (prove!) that one of the two following statements is true to you (not at the same time, but one of them is true)

• There is no such thing as copyrightable material of any kind.

• There is such a thing as copyrightable material, but every image ever made is a copyright violation of ever other image ever made.

Nice try but no cigar.
Copyright is to protect original expression in tangible form, there can't be a violation even if two expressions are exactly the same provided they were created independantly.

====

Onto the lens number case :-
Whether or not the number is copyright (seems very unlikely), if the number for any particular lens is available from his website, then I'd imagine that pretty much everybody would link to the information rather than quoting the number directly purely out of respect for the effort taken to obtain it and a desire that he'll continue to collect and provide future information.

If the method of obtaining the number was patented (i.e. you'd need a license to get the number from first principles yourself) the number generated wouldn't have any special protection.

Even if the method was truely a trade secret, the number would only also be a trade secret if there was some agreement (explicit or implicit) that you would treat it as such.
Copyright is the wrong branch of IP for this.

The place where copyright may be applicable (in some juristrictions) is for the whole collection.
An analogous situation would be that no single phone number is copyrightable, but phone books are.

Quote - Even if some product shaders are too complicated to have GC injected by a 'generic' GC injector script ...

I suspect that an algorithm could be devised to deal with any shader because they aren't true networks (they're acyclic) so it must be possible to work out where the sources are (the sinks are the inputs on the PoserSurface node) and so you'd be able to assign a GC/non-GC state to every edge, and that would tell you where you'd need to insert GC or anti-GC.

Quote - By "ineffectual", do you just mean it will give a zero result? Or do you mean that using a math node zero plugged into the value channel will cause the internal node calculations to be skipped; whereas simply setting the value to zero, or the colour to black, will not?

I'll give you my understanding. Then Bill can give you the real reason.

My understanding is that plugging in a maths node that does nothing tells that channel to send no information to the renderer.
That channel still has information that it sends to 'preview-mode' so it will continue displaying whatever colour is in that channel or whatever colourMap may be attached to it.

Can't for the life of me sort out how BB figures these things out. No wonder he's so focused on maths as a solution: it IS!
Consider 0 + 0 = 0. This does nothing.
Well, to my mind it does something - it is adding, which to me is an activity, but you could also see it as "put +0 together with +0 and what do you get?
And then there's the whole equation operator.
Now, to my knowledge there's no such thing as plus or minus 0... zero is zero

Anyway, adding zero to itself is achieving nothing.

You can see why I suck at maths: I over-analyse it! So, the activity of "do nothing" might be telling that channel to "send nothing".

K, I give up. Next witness...

The value inputs multiply the corresponding colour input and pass that value on to the next section of the PoserSurface internals when rendering.
There is some "magic" associated with the Diffuse input for the preview in that it will pass through texture colour even when the Diffuse_value is set to 0.0

Quote - Now, to my knowledge there's no such thing as plus or minus 0... zero is zero

The concept of signed zeros does exist in the "One's complement" system (-> http://en.wikipedia.org/wiki/Signed_number_representations#Ones.27_complement).

Quote - The value inputs multiply the corresponding colour input and pass that value on to the next section of the PoserSurface internals when rendering.

Oh, and so since 0 * whatever_value = 0, no information is passed. I follow you.

Come to think of it, I'm kinda remembering BagginsBill explain it in a similar way... having grey moments these days. Looooooooooong grey moments.

I no longer remember if/why I did the Diffuse_Value = Add(0). It may have even been a behavior of a version of Poser which doesn't exist anymore, because of service releases.

My belief system at the time was this:

Rendering uses all the nodes, and all the math you can build. For rendering purposes, all of the following are the same. (Note: <-- denotes plugging in a node.)

Diffuse_Value = 0
Diffuse_Value = 1 <-- Add(0, 0) # Math:Add node plugged in here, aka 1 * (0 + 0)
Diffuse_Value = 1 <-- Mul(1, 0) # Math:Mul node here, aka 1 * (1 * 0)
Diffuse_Value = 0 <-- Add(x, y) # Note - any value of x, y here would still result in 0, because 0 * (x + y) = 0

Now we can certainly see that all of these would completely disable the built-in Diffuse node in the PoserSurface.

But, what does preview do? It seems to ignore a lot of nodes and connections. I'm not sure, but I have a recollection that it would honor the simple DIffuse_Value = 0 in at least one version of Poser, resulting in a black preview. But it did not "understand" 1 * (0 + 0) as being black, instead it saw that as 1 * <<something I'm too stupid to figure out so I'll just assume it's 1>>, which resulted in a nice bright colored preview image.

Lately I've been just setting Diffuse_Value = 0 because nobody seems to tell me that their NVidia GTXFROMBULOUS90000 board (which I don't have) shows my shaders as black in preview. At one time, they did, and that's when I did the stupid 1 * (0 + 0) trick, because apparently that kind of "complexity" didn't end up in the preview calculation.

RV,

You've spoken of the issue of referencing color maps. I'm not following you. What is your question?

Are you asking if it's ok to include the name of a 3rd party color map in your shader? If so, I'm telling you that I'm sure it is ok.

If you're asking if it's ok to re-distribute said color map, (modified or not) I'm telling you that I'm sure it is not ok.

Either way, there's no question, in my mind, yet you bring that up, so I'm confused.

Quote - Nice try but no cigar.
Copyright is to protect original expression in tangible form, there can't be a violation even if two expressions are exactly the same provided they were created independantly.

But what made you think I was referrring to expressions that are exactly the same? Quite the contrary, I'm referring to expressions that are completely unalike.

It has to do with the provision that gives the copyright holder control of the creation of derivative works. Within the concept of derivative work lies the trap.

And, by the way, the concept of derivative work is incredibly important here; person X taking a shader (normally for sale as part of a larger body of work) by person Y, changing it (adding GC), and distributing this new version.

In summary, person X acquires the work of person Y legally, extracts a subset (copying), alters that subset (deriving), and distributes that subset (more copying of the original subset).

I believe that some people will agree that this is copyright infringement.

Others will agree that it is not.

Regardless of which point of view you take, the entire house of cards falls down.

I know this must seem like a huge backward step -- Bill and everyone else is going to be shaking their heads and going: "Hey, we've gone OVER all this already!!" -- but for those of us (might just be me, actually) who are (unfortunately still) node dummies and who are a bit thick besides, a bit of review.

Come to think of it, critical review. I wouldn't have said what I said in that earlier post about not understanding how plugging a maths add node that added 0 to 0 (resulting in 0) would send "do nothing" to the renderer if this concept were firmly entrenched.

"Plug into a channel" is the same as "multiplication".
So:
plugging any output with a value of 0 into an input channel is going to be multiplying the value in that input channel by 0.

So, adding colours (since that's something I'm wanting to do) needs to be done in a color_Math Add node... then you can plug the result into a blender and then into your GC thingie... no wait. You should GC your colours first.

Right.
Then, add (or whatever you want to do with) those colours.
Thus:

What this is saying is:
Up the value of each colour in the Value_1 channel by the power of (the value_2 channel * 2.2 = 2.2)
Add colour (Value_1 * the output of color_math) to colour (Value_2 * the output of color_math_2)

The clamp - not sure if I'm using it properly - is to prevent making a hyper-colour. I find it interesting that the colour doesn't look any different in the "clamp" output screen... Poser must already do some sort of clamping because it can't display a hyper-colour, which is definitely what this would have been:
(.619 , 0 , .494) + (1 , .235 , .153) = (1.619 , .235 , .647)

So, question. What is clamp doing? Looking at each element of the tuple and deciding which one needs to be kept from going over the limit? Well, no. Tried that. Didn't give me that colour above:
1.619 chopped down to 1 -> 255
.235 -> 60
.647 -> 165

So, I did something that taxed not only my maths abilities to the stretching point, but those of the rest of the household: I decided I'd determine what percent of 1.619 1.000 was, and reduce the other colour values by the same percentage (61.7665). So:
61.7665 percent of 1.619 = 1 (roughly) or 255
61.7665 percent of .235 = .145 or (roughly) 37
61.7665 percent of .647 = ..3996 or (roughly) 101

I think it's safe to assume that "clamp" is going to be doing far more accurate maths than I am - heck, anyone in the solar system is going to be doing more accurate maths than I do - so that might account for the slight difference in colour.

Something this little exercise has brought to light: the colour from the colour picker is not the same as the colour in the preview window after the exponential maths have been applied. Which makes me want to revise my shader a bit - I'm not displaying that preview window on those color_math pow nodes where users will potentially be selecting colours for makeup.... hmmmmm.

Adding colours and invoking "clamp" is not the same as blending them:

Needs to be noted this is just a first part of the colour process .... gamma (back to sRGB) isn't displayed here.

Quote - RV,

You've spoken of the issue of referencing color maps. I'm not following you. What is your question?
Are you asking if it's ok to include the name of a 3rd party color map in your shader? If so, I'm telling you that I'm sure it is ok.
If you're asking if it's ok to re-distribute said color map, (modified or not) I'm telling you that I'm sure it is not ok.

I was basing my statement that referencing original colourMaps (not re-distributing them, but just referencing them in a pz2) was going to be an issue on what I was told whilst working on some hair-colour mods for a friend of mine, Bill. I probably misunderstood her - that wouldn't surprise me much.

So if the consensus is that referencing existing colourMaps - ones that one assumes exist, but since all one is distributing is a pz2, they would never be part of the package - shouldn't be a problem, then I see no further obstacles to sharing GCed material shaders, either as pz2 files or as mt5 / mt6 files.

Sound right?

Quote - It has to do with the provision that gives the copyright holder control of the creation of derivative works. Within the concept of derivative work lies the trap.

There is no trap in derivatives (made with or without permission).
Derivation creates a nesting of copyright, the really tricky bit is how you determine if derivation has occured rather than original creation.
The trap is that for some defences against an accusation of copyright violation you have to admit to copying/derivation e.g. fair use, that the use is sufficiently transformitive, or that the copied/changed elements aren't copyrightable, whereas competing claims of original creation will be decided by a number of factors e.g. documention of creation, likelyhood of the similarity in the two creations but only after a determination of what elements are actually protectable by copyright has been made.

How can you claim there is no trap, when I haven't told you what it is yet?  I only told you where it is.

Let me ask you this:

Do you believe images are copyrightable? If not we can stop now and the system is dead.

OK so you do, right?

Now is it a copyright violation to:

• Crop the image and re-distribute?

• Reduce the image size and re-distribute?

You may say "it depends" on how much you crop or reduce, right? OK then:

Given a 1000x1000 image, please identify:

Cropping / resizing to 500x500 - violation?
Cropping / resizing to 250x250 - violation?
Cropping / resizing to 100x100 - violation?
Cropping / resizing to 10x10 - violation?
Cropping / resizing to 1 x 1 - violation?

I'm starting to hint at the trap.

Somebody surely is going to agree that cropping an image to 1x1 (one pixel of the original) is no longer a violation, right? But that 1x1 pixel was not created originally, it is a copy of the original work. So it must be a violation, by definition, right because it is illegal to re-distribute even a subset of a copyrighted work. Or is it ok as long as the provenance of the subset is no longer recognizable?

In which case we can assume, what a 3x3, 5x5 - what is the largest unit that is not copyrightable? How much of a work must be present in its original form to be considered copyright violation?

This is still not the trap, but I'm trying to get you to think about things a certain way. If you refuse to think about thing this way, well then you'll never be convinced of the trap.

As subjective as this might appear as an answer: I'll propose this.

If the originator of an image cannot recognise the image as a derivative of his work, then the image falls out of the realm of copyright. The originator of the image will not lay claim to the image as being a derivative of his work, and so copyright becomes moot.

No?

I probably shouldn't be going so OT here. We can/should discuss the implications of copying somebody's shader, for the purpose of improving it (a derivative work), elsewhere.

RV:

Your big post above about the GC and Clamp and such.

Clamp is simple: Clamp(x) = x, but no less than 0 and no more than 1.

And despite what you said/deduced/calculated, it does that on each element of the tuple.

You skipped a bunch of steps so I have to study what you did to arrive at your conclusion. You wrote a lot in one post which makes it really hard to dissect.

I'll dissect it.

Quote - The clamp - not sure if I'm using it properly - is to prevent making a hyper-colour.

Clamp will surely prevent a color from being hyper (or hypo), by definition. However, it is a destructive operation in this case, and may not be what you intended. You are changing the ratio of the red to green to blue, which means you're changing the color, not simply choosing a darker normal version of a hyper color. Consider the color RGB 65535, 255, 255 - that's pretty much red. If you Clamp it you get RGB 255, 255, 255 which is the brightest normal shade of gray, aka white. Clamping a hyper red and getting white is probably not what you intend.

Quote - I find it interesting that the colour doesn't look any different in the "clamp" output screen... Poser must already do some sort of clamping because it can't display a hyper-colour, which is definitely what this would have been:
(.619 , 0 , .494) + (1 , .235 , .153) = (1.619 , .235 , .647)

Right here you went berserk. So many things wrong and untested. Let me try to correct all of this.

I'm trying to sample your screen shots to find what color you really have there, but you JPEG'd them so bad I can't get a consistent color.  So I'll assume the first one was .619, 0, .494, and your second one was 1, .235, .153 just as you say. (Although I can't find any pixel that is exactly those values.)

Now look at what you wrote earlier (which is correct):

Quote - What this is saying is:
Up the value of each colour in the Value_1 channel by the power of (the value_2 channel * 2.2 = 2.2)
Add colour (Value_1 * the output of color_math) to colour (Value_2 * the output of color_math_2)

But then you wrote this:

Quote - (.619 , 0 , .494) + (1 , .235 , .153) = (1.619 , .235 , .647)

That's wrong. You just established that what is being added is the anti-gamma corrected version of these colors, not these actual colors, i.e. these colors to the power 2.2. You didn't raise these to the power 2.2 before writing out the math for the add.

So here's what the Add is adding:

(.348, 0, .212) + (1, .041, .016) = (1.348, .041, .228)

If you Clamp that you get (1, .041, .228) and that is the color showing in the preview of your Clamp node.

As for the claim that Poser clamps the preview colors, that's probably true, but I have not done enough testing to prove it to my satisfaction. It may be true, but we can only wonder, unless we do a lot more tests.

I raise this point because I have observed a difference in rendering of hyper-colors between a node parameter and a node output preview. I have seen the parameter (such as Value_1) contain a hyper color (created via matmatic) and it did NOT show a clamped version of that color. It showed what I believe to be a Modulus version of that color.