-
thats one hell of a complex node network.....holy cow!!!!...all this for what...a quarter of the circle.....
-
can we sue this to make asteroid belts??/...just a thought!
Looks very useful, Thanks a load :)
Richard
-
I've been writing a program to create asteroid belts, though it is really an illusion since the way I'm doing it would bog down most computers. I'm using only 1 or 2 degrees of an arc.
Not sure how this would work with asteroid belts.
Quote from: dhavalmistry on September 09, 2007, 11:52:22 AM
can we sue this to make asteroid belts??/...just a thought!
Harvey, thanks. This looks useful and is going in my library.
This is incredibly useful for me.
Thankyou very much Harvey... 8);D
-
Hi Harvey
A feature that will enable node values to be linked is planned which will be very helpful for stuff like this. I haven't looked at this clip yet but I'll have a play later. Another thing you can use this for is to drive a wedge through the cloud fractal out of frame and towards the sun. That would let you place a slit of sunlight across the terrain exactly where you want it while having a densely clouded sky.
Is the distance limit spherical or circular? (or selectable?... there are different uses for both)
Hi, BB -
re cloud manipulation - that's a neat idea! I hadn't thought of that.
Distance is circular. I'd actually set it up for spherical initially and then decided that wasn't what I wanted. I don't know about making it selectable - you might end up with a bunch of unnecessary trig operations going on. I'll put together a separate spherical one.
I use spherical for objects mainly to allow for higher camera positions, but circular also has a lot of uses. Separate versions might be just as practical and avoid clutter.
Very nice, I love the node network ;D
Thank you, thank you. :D I actually spent more time tweaking the node locations than I did creating the network.
;D
Hey, Ben - re spherical filter: How does this sound for inputs/control values: CenterX, CenterY and CenterZ, Inner and Outer Radius, and then Theta Direction, Theta Span, Phi Direction and Phi Span. I'm thinking of providing scalar inputs to control angular coverage instead of using a color adjuster(s) at the output. That control set would allow you to define a frustum.
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.
Ah, skip it then. Unless someone really wants it I won't bother. The pie filter was the one I really needed myself.
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.
-
-
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] >:(
-
Well I was present, but I am modest. I have been programming for 44 years. :D
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.
The most agraving error I did was not full understanding your filter. >:(
So now a new a trial. ???
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?
::)
Hi mogn,
Quote from: mogn on September 12, 2007, 02:57:11 AM
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.
Quote
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