Pie Filter - Bug Fix!

[bigben]

It sounds interesting, because it can be done, but I'm not sure what I would use it for though. I currently use a split spherical limit and flat pie slice.  I'm sure if you made it someone would find a use for it one day... or you may want to hold off until the node network allows the creation of "macros" which will simplify the layout process.

[Harvey Birdman]

Ah, skip it then. Unless someone really wants it I won't bother. The pie filter was the one I really needed myself.

[mogn]

Harvey, I have now studied your pie filter.

IMO the conditional shader should be avoided if possible. (Thats a general statement for all programming languages"

So I have tried to tidy up your filter, even if I have only saved 5 nodes, (27 nodes against 32 nodes)
I think that the flow is much easier to follow and understand.
The only functional difference, is that in my filter, you must specify a
direction 45 degrees less to reach the same result.

A thing that bothers me is that I miss a convert node from the range -1..1 to 0..1
this implementation uses 4 nodes to do that.

[Harvey Birdman]

-

[Harvey Birdman]

-

[mogn]

Easy to beat: Scalar to colour is redundant 

My reason to object conditionals are that the mind must follow more threads to deciffer a conditional.

E.g it is easier to understand:

   x = 1;
   if (condition) x = 2;

than:

   if (condition)
   {
      x = 2;
   }
   else
   {
      x = 1;
   }

Or using a modern stupid standard;

   if (conditional) {
   x = 2;
   }
   else {
   x = 1;
   }

In the same sense the replacement for x+1: comp(neg(x))
is easier to deciffer than add(x,scalar(1))

Reason: same number off nodes but one connection less to confuse the network.


I think that the vector I use instead of [sin,cos] is [cos + sin,cos - sin] 
   

[Harvey Birdman]

-

[mogn]

Well I was present, but I am modest. I have been programming for 44 years. 

Your are of couse correct in pointing out my errors. That just me im not testing enough!

I will get back when I manage a better demostration of the virtues of 'linear threads' programming.

[mogn]

The most agraving error I did was not full understanding your filter.
So now a new a trial. 

[Harvey Birdman]

Dude.... get a life. You've already made a complete ass of yourself in this thread. Why don't you try making some contribution of your own instead of getting hung up on trying to show me up?

[jo]

Hi mogn,

My reason to object conditionals are that the mind must follow more threads to deciffer a conditional.

E.g it is easier to understand:

   x = 1;
   if (condition) x = 2;

That's how the Conditional scalar node works, if you don't provide an else value.

than:

   if (condition)
   {
      x = 2;
   }
   else
   {
      x = 1;
   }

You don't have to do that with the Conditional scalar node.

If you simply talking about stylistic things in programming languages, I really dislike this form :

x = 1;
if (condition) x = 2;

for two reasons. One is that it becomes inconsistent, you end up having two conditional clauses which look different, one with brackets and one without, which makes the code harder to scan. Second, you can't set a break point on the statement so that the breakpoint only gets hit when the conditional is met. Matt does things like that all the time, and it drives me nuts :-).

I much prefer this form :

x = 1;
if (condition)
{
    x = 2;
}

for consistency and ease of debugging.

There is a good reason to avoid conditionals in node networks if you can, and that is because conditionals introduce discontinuities ( i.e. hard edges/transitions ) which the renderer doesn't like, it causes aliasing and jagged edges. This is only really an issue in logic which makes things visible. It is often better to use a smoothly interpolated transition area between areas of two different values. A future version ( next alpha release, anyway ) will have a smoothstep function to make this easier. That isn't to say that conditionals aren't very useful, because they are :-).

Regards,

Jo