Nodes and values ideas, questions
Posted: Wed Jul 28, 2010 3:54 pm
Hello I was just wondering if the Octane team is planning on adding a few things to the node tool set. Here are some additions or ideas I'd like to see implemented.
First would be some basic math nodes (add, sub, multiply).
Maybe the ability to input values above one? I find sometimes the internal idea of what "one" is is not enough, so it would be nice to go over that value.
This is a big one- the orientation of the nodes. Really right now it's more like shake/nuke, which is fine for compositing, but this really limits seeing the names of nodes etc. Personally I GREATLY prefer the industry standard for render engines where it is mainly a left to right affair (mental ray, LW, Houdini, messiah etc.), with names and nodes exposed as needed. Preferably there are not just many input value entries exposed, but also output.
The node triangles and circles should have more variation in shape AND be VASTLY different colors. It's nice to have a great looking interface, but the contrast is SO weak on these inputs it makes things more difficult than need be. Don't be afraid to sling in some cyans, magentas, pinks, garish yellows etc. They may not look swank, but they make it easier for people to quickly see what is what on a node (is it an integer, scalar, or color value etc.) esp. if you're not going to have names exposed too.
The ability to drag or right click on existing node connections to add a node would be very helpful.
An over view node window navigator would be esp. helpful. Softimage's render tree has one, there are such options in Fusion etc. this makes zooming around complex trees more easy.
Auto PAUSE render on node interaction would be helpful so that the preview only updates or resumes rendering AFTER you've made a connection. This would improve responsiveness for people on workstations with one card.
Preview shader balls on a per node, up to that part of the tree basis, preferably with customizable preview object and BG image/texture.
A raytype node to limit what part of the engine sees what on a material, which might improve certain rendering tasks.
A gradient mixer node would be helpful.
Compound node groups with ability to customize exposed inputs and outputs would be helpful. This would especially help when distributing complex node sets to other people less adept at understanding or working with nodal texturing etc.
Ability to override how Octane now makes the node up the tree say what the input is down the tree. I understand why you are doing this, but it IMHO, is only to compensate for a design flaw. I would like to be able to have the node keep its original name AND even better, let us also input a customized name.
Ability to read scalar weight values if supported by an exporter. Weight maps are really helpful to getting the full power out of procedural texturing and many node applications IMHO. Maybe the ability to read FBX or collada files, or some format that supports weights and is fairly universal? Once this is implemented, it could be a scalar node input that we could set to the weight name.
Thank You!
First would be some basic math nodes (add, sub, multiply).
Maybe the ability to input values above one? I find sometimes the internal idea of what "one" is is not enough, so it would be nice to go over that value.
This is a big one- the orientation of the nodes. Really right now it's more like shake/nuke, which is fine for compositing, but this really limits seeing the names of nodes etc. Personally I GREATLY prefer the industry standard for render engines where it is mainly a left to right affair (mental ray, LW, Houdini, messiah etc.), with names and nodes exposed as needed. Preferably there are not just many input value entries exposed, but also output.
The node triangles and circles should have more variation in shape AND be VASTLY different colors. It's nice to have a great looking interface, but the contrast is SO weak on these inputs it makes things more difficult than need be. Don't be afraid to sling in some cyans, magentas, pinks, garish yellows etc. They may not look swank, but they make it easier for people to quickly see what is what on a node (is it an integer, scalar, or color value etc.) esp. if you're not going to have names exposed too.
The ability to drag or right click on existing node connections to add a node would be very helpful.
An over view node window navigator would be esp. helpful. Softimage's render tree has one, there are such options in Fusion etc. this makes zooming around complex trees more easy.
Auto PAUSE render on node interaction would be helpful so that the preview only updates or resumes rendering AFTER you've made a connection. This would improve responsiveness for people on workstations with one card.
Preview shader balls on a per node, up to that part of the tree basis, preferably with customizable preview object and BG image/texture.
A raytype node to limit what part of the engine sees what on a material, which might improve certain rendering tasks.
A gradient mixer node would be helpful.
Compound node groups with ability to customize exposed inputs and outputs would be helpful. This would especially help when distributing complex node sets to other people less adept at understanding or working with nodal texturing etc.
Ability to override how Octane now makes the node up the tree say what the input is down the tree. I understand why you are doing this, but it IMHO, is only to compensate for a design flaw. I would like to be able to have the node keep its original name AND even better, let us also input a customized name.
Ability to read scalar weight values if supported by an exporter. Weight maps are really helpful to getting the full power out of procedural texturing and many node applications IMHO. Maybe the ability to read FBX or collada files, or some format that supports weights and is fairly universal? Once this is implemented, it could be a scalar node input that we could set to the weight name.
Thank You!