Minor things

Started by mogn, June 17, 2007, 02:21:54 AM

Previous topic - Next topic

mogn

IMO you have too many shaders in the functional group: (don't end up like blender with an impossible UI)
Since vectors and colours are handle in the same way, there are no need to have to have two groups of shaders.
In general scalars, vectors, and colours should be handled in a general way:
Only one add shader.
Only one subtract shader.
Only one divide shader
Only 3 multiply shaders.
E.t.c

If you keep both muliply colour, and multiply vector, they should be handled differently, e.g.
if you multiply a colour with a negative scalar, the result shoul be clamped to zero.
Negative colours make no sense.
In this way you eliminate the abs colour shader.
The abs colour shader and clamp 0 colour shader is the same.

The clamp01 vector shader is missing.

In the documentation, it is mentioned the a disabled shader works like a walk through.
This is not the case for a constant shader, whisch works like a constant shader, wheter it is enabled or not.

A walk through (scalar, colour or vector) is useful for test purposed, and distibuting nodes for simplyfying networks.

The drop down list when you assign a shader, gives difficlties when it contains more shaders than can be shown on one page.
It should be broken up in level for better handling.

Apart from this (and the missing support for internal networks) I love the functional network in TG2.  8)

I forgot to ask: what does the step function do?

bigben


mogn

Thank You  8) very useful.

Volker Harun

The simplified nodes could have triple I/O - for scalar, vector, colour. And/or they could be toggled inside the node (convert yes/no).

Negative colours are fun. I am thinking of Bryce's negative lights for darkening certain areas. And the output of a negative colour does not mean that it does not have sense for further calculations ,-)

Volker

Matt

#4
Hi mogn,

I considered different approaches. The current approach was chosen because the internal implementation is simple enough that calculation speed is fairly efficient and creation of new functions is straightforward for the software developer (including users of the SDK when it is released in the future). Also, the current naming convention tries to make it clear what type of output each function has (in most cases this is denoted by the last word in the function name). At this time I don't know of a way that I could allow 'intelligent' selection of output type without affecting speed, and the alternative of using multiple outputs does not fit well with the overall design of the node system as it currently works (although we may need to support multiple outputs in other nodes eventually). Despite potential clutter, it does work fairly well as designed, and although it may be reevaluated in the future this seemed like the best compromise for now. There are other factors, but the current system developed naturally from the earlier shader network.

It may be possible to merge colours and vectors into a single set of functions because, as you say, they operate the same way. However, since this is not possible with scalars and I chose to put the datatype into the name of almost every function, for consistency and clarity I thought it would be best to separate every type. Some users may not know that vectors and colours are represented by the same internal data, so there are clearly named conversion functions even though in many cases they are not needed.

There are some suggestions that I would strongly disagree with, such as clamping of colours. Negative colours are often important as intermediate values in a complex function even if the final result should be clamped, and sometimes negative colours are actually desirable. Clamp functions exist should you need them.

Matt
Just because milk is white doesn't mean that clouds are made of milk.

mogn

Thanks for your responce. As a matter colour nodes and vector nodes can be freely interchanged,
e.g the missing complement vector can be replaced with a complement colour.
Like wise the missing clamp 0 vector, can be replaced by clamp 0 colour.

mogn

Normally I do not want more different shaders, but the following 3 shaders would simplify the node network:

1)  dec(x) == x - 1
2)  inc(x)  == x + 1
3)  adj(x)  == inc(x)/2   (converting the range -1..1 to 0..1

mogn

#7
Quote from: mogn on July 07, 2007, 02:40:31 AM
Normally I do not want more different shaders, but the following 3 shaders would simplify the node network:

1)  dec(x) == x - 1
2)  inc(x)  == x + 1
3)  adj(x)  == inc(x)/2   (converting the range -1..1 to 0..1

Thanks for the new tg4 functions, which can be used to implement a one node tgc of above functions.
E.g  adj(x) = "Add multiply scalar"(0.5, x)

Matt

I hadn't thought of using Add Multiplied Scalar for remapping ranges like that. Thanks for the tip (and .tgc).

Matt
Just because milk is white doesn't mean that clouds are made of milk.