Channel plugin doesn't work for Bump

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 10/04/2003 at 15:25, xxxxxxxx wrote:

User Information:
Cinema 4D Version:   8.100 
Platform:      Mac OSX  ; 
Language(s) :   C.O.F.F.E.E  ;

---------
Hi,

probably a very stupid thing... I wrote a simple ChannelPlugin using COFFEE. The plugin works fine for color, displacement, etc...

However, it doesn't work for the bump channel - which is a bit sad, as this is exactly it's intentional use   ;-)

I have not overloded GetInfo(), do I have to? My impression was that a simple shader is considered to deliver a bump color...

Any hints are as always apreciated!

Thanks

Kabe

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 10/04/2003 at 20:27, xxxxxxxx wrote:

Only works if it is based upon UV.

If your plugin is based on the cd->vd->p, the normal, or anything else besides UV you have to us the direct bump flag or create your own sampling system ( this took some serious time for SLA, it was oh so fun ). It is possible, just takes effort. If you tell us what your plugin is doing maybe we can help.

bt

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 10/04/2003 at 22:06, xxxxxxxx wrote:

Actually it is based on vd->uvw:

<CODE>MyShader::Output(settings,rd,p,n,d,t,texflag,vd)
{
     var x=vd->uvw.x;
     var y=vd->uvw.y;

// [...]
// some calculations to get m out of x and y...

return vector(m);
}
<CODE>

The main purpose is to create certain kinds of continuous gradients which should be used in the bump channel to affect reflection.

The curious thing is that the shader works exactly as intented if used in the displace channel [on the very same material on the same object].

However, I just discovered that if I use the picture created by the shader output is also not working as expected (just numerical artifacts showing up).

Rethinking about how bump is working it looks like giving back a color vector is generally not suitable for the kind of relatively slow change of values that are produced by the underlying algorithm.

If anybody has further insight, just let me know ;-)
Thanks anyway!

Kabe

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 11/04/2003 at 08:49, xxxxxxxx wrote:

Sorry, I don;t do COFFEE. To me 'cd' is channel and 'vd' is volume data.

I am guessing here but I think the 'p' variable is what you want to use if you are intending to use uv. UVW is a completely different creature. Try 'p' for the hell of it. See what you get. I am speculating again but I would say 'p.x' == u and 'p.y' == v ( 'p.z' would surely be zero all the time ). Again I am only speculating as I have not written and COFFEE in over three years.

Good Luck...
bt

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 11/04/2003 at 11:52, xxxxxxxx wrote:

This gets scary...

First thanks a million, you were right... using p.x, p.y works!

However, I'm still trying to close a mind gap here...

I just changed the input... and both of the inputs (vd->uvw.x and p.x) do provide similar or even the same data so that the calculated outout look exactly the same when used in another channel like ie. color.

So obviously vd->uvw.x does provide data which were no bogus...

Are there any side effects using p.x instead? What exactly is that projected point p? and what's the difference between p.x and uvw.x, provided that the body uses UVW mapping?

Again thanks for your help!

Kabe

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 11/04/2003 at 12:18, xxxxxxxx wrote:

UVW is mainly for volume shaders, afaik.