PDA

View Full Version : I hate the Node Editor



lazyanimator
05-04-2012, 07:40 AM
I'll be honest and accept that I am opening myself up to abuse but frankly - The node editor is fking rediculous. There I've said it!

I appreciate its flexibility and power and thats great, it really is, but it reminds me both literally and metaphorically of the early synthesizers of the late 70's, early 80's. Plug this into that, turn this up, that down and those half up and you'll get a sound, as long as you have an engineering degree that is! Yes, I know its not quite the same is it. I know its great and reasonably simple to add a material or a gradient or any of the basics, but I could more or less do that in the standard materials editor. Like the musicians or the 70's and 80's I am an artist first and a technician second (or third or forth) I appreciate you have to put a bit of work in to get results and some of that is technical. It cant all be artistic and fun all the time. But surely we want these processes to be simple dont we? So we can get on with the actual job of creating stuff? If I were a pilot I would want the plane to take off when i pulled that lever, I wouldnt want to have to go and plug all the bits in first (neither would my passengers I would wager!). Am I over reacting a little? Well yes, probably! But for me at least, the future of cgi in this digital age is to refine the process of creation by making ball aching things less so! I dont mind tweaking, but I for one dont want to have to spend a day trying to reprogram nodes in order to get the correct settings.

I am sure all this has been covered before, but I needed to rant. Now, there, see, I feel better.

Going for a lay down,

LA.

Nangleator
05-04-2012, 07:44 AM
If it was easy, they wouldn't pay us for it.

Wait. They hardly pay anything now. Something's wrong with that line of thought...

RebelHill
05-04-2012, 07:52 AM
So... Dont use it if thats how you feel.

The point of the node editor is that it allows you to BUILD things... Even if you COULD package all those possibilities into some "artist friendly" interface... it would have to have MILLIONS of options to account for all the possible variety.

Would that be easier??

But there's a LOT of artistic concepts that can be applied to nodal working, you've just gotta think in terms of an expanded artistic vocabulary.

http://www.youtube.com/watch?v=nGKwqL89LaA

3DGFXStudios
05-04-2012, 07:58 AM
And you're from Oxford? Huh? ;)

lazyanimator
05-04-2012, 08:03 AM
Didnt think it would take long lol.

The node editor is far too complicated. There I said it again. Fine with the functions not fine with the method of achieving those functions. I want to use it. But for me its not intuitive past a certain point and down right complex after that. And I disagree, I am certain a more user friendly system could be designed for the most part.

RebelHill
05-04-2012, 08:12 AM
You could say the same of any endeavour though... there are always more and more complex/difficult places to go... at some point everyone reaches the limits of either their capability or interest.

But if a better system COULD be made... then why hasnt one?? Why have packages been falling over themselves left right and centre in recent years to add more and more node functionality??

And again... how can you account for all the MILLIONS of possible constructs available in the node editor in some other interface.

Honestly... bash away at the node editor all you like... but if you cant present a viable alternative that can do all the same stuff... then what else can one say but "if u dont like it, dont use it".

OnlineRender
05-04-2012, 08:27 AM
Didnt think it would take long lol.

The node editor is far too complicated. T.

I think as far as node editors go LW is pretty simplistic and powerful once you get into fusion and even blender atm its goes way more complex and fiddly ...but hey each to there own

lazyanimator
05-04-2012, 08:50 AM
3DGFXStudios - love that, that was witty retort of the day so far!

Nangleator- you are not wrong.

I accept your points rebel hill, but I wonder if there isnt a silent majority that may feel the same way? There may not be of course and it may just be me.

I have no idea how cgi software is developed, however it has always seemed to me that most software is developed by the types of people that are mathematically inclined, and the rest of us try to keep up as best we can. Its also been my experience that software has attempted to become more user friendly in order to evolve and gain in popularity. It has predominiantly done this by becoming easier to use, streamlining processes and automating them. Dont misunderstand me, I realise cg software is vast and complex in itself. I also agree that we dont need to dumb anything down. That is not what I am suggesting. I am simple saying I personally would like to use the power of the node editor in a simpler fashion. Or at least divide it up a bit.


LA.

littlewaves
05-04-2012, 08:51 AM
I've always found the node editor to be very intuitive and logical. I much prefer it to layers

For me it's very much like using electric guitar and FX pedals so I suspect that's got some bearing on why I'm more comfortable with it.

zapper1998
05-04-2012, 09:00 AM
I use the Old Surface editor.. Still

And I use the Node Also..

I do the Surface using thr Old Editor...

Create a Duplicate object and then do the same surface using the Nodes..

Thats how I have been learning the stuff, actually kinda fun.. sometimes I get a little carried away.. Node editor is pretty robust..


SShhhhhhhhh...
I printed out the manual at work on the Color Laser Printer...
SShhhhhhhhh...

Mike

RebelHill
05-04-2012, 09:02 AM
I also agree that we dont need to dumb anything down. That is not what I am suggesting. I am simple saying I personally would like to use the power of the node editor in a simpler fashion. Or at least divide it up a bit.


LA.

I know, and I get that... but what Im saying is that the node editors (as a whole) are designed to do one thing... bring the power of being able to code (aka build) your OWN solutions where none exist "pre-made". And the reason for this is that there are literally MILLIONS of different things that COULD potentially be built (coded).

So how to give access to all these HUGE number of possible tools to end users?

Either they learn how to code and build their own stuff... or you give them an interface that "simplifies" to "coding" process... and that's what node editors do... and to date, no-one has come up with a better way.

So what's the other option?? Millions of different "pre-made" shaders or deformers, or tools to choose from?? That's gonna be a long wait for any software company to make, and even longer to read up on em all and select em from a menu.

So what's the alternative??

Node editors ARE NOT trying to jsut rpesent access in a way that computery, programmy, mathy types understand things... they're an attempt to allow non mathy users access to some of the power that they're missing out on.

Is that still gonna be too complex for some folk... sure... but again... whats the alternative??

Consider scratch by MIT... http://scratch.mit.edu/ a nice little interface to get 10 year olds into the basics of programming... guess what... its NODAL.

If the fellas at MIT cant come up with a better way of getting ordinary folk access to complex programmatic concepts, what hope does anyone else have?

And again... if u watch the YT vid I posted, u can see very plainly how even seemingly "mathy" concepts actually have very basic roots behind them that are very easy to understand for an artist.

bazsa73
05-04-2012, 09:05 AM
Let's hate the world!

Captain Obvious
05-04-2012, 09:13 AM
If you don't like the node editor, then don't use it. Regular layered texturing still works fine in Lightwave, doesn't it? I don't see the problem.

Sensei
05-04-2012, 09:15 AM
I am certain a more user friendly system could be designed for the most part.

I can't imagine what can be easier to use than nodal editor..

If you have ready material, somebody have to code it first. If it'll have more than 3 controls, you will be screaming it's too complex for your brain anyway.

lazyanimator
05-04-2012, 09:17 AM
Sorry I dont understand why would one need a million shaders?

jeric_synergy
05-04-2012, 09:24 AM
I'll be honest and accept that I am opening myself up to abuse but frankly - The node editor is fking rediculous. There I've said it!

I appreciate its flexibility and power and thats great, it really is, but it reminds me both literally and metaphorically of the early synthesizers of the late 70's, early 80's. Plug this into that, turn this up, that down and those half up and you'll get a sound, as long as you have an engineering degree that is!
I feel your pain, my brother. :cry: :cry:

--Although, I think you meant "math degree". :D

I am congenitally confused by the node methodology (not the editor per se). Oftentimes the mind set or conceptual approach of nodal work seems backwards to me, and information seems to flow in mysterious or occult ways.

However, I blame this more on training than actual implementation. All too often nodal tutorials are trundling along and then there's a " ...and then a miracle occurs... (http://star.psy.ohio-state.edu/coglab/Miracle.html)" moment where a whole swath of explication is skipped. And of the NewTek official documentation, I maintain the prose style is so turgid and obfuscatory as to inhibit understanding. (Over and over, NewTek documentation "buries the lede", and the actual function of a feature is the very last item presented.)(If at all.)

There's also a tendency of "and use THIS totally obscure and undocumented 3rd party node to blah effing blah....". I really hate that one.

The editor per se is fine by me: I don't know how one would access all that power in a more accessible way. It's really quite remarkable.

http://star.psy.ohio-state.edu/coglab/Pictures/miracle.gif
+++

If it was easy, they wouldn't pay us for it.

Wait. They hardly pay anything now. Something's wrong with that line of thought...
That's one thing: when I look at the networks people construct that are mind-blowingly elegant and complex and truly hard to understand, and then I contemplate the sparse rewards that accrue to the holders of this knowledge, I wonder "why am I busting my balls to learn this again?"

RebelHill
05-04-2012, 09:29 AM
Sorry I dont understand why would one need a million shaders?

Its not about needing a million... its about needing a particular ONE out of millions of potential possibilities.

Only a handful can ever get pre-made... so what do you do if you need something thats not on the list of those available??

Answer..

You either go without, or you create your own... from scratch.

Cant program from scratch, then you're SOL.

Node editors are the best available method to try and bridge that gap for non coder users.

Nicolas Jordan
05-04-2012, 09:31 AM
Like some have already mentioned you don't have to use it at all. The node editor just allows users who need it or want it the ability to dig in deeper and fiddle around with complex technical surfacing networks.

I still mostly use the standard surface editor for most things but when I do use the node edit I usually just use the single material nodes since they are easy to hook up and give a good result quickly.

lazyanimator
05-04-2012, 09:37 AM
thanks jeric, I was beginning to feel all alone there for a while!

I agree and the more I think about it, the more I realise I havent made myself clear, its not nodes themselves, its the convoluted (to my mind) manner in which they rely on each that I stumble with. I will always find it difficult to use well- I fear.





LA.

-EsHrA-
05-04-2012, 09:37 AM
Let's hate the world!

large part allready does.

jeric_synergy
05-04-2012, 09:38 AM
It'd be nice if there were a market for "hand crafted networks": you log on, submit your needs and criteria, the market hooks you up with a network artisan, money changes hands, everybody's happy. Node operators get money, artists get the shaders they want without giving themselves headaches.

Very unlikely.

jeric_synergy
05-04-2012, 09:41 AM
thanks jeric, I was beginning to feel all alone there for a while!
Dood, "SpotInfo" totally confuses me.

I think it -the nodal mindset- may be one of those things like "Reverse Polish Notation"-- the greatest thing since sliced bread IF you 'get it' -- totally opaque if you don't.

Or recursive subroutine programming. Some get it, some don't.

lazyanimator
05-04-2012, 09:46 AM
just to summerise -

I realise I dont have to use it. I want to use it, but find it overly complicated. Clearly I dont actually hate the node editor, I just dont get on with it that well, kind've like my brother in law (no, only joking Nat!).

Thanks to everyone for joining in this light hearted conversation.

Sensei
05-04-2012, 09:55 AM
and information seems to flow in mysterious or occult ways.

How renderer works:

- send ray from camera to filmplane through pixel x,y
- so ray origin and ray direction are initialized
- ray flies and hits geometry
- object id (LWItemID) is known, polygon index, polygon id (LWPolID), polygon normal vector, world spot position (equal to ray origin+ray direction * ray length), ray length, weights from spot to 3 or 4 neighborhood vertices are known. They are exposed in Spot Info node. All these are available in node evaluation function.
Then the first is calculated normal vector from 3 or 4 neighborhood vertices, multiplying weights by point normal vectors (if surface smoothing is turned on, otherwise normal is just polygon normal flat vector).
- renderer is asking Node Editor to replace Normal vector (if you plugged something, it's replaced)
- renderer is asking Node Editor to replace Bump vector (if you plugged something, it's replaced)
- final normal = Normalize( normal vector - bump vector )

- renderer is checking whether Material is plugged. If so, Node Editor is asking node which is plugged to it, to evaluate. Everything else is ignored.
- otherwise if no material is present Diffuse Shading, Specular Shading, Reflection Shading, Refraction Shading are calculated.
if Diffuse Shadding is plugged, then Color, Diffuse, Diffuse Sharpness, Luminosity and Translucency are ignored.
if Specular Shading is plugged, then Specular and Glossiness are ignored.
everything what is not yet listed above and not ignored are calculated. Evaluation always goes from the root (Surface node on right side), to the left, node which have something on left inputs plugged are asking (optionally) childs to evaluate.

safetyman
05-04-2012, 09:58 AM
If we didn't have it in LW, everyone would be complaining that we needed it because Max and Maya have it. For me it's nice to know it's there in case I need it (makes adding a metal/glass/car shader a 2-step process rather that a 6-8 step process).

Danner
05-04-2012, 10:05 AM
I like your "node operator" idea Jeric. It's not as crazy as you think, I used to think I'd never buy a 3d model, since modeling is a mayor strenght of mine..

bobakabob
05-04-2012, 10:42 AM
just to summerise -

I realise I dont have to use it. I want to use it, but find it overly complicated. Clearly I dont actually hate the node editor, I just dont get on with it that well, kind've like my brother in law (no, only joking Nat!).

Thanks to everyone for joining in this light hearted conversation.

Lazyanimator,

Good thread. I used to feel the same way about Nodes but very soon got to really enjoy using them. In Lightwave it's win win as the old materials editor is really quick and straightforward. Nodes allow you even more scope for experimentation. Also now we have VPR you get instant feedback messing about with nodes. Plus there are surfaces like SSS skin generously contributed by Wavers you can download off this forum to figure out how they work.

One thing I've always loved about CGI is the fusion between art and science. I agree for those of us who aren't into maths it can be anxiety inducing but it's good to adopt the approach Brian Eno has to music which is to encourage happy accidents with stuff you half understand. Too much knowledge and technique can sometimes kill originality and inspiration so from this perspective nodes are your friend.

Your analogy of retro synths is true but I used to love the sheer quirkiness of those things... one minute you'd get an elephant fart, the next a transcendental sound that would transport you to the heights. In a busy production you can cut down experimentation and use something you know, like the materials editor.

Don't know whether you're old enough to remember the 65 in 1 Electronic Project Kit toy beloved of teenagers in the 70s but nodes have something of the childhood thrill of wiring things up, half reading the instructions, to make something happen like triggering an oscillator, making a synth, or solar powered radio.

http://www.radiomuseum.org/images/radio/radio_shack_usa/electronic_project_kit_65_in_1_256485.jpg

Batteries not included

RebelHill
05-04-2012, 10:49 AM
"SpotInfo" totally confuses me.

A point on a surface is a "spot"... there are various "infos" that you can ask about that spot... where it is in space, how near it is to other "spots", is it lit or shadowed, if lit what angle (relative to the surface) is that light ray hitting it at... etc, etc.

How can it be explained any simpler?

If I point at a "spot" on my desk (or sneaker, or wall paper), and I ask... "what colour is it... where is it... which way is it facing?"... whats not to get?

jeric_synergy
05-04-2012, 11:03 AM
I like your "node operator" idea Jeric. It's not as crazy as you think, I used to think I'd never buy a 3d model, since modeling is a mayor strenght of mine..
For a small operator, a "freelance node operator" market for the creation of bespoke node networks would be great, but there's obvious challenges:


absolute minimum payment (U$50?)
distribution rights
payment infrastructure
contention resolution

Unlike Turbosquid, these items would be totally bespoke (that's "custom" for Yanks) and created on demand. IOW, there's no shelve full of 'em.

Turbosquid probably has big chunk of the infrastructure required to make it happen. OTOH, it's one of those chicken-and-egg problems.

If Pictrix can't make enough $$ to stay afloat with his killer plugins, it's hard to see how this could be a going concern. ::sigh::

Meanwhile, network artisans can always advertise here in the Classified sections. :D

jeric_synergy
05-04-2012, 11:15 AM
If I point at a "spot" on my desk (or sneaker, or wall paper), and I ask... "what colour is it... where is it... which way is it facing?"... whats not to get?
Next time I run into a confusion example I'll try to remember to come back and address this question

To be fair, some of the confusions arise in the OTHER node editors, such as motion or displacement.

+++
(attempting to answer w/o concrete examples)
It may be that some of my confusion arises from assumptions or conventions inherit in the nodal approach. These conventions make it sometimes easier or more logical or more 'natural' to me to read the network from right to left, rather than left to right.

Whatever my issues are, it remains that a percentage of users find nodes quite confusing. Whether that percentage is great enough to stir NewTek to do something about it is up to NewTek to determine and decide.

DEAD HORSE MODE: which is why I keep asking for EVOLVING official documentation: if the existing dox aren't connecting with, say, 8% of users, different explanatory approaches could be appended/included to the current documentation.


http://www.metamath.com/lsweb/fourls.htm

probiner
05-04-2012, 11:19 AM
Node Editor is very very good. Simple because you can mix the crap out of things, that otherwise would be separate with no interaction. Allows you to make your own tools too (imagine that applied to modeling ;)) It makes Lightwave much more that what would be without it. Dpont hurray!

The room for improvement I see, though, is:
- There are several node environments and not only one, or at least a layered one where everything could interact with everything else and not just Surface or Displacement or Schematic View, etc..
- Bonus organization gimmicks, since it can become a fuss when you work on separate bits and then try to join them. It would be nice to have things like Compounds; Organize/Relax/Distribute/Align spacing between nodes options; Highlight Links of selected nodes (sometimes you just lose yourself on all those lines crossing); Spline Interpolation (prettier :D); Groups or Fields (I could focus the view on the group by choosing it from a list, let's say I working the shader for Diffuse and rapidly want to jump to the shader I'm building for the Specular, without having to navigate the view to get there. Plus dragging a node belonging to a group with the Middle Mouse Button would drag all of them, without having to select them all, like they were linked).


If you want to learn about the Node Editor, hating it won't help :p
What in particular are you having difficulties with?

Cheers

RebelHill
05-04-2012, 11:27 AM
These conventions make it sometimes easier or more logical or more 'natural' to me to read the network from right to left, rather than left to right.

Then Id say you're shooting yourself in the foot...

Its like saying "its more natural to me to drive my car everywhere in reverse".

If you want to learn to use something, its almost always best to learn it (at the very least at first) in the way it was designed to be used.

Plus I dont even know what you're talking about when u say "these conventions"...

regular
05-04-2012, 11:41 AM
The tutorial on Node Based Editor from Libery3D.com cleared up a lot of mysteries for a newbie like me. :)

jeric_synergy
05-04-2012, 11:43 AM
The tutorial on Node Based Editor from Libery3D.com cleared up a lot of mysteries for a newbie like me. :)
Do you mean James Willmott's videos?

regular
05-04-2012, 11:43 AM
Do you mean James Willmott's videos?

Yes, that's the one.

shrox
05-04-2012, 11:43 AM
Node editor is the least intuitive aspect of Lightwave. But I am figuring it out...

jeric_synergy
05-04-2012, 11:44 AM
If you want to learn to use something, its almost always best to learn it (at the very least at first) in the way it was designed to be used.

Plus I dont even know what you're talking about when u say "these conventions"...
Obviously, the way the programmers think about it is congruent to how you think about it.

We are not all so blessed.


Yes, that's the one.
James makes very nice products.

RebelHill
05-04-2012, 12:04 PM
Obviously, the way the programmers think about it is congruent to how you think about it.

Left to right??

Thats like saying "its the same way literature students think".

Your statement makes no sense.

C follows B, follows A

I suspect you're overthinking things... like I say with the spot example... I point to a spot, and enquire colour/position...

what dont you get??

Dexter2999
05-04-2012, 12:12 PM
Node editor is the least intuitive aspect of Lightwave. But I am figuring it out...

Least "intuitive" because it is logical.
It has nothing to do with what your intuition says. (Apparently for many their intuition is to close their eyes and slap blindly...or run away)
It has everything to do with learning what the pieces do and then figuring out what they do in combination.

I have yet to see anyone post a "surprise" by using the nodal system. Only incredibly ingenious ways of combining nodes to achieve formerly impossible results.

jeric_synergy
05-04-2012, 12:18 PM
Your statement makes no sense.

RH, right off hand, as I indicated, I can't remember what it was that confused me -- simply remembering poorly/un understood things is difficult. When I have a concrete example I'll provide it.

It may be hard to believe that what seems natural to you is not natural to everyone, but it is true. Not everyone thinks in the same way, nor learns in the same way.

Meanwhile, I found an interesting bug in the editor, a small one. Posting in the bug forum. (My talent for finding bugs also slows down the learning process.)

silviotoledo
05-04-2012, 12:24 PM
I don't like nodal connections too much too, but it's very powerfull and not only for surfaces once it integrates almost everything. It's the natural way to advance is the complex CG area.

I would say I also expect it would be easier to use too and it can be. And I also would like to see more documentation about it and videos.

The LW surface editor ( with no nodes ) is also very powerfull and I really like it. I can tell you LW surface editor is the best if you compare to these ones I've used:

MAX - terrible
BLENDER - terrible
MODO - No words to say how unusable this is! Too weak!

So these other softwares needs a lot of presets materials 'cause users will find too much difficult to create a material.

But back to the problem. I really would like LW team make it easier to use or add a bit more documentation about it.

Artists need simplified solutions. We don't wanna deal with all that complex techniques.

As example I can show you the difficult to add a displacement map through a node. Oh my god! Why all that math and connections. I just wanna displace the geometry!

probiner
05-04-2012, 12:30 PM
As example I can show you the difficult to add a displacement map through a node. Oh my god! Why all that math and connections. I just wanna displace the geometry!

An editable compound... :p
The best of 2 worlds. Since there could be only the chosen inputs for a streamlined operation; while still be able to open it and change the mechanics going on.

I think that in a way this is what already happens with some of the materials, but they can't be opened or edited by default.

RebelHill
05-04-2012, 12:35 PM
It may be hard to believe that what seems natural to you is not natural to everyone, but it is true. Not everyone thinks in the same way, nor learns in the same way.

Im honestly not suggesting that what seems natural to one should be the same for all... But there are certain fundamentals which ARE the same for everyone, everywhere. What is up, what is round, what is blue? These things are just as natural to everyone.

My point about "I point to a 'spot', ask colour etc" was simply this...

Thats ALL the spot info node is... if u understand that basic idea, then u DO understand the spot info node, even if u dont realise it.

Really, all Im trying to do is get an understanding of where your understanding is failing in the hope that maybe I can help you out, plug the gap, whatever.

hrgiger
05-04-2012, 12:37 PM
Rebel Hill, yes on all accounts.

I would say the node editor is probably the best thing to come from the LightWave 9 series.

jeric_synergy
05-04-2012, 12:42 PM
I suspect you're overthinking things...
Very possible. :thumbsup:
RH> :twak: <Jeric
Later :beerchug:

JeffrySG
05-04-2012, 12:43 PM
The only thing I wish is that you could preview what the output of each node was in a visual way. Sometimes I'll do this by plugging the output into the color input even if it's not for the color just to see what I'm working with but it would be great if there was a more intuitive way to do this. Using VPR has made things 10x easier for me though as you can try many different combo and see the results very quickly. I always preferred the nodes to the layer system though. It's great that they are both still there for those that want them.

The great thing about the nodes are the power of them.
The frustrating thing about the nodes are the power in them.

jeric_synergy
05-04-2012, 01:08 PM
The only thing I wish is that you could preview what the output of each node was in a visual way. Sometimes I'll do this by plugging the output into the color input even if it's not for the color just to see what I'm working with but it would be great if there was a more intuitive way to do this.
It's pretty easy to think of new/better features for the editor, although all in all I don't dislike it heartily (but then, I avoid it (see above)). Jeffry's idea above would take a lot of the mystery out of working with the various outputs. :thumbsup: Perhaps clicking on a 'wire' could show it temporarily, like a "window into a pipe". (Plus a more permanent option.)

re Editor UI: I thought it was a HUGE mistake, though, to use "F" for "show all" when everywhere else in LW it's "a". That pissed me off A LOT. A fully gratuitous error. Also, when the zoom is at 98% and you can't manipulate arrows, some big impossible to miss indicator would be appreciated. :devil:


The great thing about the nodes are the power of them.
The frustrating thing about the nodes are the power in them.
Well put!



MAX - terrible
BLENDER - terrible
MODO - No words to say how unusable this is! Too weak!

LOL, I guess I should count my blessings then!

Lewis
05-04-2012, 01:16 PM
Nodes in LW are great but missing few important things IMHO.

1. Ability to share single node material over mutiple surfaces/materials i.e. fully nodal under the hood (current nodes work too "linear/layered" 'coz to apply same settings to 2 or more surfaces we need to copy/paste same setup into each "nodal" tree i.e. looks like we are doing nodes in layers (which is crazy by thought but looks/works that way in LW currently 'coz of that copy pasteing between surfaces :().

2. Sometime it confuses me 'coz we can mix layers and nodes in same time but i always forget which one overrides which 'coz even if you have activated nodes for a surface some channels of layers (like bump) still get through - that seems counter intuitive to me and I'd like it one or the other without mixing.

3. Nodal in LW is badly supported by OpenGL (almost always flat gray material until you render/VPR) :(. Yes I know it's not easy to support all nodes in openGL but simple color and 1-2 layers of texture should be doable. Some will argue we have VPR now but for complicated scenes, interiors (multibounces aren't really doable with DRAFT mode and non-draft is slow as hell) or lot of lights scenes VPR is too slow and not usable so i need to do F9 to check is my nodal tree working/texturing as i would like and simple openGL texture preview would help there a lot.

4. Compounds, i want to group several nodes into single node (was possible in NT's "other" product and i loved that option where uoy can go dig in and see how is some material actually created so you could learn by reverse engineering how is Dielectric or conductor node made). And No, I don't want answer - save nodal surface "preset" and call it a day. I really want to group my nodes into compounds to make it tidy and nice looking ;).

5. Nodes per surface are slow to activate (workflow issue). Id' like general preset in options where we could choose that surface editor works in Layers or Nodes by default so that when i click surface it goes directly to nodes instead need to click check mark and then open node editor for each surface (get's tiresome when you have 50 surfaces in scene and can't share single material over multiple of them).

BUT even with all that i see power of nodes in LW so anyone who need something powerful will have to learn them regardless of how illogical they seem in some situations or to some users :).

BTW all those points i said are mostly needed Features/workflows but i think Lw will need to evolve much more "under the hood" to allow that to work that way so I'm not sure how soon that is doable :(.

cheers

jeric_synergy
05-04-2012, 01:32 PM
I'm still typing the same number 3 times for SCALE, I wish that would get a shortcut. (Both in nodes and layers.)

RebelHill
05-04-2012, 01:45 PM
when the zoom is at 98% and you can't manipulate arrows

U can in v11

Dexter2999
05-04-2012, 01:54 PM
But there are certain fundamentals which ARE the same for everyone, everywhere. What is up, [snip]?

Are you talking Y (LW) or Z (AD)?

grangerfx
05-04-2012, 01:54 PM
I have been suggesting for some time that we provide an alternate UI to the Node Editor. It could work like some electronics I have seen with a nice easy to use front panel which can be flipped down so you can work on the many little switches and knobs behind it. The idea is that most of the time the front panel does exactly what you need but from time to time you can get at the underlying complexity. In the case of a nodal system, you could add an entire node tree as a shading preset and then just see the few most useful settings among all the nodes presented in a simple and easy to understand UI. When you want to, you can click a node editor button and rewire the system however you want and save it as a new preset. You could also share the presets with other users.

-Mark

RebelHill
05-04-2012, 01:55 PM
Z is only max u know... not AD general.

RebelHill
05-04-2012, 01:56 PM
I have been suggesting for some time that we provide an alternate UI to the Node Editor. It could work like some electronics I have seen with a nice easy to use front panel which can be flipped down so you can work on the many little switches and knobs behind it. The idea is that most of the time the front panel does exactly what you need but from time to time you can get at the underlying complexity. In the case of a nodal system, you could add an entire node tree as a shading preset and then just see the few most useful settings among all the nodes presented in a simple and easy to understand UI. When you want to, you can click a node editor button and rewire the system however you want and save it as a new preset. You could also share the presets with other users.

-Mark

Isnt that basically just compounds then? (not that its a bad thing)

Cageman
05-04-2012, 02:01 PM
Isnt that basically just compounds then? (not that its a bad thing)

Yep... Grangers description sounds very much like a compound node to me too!

:)

grangerfx
05-04-2012, 02:04 PM
Isnt that basically just compounds then? (not that its a bad thing)

I don't know. Is it? I was thinking that instead of seeing the standard surface editor, you would get a custom panel with all the buttons, sliders, numerical entry values, textures, envelopes etc. used to control the material preset you have selected. You would never see the nodal editor unless you request it. There would be no more standard surface editor. This approach is also a lot faster to render since only the values actually needed for shading would get computed.

Sensei
05-04-2012, 02:04 PM
For me it sounds like TrueGroup (http://www.trueart.pl/?URIType=Directory&URI=Products/Plug-Ins/TrueGroup):p

Dexter2999
05-04-2012, 02:04 PM
Z is only max u know... not AD general.

Actually I was thinking AutoCAD when I wrote that.

But good point, Sir.

DrStrik9
05-04-2012, 02:20 PM
For as little as I understand nodes, I like the potential power there. Recently, I've been using nodes to do things I can't seem to do in the regular surface editor. I ALWAYS start at the surface editor, and only work with nodes if the surface editor falls short, which seems to be happening more and more.

But it's always a kind of "I.Q test" for me. I just did a simple moving texture, with an animated alpha sequence combining its effect on a second static alpha. I used two alphas so I could change the animated color without having to rebuild the node setup. Conceptually it's very simple. But getting nodes to DO it: 2-1/2 hours of confusion and hair-pulling! Hahaha

To tell you the truth, it works beautifully, but I STILL don't really understand why. LOL :)

RebelHill
05-04-2012, 02:22 PM
I don't know. Is it? I was thinking that instead of seeing the standard surface editor, you would get a custom panel with all the buttons, sliders, numerical entry values, textures, envelopes etc. used to control the material preset you have selected. You would never see the nodal editor unless you request it. There would be no more standard surface editor. This approach is also a lot faster to render since only the values actually needed for shading would get computed.

Compounds with their individual front end perhaps rather than within the node editor itself per sť.

A nice idea, be worth thinking about more def.

Hieron
05-04-2012, 02:50 PM
I have been suggesting for some time that we provide an alternate UI to the Node Editor. It could work like some electronics I have seen with a nice easy to use front panel which can be flipped down so you can work on the many little switches and knobs behind it. The idea is that most of the time the front panel does exactly what you need but from time to time you can get at the underlying complexity. In the case of a nodal system, you could add an entire node tree as a shading preset and then just see the few most useful settings among all the nodes presented in a simple and easy to understand UI. When you want to, you can click a node editor button and rewire the system however you want and save it as a new preset. You could also share the presets with other users.

-Mark

Sounds like a perfect idea (compounds/nested nodal flows).

Anyone who worked with Labview (do a google images on that word, see the insane diagrams and the easy switches front ends) knows how versatile these can be in driving electronics etc. Same thing would work very well for LW nodes.

So node editor for sure is not too complicated, it just needs to be more globally connected to all other parts of LW, give more visual feedback and allow nesting.

People could sell or share these nested nodal flows with easy front ends, why not.

jeric_synergy
05-04-2012, 03:01 PM
U can in v11
Ooooo, nice, glad they fixed that.

BeeVee
05-04-2012, 03:12 PM
You actually have the opposite problem now. Just because you *can* hook up nodes at only 10% mag doesn't mean you really should - you can end up with all sorts going on... a quantum zen approach to nodal surfacing.

B

Lewis
05-04-2012, 03:39 PM
This is NODE compound thing screen I was talking about. User friendly version (view) for Artists and Advanced view (inside of compound) for those who like to do all this math "thing" on their own or even want to change it (math behind material) for some reason :) :).

Sensei
05-04-2012, 03:47 PM
This is NODE compound thing screen I was talking about. User friendly version (view) for Artists and Advanced view (inside of compound) for those who like to do all this math "thing" on their own or even want to change it (math behind material) for some reason :) :).

That's asking for slow rendering..

Lewis
05-04-2012, 03:51 PM
That's asking for slow rendering..

compounds mean slow rendering ????

silviotoledo
05-04-2012, 03:52 PM
This is NODE compound thing screen I was talking about. User friendly version (view) for Artists and Advanced view (inside of compound) for those who like to do all this math "thing" on their own or even want to change it (math behind material) for some reason :) :).

Yeah! I like the user friendly version and the advanced version inside. Killing interface. Did you draw it? I wish Matt does curved lines at connections because the squared ones overhides.


Would this alow down the render times Sensei? why?

Sensei
05-04-2012, 03:54 PM
compounds mean slow rendering ????

Of course.

The more will do cpu directly without interpreting while rendering, the faster will be routine.

Imagine simple cases like:

Add node which is then connected to some Clamp node. Native cpu version will be maybe hundred times faster than version you're suggesting..

Lewis
05-04-2012, 04:03 PM
Sensei - So all those other apps having Node compounds are SLOW at rendering and LW has fastest rendering 'coz it don't have compounds :) :)? Really ? This is just like grouping of nodes. Dielectric is compound of all those different nodes/vectors/whatever internally which is done by CODE anyway so it just shows them in more artist friendly way.. This is just silly.

I guess we need to tell Softimage Devs to kill the compounds (or MAX devs who have compounds for modeling tasks also) and they'll speedup rendering greatly :). Maybe we should ask NT Devs to kill the GUI totally and go back to PovRay way of typing in render settings, paths, settings... as text and waiting to render in Command line - that would be fastest then :) :).

silviotoledo - No i didn't draw this, i just made screengrabs, it works that way actually ;).

Lewis
05-04-2012, 04:07 PM
Add node which is then connected to some Clamp node. Native cpu version will be maybe hundred times faster than version you're suggesting..

You do realize this is not just some PS mockup - right ?

Sensei
05-04-2012, 04:43 PM
This is just silly.

I am quite shocked by your ignorance..

And I said "routine which does it using native cpu will do it maybe hundred times faster that the same split to dozen basic nodes".
It doesn't mean that rendering will be hundred times faster (because renderer's the most time consuming operation is ray-casting and recursive ray-tracing). But that node will be hundred times maybe faster. CPU has to jump from memory to another memory, and constantly reloading cpu instruction cache, not to mention data cache, which wouldn't be done if everything was just single procedure not jumping anywhere.

Flexibility received, cpu time taken.

See gfx cards- they are extremely not flexible.. (you can't even have more than 1 normal vector or 1 uv per vertex!)



I guess we need to tell Softimage Devs to kill the compounds (or MAX devs who have compounds for modeling tasks also) and they'll speedup rendering greatly . Maybe we should ask NT Devs to kill the GUI totally and go back to PovRay way of typing in render settings, paths, settings... as text and waiting to render in Command line - that would be fastest then .

Interpreting text files actually is VERY slow. Procedure has to parse text which might be damaged. If it won't do it correctly routine might crash if something is not perfectly entered.. See how slow is OBJ loading.. Load 1 million poly OBJ and then load same LWO, if you're not familiar with them..

Computers like binary data directly provided.
The less interpreting, the less jumping from routine to routine, the better.

GUI doesn't mean slow working of operating system. Most of processes are in waiting state, until some event is send to wake up them. And usually only active window is receiving and processing mouse and keyboard events.
Command line tool must be started up (SLOW), then parse (even SLOWER), and then render, and then save (SLOW disk access).
Renderer such as LW has everything loaded and prepared already, and result is ending up in physical memory..

Lewis
05-04-2012, 04:56 PM
I am quite shocked by your ignorance..


Ignorance of what ? You do realize that screen-grabs i made WORK and they work fast and those who made them didn't find it unnecessary or slow. Seems that you are ignorant in this case. I'll repeat this is not PS mockup, it's actual product/working.

Also i didn't comment your prediction of "maybe 100 time slower" (so read more carefully next time). I just say it's silly to prevent artist friendly tools (or rather just a view type like in this case) on excuse it MIGHT be slower (let alone percentage of what it "might" be).

So how do you comment many other apps having compounds of nodes at their disposal ? Are their DEVs not knowing to CODE then or what ?

Jezz sometime it's really hard to debate on NT forums, some users just don't understand "Artist Friendly" stuff. Maybe we really should just type in numbers and do math equations to prevent "possible" slowness of rendering, God forbid any user friendly drag and drop, groups, compounds or anything that helps artists to get results better :D.

Hieron
05-04-2012, 04:58 PM
I am quite shocked by your ignorance....

ehm.?!. let's keep it sort of friendly?
as if he is suggesting something that will seriously slow down renderspeed in todays production renders, having GI, AO, blurry refl. soft shadowed traced lights.


This is NODE compound thing screen I was talking about. User friendly version (view) for Artists and Advanced view (inside of compound) for those who like to do all this math "thing" on their own or even want to change it (math behind material) for some reason :) :).

Agree, did you btw do that google images search on Labview? One could envision an even "artist friendlier" front end like Labview does provide to access the nodal madness behind. I do not mind but I could imagine it to be very helpfull to some...

Sensei
05-04-2012, 05:15 PM
Do you find Lscript/Python artistic friendly? You can load scripts made in them, then change whatever they contain. You have flexibility..
But you can't ignore the fact the same plugin compiled in C/C++ will run hundred times faster. That's fact.
I have replaced many Lscript with equivalent in C/C++ and people using previously script were "shocked by speed"..


Are their DEVs not knowing to CODE then or what ?

That's not the only matter of knowledge. Which (sport) runner will be at finish- the one who has 1 km to run, or the one who has 10 km? CPU is jumping from memory to memory, reloading same data constantly, over and over again. And nobody can't do anything with that. Except writing everything from scratch using native cpu machine code.



Jezz sometime it's really hard to debate on NT forums, some users just don't understand "Artist Friendly" stuff.

Who is not understanding "artistic friendly" stuff?
Me?
Telling the truth that is not by your mind, is hurting you?

I didn't comment on any flexibility aspect. I was constantly telling about speed of execution of code.

Of course LW should have something like: select couple nodes, press RMB, pick up from drop-down context menu "Create Group" and done. There is group. Easy to do by user. But it won't change fact that it will have similar execution time as it has currently.

Hieron
05-04-2012, 05:20 PM
hehe, this thread went from commenting that the node editor is too complex to work with for some, to noting general rendering info and that C++ direct code is faster..
There is a sort of disconnect here :)



I didn't comment on any flexibility aspect. I was constantly telling about speed of execution of code.


Which is moot if there is no sense of scale given. Sure adding a layer takes a wee bit more time.. is it significant when average rendertimes per frame run into say 10 minutes? (sincere question)


Of course LW should have something like: select couple nodes, press RMB, pick up from drop-down context menu "Create Group" and done. There is group. Easy to do by user. But it won't change fact that it will have similar execution time as it has currently.

Good so everyone agrees. Let's just assume that the time impact will be absolutely minimal in normal usage scenarios, otherwise every single feature request could be bombarded by such replies?

probiner
05-04-2012, 05:27 PM
This is NODE compound thing screen I was talking about. User friendly version (view) for Artists and Advanced view (inside of compound) for those who like to do all this math "thing" on their own or even want to change it (math behind material) for some reason :) :).

Im gonna add a checklist Option to your example Lewis. This would allow those that are designing the Internal Node Tree with all the complications and math etc to make the maximum of inputs, outputs and properties of each node available from the outside as they see fit for an the end user, that doesn't want to deal with the internal complicated stuff of the compound. Just like you have with some Material in LW today I guess.


By the way Lewis... What a heck is that? hun? :O

And this one is a mockup :D
http://i153.photobucket.com/albums/s202/animatics/Lightwave/th_Compound-Nodes-Checklist-B2.png (http://i153.photobucket.com/albums/s202/animatics/Lightwave/Compound-Nodes-Checklist-B2.png)

RebelHill
05-04-2012, 05:45 PM
This is NODE compound thing screen I was talking about. User friendly version (view) for Artists and Advanced view (inside of compound) for those who like to do all this math "thing" on their own or even want to change it (math behind material) for some reason :) :).

yes thats perfectly fine, Im not sure I see the point in putting the final compound of any network as some kind of panel based front end surface editor thing with separate node editor for the inner compound whic is sort of how Im interpreting Mark's thoughts and sort of what we have now, sort of.

Id have thought that this common node graph with compounds style is fine, no point in reinventing the wheel, If u wanna jazz it up, make compounds encryptable to allow node based "plugins" to be "written" by devs, etc. Give special nodes who's output data comes from sliders, or some other sorts of things u can have in the UI/VP to let node detwork builders cramp things down to a simple, option based UI style/based input where applicable, etc.

Basically... give a better platform for node built plugin development and make it look not too dissimilar to Lewis' and probiners pictures I thinks.

Lewis
05-04-2012, 05:48 PM
By the way Lewis... What a heck is that? hun? :O


Hehe, secret weapon, LW of course ;) :).

jeric_synergy
05-04-2012, 05:52 PM
Of course LW should have something like: select couple nodes, press RMB, pick up from drop-down context menu "Create Group" and done.
Except, of course, it should be a hotkey. :cursin:


:D

probiner
05-04-2012, 05:56 PM
Hehe, secret weapon, LW of course ;) :).

It's CORE!(?) There, I said it :p

What is the racional behind "Self" and "Self_1" if you can explain :D ?

speismonqui
05-04-2012, 06:12 PM
It's CORE!(?) There, I said it :p

What is the racional behind "Self" and "Self_1" if you can explain :D ?

I kwet it! it looks lovely :cry:

jeric_synergy
05-04-2012, 06:16 PM
I kwet it! it looks lovely :cry:
It was the spawn of hell.

Lewis
05-04-2012, 06:17 PM
It's CORE!(?) There, I said it :p


:gotpics:
:newhere:
;)

probiner
05-04-2012, 06:18 PM
Ah forgot another thing that bothers me sometimes. To have to pan around back and forward long distances to get the same link already in the neighborhood. I guess that since they corrected the zoom issue in LW11 this might not bother so much.
Anyway, here it goes.

http://i153.photobucket.com/albums/s202/animatics/Lightwave/Nodes-MMB.gif

Yeah I know... it's a shot distance here. But when you have groups of Node Trees interacting and you just wanted a copy of that link that is right there, it kind of makes you snap out of what you were doing when you go look for the source of that link. =P
Bottom line, Node environment usability has particular obstacles that we don't encounter in the rest of the app, and it would be nice if there were eventually "shortcuts" thought specifically for how we use it.

Cheers

Matt
05-04-2012, 07:19 PM
If you don't like the node editor, then don't use it. Regular layered texturing still works fine in Lightwave, doesn't it? I don't see the problem.

Exactly right, the beauty of LightWave's surfacing is that you have the power of nodes _if_ you need them, if you don't, you can get by quite happily with the layered Surface Editor.

You can even mix and match which channels you want to use nodes with - only need a Fresnel node for reflections? Just plug that in and you can use the layers for everything else. Not everyone else does this.

Having said that, improved tutorials for nodes is definitely something we plan to do.

dwburman
05-04-2012, 10:07 PM
I'm still typing the same number 3 times for SCALE, I wish that would get a shortcut. (Both in nodes and layers.)

In that situation, I sometimes will add a scalar constant node (Add Node>Constant>Scalar) and plug it in where needed. The nice thing about doing it that way is you can plug it into multiple nodes that need to stay in sync (like different image maps for the same texture) and I only need to change the number once.

dwburman
05-04-2012, 10:23 PM
I like the node editor and I tend to use it more than the layer system, especially if I have to copy/paste the same image or same size image in several channels.

I do agree that it can use some improvement. My wish list is

1) a bigger previewer and a way to show the output of nodes in that previewer and not just the final result. There's a plugin called InputSpy or something like that that takes care of the color and number inputs.

2) grouping/compounds with the ability to publish channels so you can use sliders etc on.

3) a unified node editor so you don't have separate node editors for each surface/displacement/etc - In the mean time there's a plugin (in pom's nodes) that you can plug the output of your node tree to store it and another node you can use to retrieve it and plug it in elsewhere.

4) There are some workflows in node-based compositors that could be borrowed from to make working with nodes easier.

5) nodes with a limited number outputs should have all possible outputs exposed... I'm thinking specifically of the Vector Scalar tool where you have to pick which channel to use for the scalar out when there are only 6 possibilities. If all outputs were exposed, I wouldn't have to open the node to select a channel from the menu. (there is a 3rd party node that does this, but it should be built-in.)

[edit] I just wanted to note that I am aware that some of my wishes were already stated in this thread by other forum members. :)

geo_n
05-04-2012, 10:26 PM
You must try modo shadertree. :D
Lw nodes are easier to use than the infamous shadertree.

jameswillmott
05-04-2012, 11:41 PM
I like your "node operator" idea Jeric. It's not as crazy as you think, I used to think I'd never buy a 3d model, since modeling is a mayor strenght of mine..

There IS a market for this, I've had a few clients that have asked for quite a few custom built node solutions only...

jeric_synergy
05-05-2012, 12:15 AM
There IS a market for this, I've had a few clients that have asked for quite a few custom built node solutions only...
Indeed? Interesting: could you expand on the situations?

FWIW, I meant "market" in the economic sense, a forum for buying/selling, not just in the "demand" sense.

jameswillmott
05-05-2012, 12:17 AM
Indeed? Interesting: could you expand on the situations?

FWIW, I meant "market" in the economic sense, a forum for buying/selling, not just in the "demand" sense.

Ah, there is not 'market' in your sense but there is/was demand...

jeric_synergy
05-05-2012, 12:28 AM
Unfortunately, I think the demand is too low to finance the infrastructure for a market. At the very least, such a service would have to encompass all of the various renderers to gain enough traction to make a go of it..

I think right now we'd be lucky to get even a nonprofit referral service going.

erikals
05-05-2012, 12:36 AM
tweaking presets and storing presets for later use is the fastest solution...

http://forums.newtek.com/showthread.php?t=127028

 

jeric_synergy
05-05-2012, 12:58 AM
tweaking presets and storing presets for later use is the fastest solution...
 
Not if you lack the ability to make a complex network in the first place.

You're better off sending xswampyx or James Willmot a mutually agreed sum. :D

silviotoledo
05-05-2012, 06:24 AM
... Just plug that in and you can use the layers for everything else...

Hey Matt

What about curved lines connections between nodes?
The squared ones overlap when accessing the same connectors.

alexos
05-05-2012, 07:26 AM
A point on a surface is a "spot"... there are various "infos" that you can ask about that spot... "... whats not to get?

I think I can answer that: you can know what it is/does in theory, but using that knowledge is an entirely different matter. And the funny thing is, other people just won't understand - as you say - "what's not to get", because to them (to you) it's all so perfectly, 2+2=4 clear that they can't imagine how anyone could have a problem with the whole thing. And yet.

I'm sort of in the middle here - I love the node editor, it made my Lightwave life SO much easier and it's rather fun to use; but on the other hand, after all these years I still haven't (not that I've tried much, admittedly) figured out what to do with all those fancy trigonometry and vector nodes (multiply matrix3x3?! ...Yeah, right!), half of the DP kit is still a complete mystery and I've never used any of the IFW waveforms; and when I see examples of those uber-populated node networks I can't help but think there must be something very wrong somewhere, because really, one shouldn't have to mess around that much for a single bloody material!

ADP.

Sensei
05-05-2012, 07:43 AM
Example usage of trigonometry - waves - plug Spot Info World Position and some vector to Math > Vector > Distance. Multiply by 3.14159265 and put to Sinus/Cosinus. Output from it plug to some clamp node or gradient (so -1 will be converted to 0) and then to f.e. Diffuse. You will have waves.

You can use them for something pulsing with regular intervals. Values from -infinity to +infinity is converted to -1.0 to 1.0.
Or if you will use Math > Scalar > Pow on input, in growing or lowering, intervals (f.e. ball jumping on floor is good example of using sinus/cosinus in Motion node editor, amplitude of jump lowered with every jump until reaching 0).

meshpig
05-05-2012, 08:40 AM
... (f.e. ball jumping on floor...

Bite hard into the backside of English as a totality; "f.e." should be "e.g." from the Latin "exempli gratia"... meaning for example and don't let this freakin american spell check crap tell you otherwise:)

jeric_synergy
05-05-2012, 09:34 AM
In that situation, I sometimes will add a scalar constant node (Add Node>Constant>Scalar) and plug it in where needed. The nice thing about doing it that way is you can plug it into multiple nodes that need to stay in sync (like different image maps for the same texture) and I only need to change the number once.
Dana, kind of a tossup between that and adding a reference null. Fiddley, y'knowatteyemeen?

BOTH of which approaches it would be nice to have a button that just makes it happen (adds the scalar and connects the inputs, or adds a refnull and selects it as ref).

jeric_synergy
05-05-2012, 09:40 AM
I think I can answer that: you can know what it is/does in theory, but using that knowledge is an entirely different matter. And the funny thing is, other people just won't understand - as you say - "what's not to get", because to them (to you) it's all so perfectly, 2+2=4 clear that they can't imagine how anyone could have a problem with the whole thing. And yet.

Yes: I can parrot back definitions of nodes all day long. But the logic involved in creating the network escapes me. And it's not like I'm the only guy struggling with it. --Ooooo, just thought of a good metaphor: I know what electronic parts DO, but sussing out what a simple circuit does would be very difficult for me. Creating one?? Something like an old flip-flop? Forget it.

I'm sort of in the middle here - I love the node editor, it made my Lightwave life SO much easier and it's rather fun to use; but on the other hand, after all these years I still haven't (not that I've tried much, admittedly) figured out what to do with all those fancy trigonometry and vector nodes (multiply matrix3x3?! ...Yeah, right!), half of the DP kit is still a complete mystery and I've never used any of the IFW waveforms; and when I see examples of those uber-populated node networks I can't help but think there must be something very wrong somewhere, because really, one shouldn't have to mess around that much for a single bloody material!
ADP.
I don't doubt that it is just that complicated, --like I said, it's the logic and the flow that confuses me. The programmers have been protecting us from the complexity. But to get programmer level power, they have to expose that complexity to us, in all its horrible glory.

Anyway, hitting the tutorials again.

jeric_synergy
05-05-2012, 10:18 AM
Another thing that may be frustrating for student node users is that, especially for 3rd party nodes created by individuals or extremely small companies, the documentation is literally written by rocket scientists.

And I think by now it's pretty well established that rocket scientists are not especially the best documentation producers. --no matter how much they protest to the contrary. (It is to laugh.)

For instance, god bless Denis, but to me his documentation is almost completely opaque.

Clear documentation is difficult and laborious to produce, and I don't see how this can be addressed because the producers' resources are too limited, and on the balance, I'd much rather these individuals and small teams spend their time on coding, where their talents are, and not on dox, which they might be hopeless at anyway.

This is where LightWIKI comes in, I guess.

jeric_synergy
05-05-2012, 03:07 PM
In that situation, I sometimes will add a scalar constant node (Add Node>Constant>Scalar) and plug it in where needed.
I thought that if you connected a scalar to a vector input, the scalar only filled up the first, "x" slot?

What I'd like is a scalar that fills up all 3 vector slots.

probiner
05-05-2012, 03:10 PM
wow... four posts in a row in 5 hours... you can edit posts you know? :p

Sensei
05-05-2012, 03:14 PM
When you're plugging Const > Scalar 1.0 to Diffuse Shading Color, result is complete white - so scalar was copied to all RGB..

And the same is when Const > Scalar is plugged to Math > Vector > Add and output plugged to Diffuse Shading.

jeric_synergy
05-05-2012, 03:15 PM
I like to keep them conceptually unitary. No one seems to be able to pull more than one thought from a post, so I bow to ugly necessity.

jeric_synergy
05-05-2012, 03:17 PM
When you're plugging Const > Scalar 1.0 to Diffuse Shading Color, result is complete white - so scalar was copied to all RGB..
Thanks Sensei. Good news. :thumbsup:

I suppose there must be a short table somewhere that shows how different output types are interpreted by clashing input types.

zarti
05-05-2012, 03:44 PM
This is NODE compound thing screen I was talking about. User friendly version (view) for Artists and Advanced view (inside of compound) for those who like to do all this math "thing" on their own or even want to change it (math behind material) for some reason :) :).

http://forums.newtek.com/attachment.php?attachmentid=104050&d=1336167577

--

eeeehhH ! .. Nostalgy ..

does it work today yet , or was an old screen ?



--

other than the above comment , i dont want to comment more on this topic .

sends me 3 and more years back .

nai thanks .

Serling
05-05-2012, 06:20 PM
just to summerise -

I realise I dont have to use it. I want to use it, but find it overly complicated. Clearly I dont actually hate the node editor, I just dont get on with it that well, kind've like my brother in law (no, only joking Nat!).

Thanks to everyone for joining in this light hearted conversation.

Since most of my surfacing lately has involved little more than UV mapping (which used to be as much a mystery to me as the Node Editor appears to be to you), I don't really get to play with nodes much.

The problem with nodes isn't the nodes themselves: it's all the permutations and infinitesimally small tweaks you can spend hours on without ever really achieving anything close to what you want to see.

Ultimately, it's all just trial and error for me and that's a miserable way to work when you have to get something done under deadline. I generally avoid the node editor unless I'm only doing a couple of nodes max. Anything beyond that, and I find it's quicker and easier to stick with the layered approach.

dwburman
05-06-2012, 11:39 AM
Thanks Sensei. Good news. :thumbsup:

I suppose there must be a short table somewhere that shows how different output types are interpreted by clashing input types.

Something like... :D

Lewis
05-06-2012, 11:57 AM
does it work today yet , or was an old screen ?


Works just fine (I'm still using it for some model showoff 'coz of speed), it's fresh screen :) :).

jeric_synergy
05-06-2012, 12:00 PM
Something like... :D
Nice. :thumbsup:

Looks like I better look up "CCIR 601".

+++
Oh, I see where I got my misconception: I had it BACKWARDS. When a vector feeds a scalar, only the first value is used. The other two are dumped.

Captain Obvious
05-06-2012, 03:29 PM
Do you find Lscript/Python artistic friendly? You can load scripts made in them, then change whatever they contain. You have flexibility..
But you can't ignore the fact the same plugin compiled in C/C++ will run hundred times faster. That's fact.
I have replaced many Lscript with equivalent in C/C++ and people using previously script were "shocked by speed"..
One 'easy' work-around for that: Have a built-in compiler.

That's effectively how the node-based Renderman shader editor works, I believe: you hook up nodes and save it out as a shader, and the editor compiles it into Renderman shader code.

Nice and optimized machine code, generated on rendertime. It shouldn't be that difficult.

zarti
05-06-2012, 04:24 PM
One 'easy' work-around for that: Have a built-in compiler.

That's effectively how the node-based Renderman shader editor works, I believe: you hook up nodes and save it out as a shader, and the editor compiles it into Renderman shader code.

Nice and optimized machine code, generated on rendertime. It shouldn't be that difficult.

thats not 'a work-around' . thats usual business .

--

when building or testing shaders with a lot of nodes( im not referring to RM )renderspeed is the same but just the compiling extra time gets added . once you are pleased and have built its ui controls , you compile it definitively as a version , and use that to work as an artist and render final scenes . So , you have the Compound , Lewis was talking about .. and 0 milliseconds of delay because of the nodal complexity or whhatewwa . everything else is Mythology ..

peace ! :D

--

final opinion ; you betah love nodes . they do make sense .

Sensei
05-06-2012, 04:36 PM
If Renderman .slo is readable by either Windows, Macinotosh and Unix it's not real compiling to machine code, but pseudo-code that's later interpreted while rendering.
See how Java works.

ArtGoblin
05-06-2012, 04:38 PM
Well...this question has a very obvious answer, and just as Douglas Adams would have explained it... the dreaded "why" questions, you could go on asking them forever but when it all come down to it there's only one real answer. And this is the case with your questions of "why" this and "why" that, and even though there have been made many very good and logical answers to your questions, you keep on asking. "Why" is that? Well I'm guessing it must be becouse you don't feel you have the answer you seek, but let me finish this one up for you.....
Sorry I dont understand why would one need a million shaders?

Why not?

Everything worth any damn isn't easy, making art no matter how creative an individual is, is still hard work... so if you want to use the advantages the node editor can give you, get to it and don't give up... it might just be worth it :)

zarti
05-06-2012, 04:53 PM
@ Sorry I dont understand why would one need a million shaders?

i believe it is not a matter of billions or trillions ..

it is a matter of a single one principle : to be free .

Ernest
05-06-2012, 09:24 PM
Im honestly not suggesting that what seems natural to one should be the same for all... But there are certain fundamentals which ARE the same for everyone, everywhere. What is up, what is round, what is blue? These things are just as natural to everyone.

My point about "I point to a 'spot', ask colour etc" was simply this...

Thats ALL the spot info node is... if u understand that basic idea, then u DO understand the spot info node, even if u dont realise it.

Really, all Im trying to do is get an understanding of where your understanding is failing in the hope that maybe I can help you out, plug the gap, whatever.

Oh, there's plenty to get confused about, regarding the spot node, if you're not thinking in correct node form from the start. The most basic one, I constantly get is, "So the spot gives me the info on a point. I can query it for light incidence and add 3 to it. Now I made this web of 500 nodes to try to make a loop so it will do it for each and every point. Now how do I plug all this into a single surface input?"

So it's not really the "spot info" node itself that gives "procedural people" trouble. The trouble is in the concept how to use a node that queries a point when they think in terms of step-by-step procedural programs, loops and logic forks.

speismonqui
05-06-2012, 09:44 PM
@ Sorry I dont understand why would one need a million shaders?

i believe it is not a matter of billions or trillions ..

it is a matter of a single one principle : to be free .

a million? that's insane. It's more like 2294
http://www.vray-materials.de/all_materials.php
:D

JonW
05-06-2012, 10:38 PM
I think this cartoon says it all.

Layers or Nodes!.....

Matt
05-13-2012, 03:37 PM
Hey Matt

What about curved lines connections between nodes?
The squared ones overlap when accessing the same connectors.

'tis done. ;)

jameswillmott
05-13-2012, 04:17 PM
And pretty they look too.

CAClark
05-13-2012, 05:03 PM
I'll agree that I dislike quite a lot the node editor. 90% of it I just don't understand. The 10% i do allows me to do some bits n bibs I can't do the old way with layers in channels. I still do an awful lot of stuff using the old ways, but I guess I'll gradually get to it. I should check to see if RebelHill has nodal videos, because the LW11 rendering one was great.

Cheers!

probiner
05-13-2012, 05:06 PM
The "guy" above you has :D
http://www.liberty3d.com/2012/03/node-based-surfacing-video-2/

erikals
05-13-2012, 07:54 PM
@10 dollar http://erikalstad.com/backup/misc.php_files/047.gif

Ryan Roye
05-13-2012, 08:22 PM
I find the node editor helpful... perhaps not the most efficient tool out there, but it does allow things that would otherwise be tedious, difficult, or impossible to do.

...but then again, I do agree the node editor can fill the shoes of the "tedious" role at times. I honestly don't know what a program could replace it with... node editors are used in many different programs, not just LW. Ever seen a typical node tree a completed project has in high-end video editing software? They get pretty crazy.

ncr100
05-13-2012, 08:44 PM
@lazyanimator - I really like the Node Editor, however I have an engineering degree so I get excited to have "the dials".

However I get having frustration there too. The first time I worked with a node-system (wasn't lightwave fwiw) I was overwhelmed.

Generally, I believe making a simple control for a complex process is hard (think Mac OSX's one mouse button, and intentionally missing user manual), but very very valuable, so I'd like to hear more about your frustration. [Also, this 'interview' part of problem solving I also like, roiling (sp?) the situation by hearing about the dense layer of problem.]

* How do you see what the true value of the Node Editor is, in your words?
** Do you see the "one node effecting another node" as adding lots of exponential complexity? (Looking at the complexity - e.g. seeing all of the many leaves of a fully grown tree at once, when looking at a tree.)
** Or, do you see this "one node effecting another" as a way to override different qualities of a Surface? (Looking at the essential structure of the tree, e.g. the trunk and few key branches.)

I wonder if you're overwhelmed visually. Perhaps if the UNUSED values of the node were de-emphasized visually, that the node system might engage with you, might "click" with you better...do you have a guess if that'd help?

* What do you dislike seeing when you open the Node Editor?
** The pre-sorted list on the left?
** The empty space in the middle?
** The small words, small GUI buttons?
** The minimal preview of surfaces?
* What would you like to see first, when you open the Node Editor?

Curious!
Nick


I'll be honest and accept that I am opening myself up to abuse but frankly - The node editor is fking rediculous. There I've said it!

I appreciate its flexibility and power and thats great, it really is, but it reminds me both literally and metaphorically of the early synthesizers of the late 70's, early 80's. Plug this into that, turn this up, that down and those half up and you'll get a sound, as long as you have an engineering degree that is! Yes, I know its not quite the same is it. I know its great and reasonably simple to add a material or a gradient or any of the basics, but I could more or less do that in the standard materials editor. Like the musicians or the 70's and 80's I am an artist first and a technician second (or third or forth) I appreciate you have to put a bit of work in to get results and some of that is technical. It cant all be artistic and fun all the time. But surely we want these processes to be simple dont we? So we can get on with the actual job of creating stuff? If I were a pilot I would want the plane to take off when i pulled that lever, I wouldnt want to have to go and plug all the bits in first (neither would my passengers I would wager!). Am I over reacting a little? Well yes, probably! But for me at least, the future of cgi in this digital age is to refine the process of creation by making ball aching things less so! I dont mind tweaking, but I for one dont want to have to spend a day trying to reprogram nodes in order to get the correct settings.

I am sure all this has been covered before, but I needed to rant. Now, there, see, I feel better.

Going for a lay down,

LA.

Rove
05-14-2012, 07:47 AM
I think the node editor truly is a work of wonder. I kinda agree with Lazy and Jeric but I wouldn't call it too complicated perse though. I've examined SideFX Houdini's surfacing power and got lost pretty quick.

I'm very visually oriŽnted. I seriously sucked at math at school. Once the Node Editor got introduced I immediately understood that it was a powerful thing which I probably never really would fully understand.
I have to admit I stayed away from it at first. After some time I started experimenting with it and found cool solutions for problems I encountered during projects.

I feel I still miss out on alot of it's power just because I cannot seem to find the time to read up on all available nodes and their specific purpose. I wish I had a couple of hours a week to invest in experimenting with the Node Editor but I have to be realistic about it.

I find myself using the Node Editor more and more though.

Tobian
05-14-2012, 03:58 PM
Pretty self defeating thread title here, as, if you hate it don't use it :) (as RebelHill repeatedly said!)

I agree that their could be a lot more done with the node editor, to make it more user friendly, compounds, which have complex pre-made internals all squished up into a single neat node, with user-made inputs and outputs, and ways of making those available on preset-shelf-type places, or in a 'user' menu in the node editor (most other places have a custom menu in LW). I'd also like a way to completely replace the surfaces, in the surface editor, with 'materials', both the coded and the hand-made ones. In terms of 'speed' that would make browsing and editing them much faster/easier, as you shouldn't need to have the full node editor open to make changes to the surface (this is where compounds with their custom inputs and outputs come in) and indeed several apps do this approach. I was very impressed with the way the cycles nodal material system does this in Blender.

Despite what Sensei has said I haven't noticed major slowdowns when mixing up a bunch of shaders vs using the pre-baked materials, indeed it's often faster, due to the complexity of the 'physically accurate' nature of these materials. Also: this is what the BSDF integrator was for in Core: to optimise all of the shaders, in a compound, into one shader, so yes, more of this goodness in Classic LW please! :)

Making the node editor more context sensitive is really needed, if it's to go throughout the software, and making the node editor fully global is ultimately something LW needs (Having nodal procedurals in LW11 helps on this front, but it's not quite there yet!)

Hate is such a strong word really. If you concentrate on how much you hate it, then you will just create a barrier to learning it, and there's just so much potential to create awesome effects you couldn't otherwise create. Yes, I agree, there is a huge scope to simplify the way the data inside node networks presented to the users, however. As Lewis' example material from Core shows, you can make really complex materials from a handful of layers of very simple materials. The power to package all of that up into a compressed compound, and with optimisations (and some caching love please!) like the BSDF integrator, or even a run-time compilation as CaptainObvious suggested, could really make Lightwave faster and easier to use, and make it possible to distribute these surfaces in a much easier to understand way for those who don't know what they are doing, and with scope to explore and tinker with them, for those who do.

Ultimately though, the maths and techniques of the node editor will always be a heady complex blend, and there's going to be those of us who can simply only scratch the surface, and that sadly is the way it is, in much the same way that rigging and expressions are alien to me, and would be a huge headache to learn. I don't HATE them, I just acknowledge I suck at them :D That's my fault, not the technology. I put more effort into lighting, rendering, modelling and surfacing, and the manual on those isn't that great either, I just stuck at it and figured it all out. (and still have a lot to learn too). Even if they do improve the node editor to include all of this stuff there'll come a point where you have to roll up your sleeves and stuck your hands in to get what you want, and all of that just becomes window-decoration. Like most things, the more I understand the basic principles of what is going on, the more cool stuff I can create and the better I can be, and the better and more predictable the results become, so really, there's no substitute for learning it really.

Ernest
05-14-2012, 03:58 PM
What do you guys think, does it still make sense to have a separate presets panel? When we can create new compound nodes, would they go in the presets panel, or should they be added directly to the node panel menu? Should the node panel's menu be only for "primary nodes" that have no smaller nodes inside?

My take on it, is that it's easier to have all nodes in the same menu, including the compound ones that we will create as presets. If it gets to that, a separate presets panel would not make much sense anymore.

jeric_synergy
05-14-2012, 04:10 PM
My take on it, is that it's easier to have all nodes in the same menu, including the compound ones that we will create as presets. If it gets to that, a separate presets panel would not make much sense anymore.
In AE, both the plugins AND the named plugin presets are in the same panel, and it's Searchable.

That would be an interface to emulate for compound nodes.

jasonwestmas
05-14-2012, 04:42 PM
Gosh, I remember learning a lot about the node editor just through these forums. I can't believe that's how I learned how to use it. Then James shined some more light with his video. I believe it was the guys that have worked with node editors before LW9.0 that helped us out on these forums.

It's pretty darn powerful system none the less. It's the visual aspect of the nodes and how they flow that helps me set things up in a way I can better understand. So in that regard it's faster for me than the layers.

erikals
05-15-2012, 02:20 AM
What do you guys think, does it still make sense to have a separate presets panel? When we can create new compound nodes, would they go in the presets panel, or should they be added directly to the node panel menu? Should the node panel's menu be only for "primary nodes" that have no smaller nodes inside?

My take on it, is that it's easier to have all nodes in the same menu, including the compound ones that we will create as presets. If it gets to that, a separate presets panel would not make much sense anymore.

i was just about to write exactly that. http://erikalstad.com/backup/misc.php_files/wink.gif
nearly anyway, the node editor should have a preset drop-down or something.

http://erikalstad.com/backup/misc.php_files/lwicon.gif
 

Jim M
05-15-2012, 03:43 AM
Something that would help people traverse the chasm from LAYERS to NODES would be this...

Layers and Nodes are not different things, they just don't have the APPARENT connections with each other they should. When you set up a Layered Material, the Layer settings should propogate thoroughly and create a node network. The Node network being what is used by the renderer. The Layers being a quick access front end.

Once this is done, more people would be able to understand more directly. ...You could even have user panels in the layers tab to quick access a Material node for example, and have a very configurable MATERIAL EDITOR

Over.

jasonwestmas
05-15-2012, 06:27 AM
What do you guys think, does it still make sense to have a separate presets panel? When we can create new compound nodes, would they go in the presets panel, or should they be added directly to the node panel menu? Should the node panel's menu be only for "primary nodes" that have no smaller nodes inside?

My take on it, is that it's easier to have all nodes in the same menu, including the compound ones that we will create as presets. If it gets to that, a separate presets panel would not make much sense anymore.

yes, I think you have the right idea. I've always believed that there are way too many panels to hop to, and so more consolidation in an intelligent manner is the way to go. On the flip side NT should pursue a more flexible UI technology for tearing off tabs and panels when needed.

Lightwolf
05-15-2012, 07:26 AM
What do you guys think, does it still make sense to have a separate presets panel? When we can create new compound nodes, would they go in the presets panel, or should they be added directly to the node panel menu? Should the node panel's menu be only for "primary nodes" that have no smaller nodes inside?
Some of that depends on how it's managed. A compound as a preset/template is different from a compound that is referenced (essentially like a native node is).
The difference being: The former creates a local copy of the compound, if you edit it then it only affects the node graph where you added it.

The later would be a compound that, if edited, is changed for all places where it is used (that is, the internal node set-up, not the properties applied to the compound itself).

And it would certainly be good to have both types.

Cheers,
Mike

jeric_synergy
05-15-2012, 07:55 AM
Layers and Nodes are not different things, they just don't have the APPARENT connections with each other they should. When you set up a Layered Material, the Layer settings should propagate thoroughly and create a node network. The Node network being what is used by the renderer. The Layers being a quick access front end.
Indeed. :thumbsup:

A "make Nodal" switch would definitely have helped with the assimilation process. And would still be a nice thing. "Rough" it in w/Layers, polish with nodes.

jeric_synergy
05-15-2012, 08:05 AM
The difference being: The former creates a local copy of the compound, if you edit it then it only affects the node graph where you added it.

The later would be a compound that, if edited, is changed for all places where it is used (that is, the internal node set-up, not the properties applied to the compound itself).
So, clone instances, versus clone templates or masters.

I have a UI suggestion for that: Clone templates (the "masters") could have an outline around them, a border, so they are like one unit, like a computer chip. As long as the outline is displayed, they are "masters" and every unlocalized instance follows their changes.

Once designated a localized instance, a compound's border disappears, and the components just become standard nodes.

I suggest than when you alter a compound master, a discreet user message be displayed (at the bottom of the edit window?) saying "Altering N instances", as a way of reminding the user s/he is futzing with more than just the visible local nodes.

Tobian
05-15-2012, 08:36 AM
The only difficulty with the 'make layers nodes' idea is that would transform all layers to nodes, and not everything in the layer editor is the same as in the node editor (many procedurals are missing for example). In other software, which have similar features as that, it's simply a question of re-represening the data in the shader. In Lightwave it is not. it's two distinct sets of data. Layers and nodes are different to each other, they just appear similar, to help with that transition.

Jim M
05-15-2012, 08:39 AM
Sorry I didn't make myself clear. Semantics. I was talking in a wishful present tense.
I was talking about how I would like it. Proper hooked up. Thoroughly.

Tobian
05-15-2012, 08:43 AM
Oh I get you, and it's something I'd have liked. I'd like the 'surface editor' replaced by custom ones, derived from materials and or compounds, where you can 'simply' amend data as you do in there, and even add 'textures' which would of course just add it to the node editor. I just know you can't do that with the surface/node editor as it's designed now.

Jim M
05-15-2012, 08:50 AM
I think it's quite good at the moment. I've used a few and it's largely accessable for creating most things.

kopperdrake
05-15-2012, 02:30 PM
Layers and Nodes are not different things, they just don't have the APPARENT connections with each other they should. When you set up a Layered Material, the Layer settings should propogate thoroughly and create a node network. The Node network being what is used by the renderer. The Layers being a quick access front end.

I like that idea, a lot. I'm in the same boat as people who find nodes daunting, and the work method does not click. But then layers is so like many other applications that have been around for so long that it makes sense mainly because that's what we learned years ago in Photoshop, or something else and, at the end of the day, it's just like layering pieces of paper on top of each other.

However, I do realise that nodes are immensely powerful, and for some projects very much worth setting up. We spent an afternoon making an 'oak wood' node, so we could cut a piece of wood from a solid block and it would have the grain of the wood through it, depending on where in the block you cut it from. However, you must really want to show an accurate oak wood grain to go to that trouble (and I'm not even sure if our attempt was that good).

I like the idea of a switch from layers to nodes and back again - monkey see monkey do is a good way to learn.

Tobian
05-15-2012, 02:54 PM
Yeah though the problem there comes once the very simple analogy wears out.. The reason to use nodes (over layers) is precisely in those areas when you can't just.. do it with layers: If all you are doing with nodes is replicating your setup of layers, why use nodes? The minute you do something with nodes which breaks the analogy, you have to fully go into nodes.

jeric_synergy
05-15-2012, 03:10 PM
Don't let "perfect" be the enemy of "good": while I accept that maybe layers are not completely a subset of nodes, there's PLENTY of overlap that would make the transition a hell of a lot easier.

So if, say, 85% of layering can be converted to equivalent networks, hey, there's a big opening right there.

Ernest
05-15-2012, 07:42 PM
Some of that depends on how it's managed. A compound as a preset/template is different from a compound that is referenced (essentially like a native node is).
The difference being: The former creates a local copy of the compound, if you edit it then it only affects the node graph where you added it.

The later would be a compound that, if edited, is changed for all places where it is used (that is, the internal node set-up, not the properties applied to the compound itself).

And it would certainly be good to have both types.

Cheers,
Mike

They don't have to be 2 kinds of compounds at all! :bday: There just have to be 2 kinds of "save"s.

When you save your scene and objects, it will always save the modified compound in your object (or in your scene, if they change that for Alembic) and will never affect the preset. If you click the "Save selected compound" button (or the "Save selected compound As...") button in the nodal panel, you will always be changing (or adding) the compound "template" on the presets menu without updating or re-saving your scene nor your objects.



Don't let "perfect" be the enemy of "good": while I accept that maybe layers are not completely a subset of nodes, there's PLENTY of overlap that would make the transition a hell of a lot easier.

So if, say, 85% of layering can be converted to equivalent networks, hey, there's a big opening right there.

Unfortunately, Tobian has a point. The "analogy" -never- breaks as long as you are creating your surface with layers and looking at the nodes that are created from it. (100% of layering can be converted to equivalent networks, if a few procedurals are added.) However, what happens when you don't just look at them on the nodes side? What happens if you do some tweaking on the connections and suddenly they can't be represented as layers anymore? How should the program respond when you try to switch to layers view again and the nodes are not representable as layers anymore? What if the user doesn't remember what they did and can't undo it and is stuck, unable to take his surface back to layers view?

A single, 1-way "convert all layers of this surface to nodes and activate nodes" button would probably be easier to implement.


(And having a new option added to the layer-type dropdown:
Image map
Procedural texture
Gradient
Node Network

could also be interesting)

jeric_synergy
05-15-2012, 07:47 PM
The operative word in my post was converted. @^@

speismonqui
05-15-2012, 09:55 PM
... node editors are used in many different programs, not just LW. Ever seen a typical node tree a completed project has in high-end video editing software? They get pretty crazy.

Indeed! :D
http://www.meyemind.com/tip/za12_r4p_scc.jpg

Lightwolf
05-16-2012, 01:30 AM
They don't have to be 2 kinds of compounds at all! :bday: There just have to be 2 kinds of "save"s.

When you save your scene and objects, it will always save the modified compound in your object (or in your scene, if they change that for Alembic) and will never affect the preset.
What if you want it to only save a reference to the compound though? I.e. have the surface update if the original compound changes?
Just as one has a surfaces using a new version of a node plugin automatically.

Cheers,
Mike

Jim M
05-16-2012, 02:13 AM
What happens if you do some tweaking on the connections and suddenly they can't be represented as layers anymore?

Well this has an existing behaviour currently doesn't it? When something is plugged into the diffuse surface the layers equivalent is greyed out.
I was thinking of a more intelligent and connected application where rather than considering the seperation as LAYERS vs NODES, we would have a Nodal system with a user adjustable front end that contains the familiar layer system with addition of user definable elements.

There is a basic surface setup that I constantly use. I would love to see user definable tabs in the surfacing pallette where one could expose nodal properties (and layer properties if it was implimented as I suggested, via node networks), and create a pallette of surfaces, parts of surfaces. One could even create a text field for making notes. Or a sketchbook for dropping unfinished or in progress networks, without having them calculated or messing up the renderable node networks.

This would create a fundamental change in as much as we could create surface/material assets with exposed sliders, numeric fields, notes and a variety of other options.

Let's say I create a complex brick material and pass it to someone who doesn't have the time to understand the ins and outs, all of the scale and postion parameters could be exposed into a user tab (and any other useful parameter when I create the 'asset'). This would also make sense when you come back to a surface 6 months down the line, you wouldn't have to relearn each complex network. And would also create a connection from 'front end/layers' to 'under the hood nodes', a bit more of a roadmap for people to understand the 'Functionality' of the node.

Over.
J

Tobian
05-16-2012, 05:11 AM
Yes but this would lead us to another problem too....

If you 'convert to layers' does it flush your layers and then copy them all to nodes. causing opengl feedback to die (nodes still can't be seen in OGL, and please don't say 'well make nodes work in OpenGL!') or leave in both sets, which the layers versions locked out.. which will be confusing if you didn't realise it would do that. Either version of the logic would be unsatisfactory.

Jim, I agree, that is what I was speaking of earlier. You create a compound, with complex innards.. You tell it which outputs and inputs to expose, so you can enter values or plug textures in (like you would before). You then allow the surface editor to show that compound in surface editor, instead of the material. This would create a very simple looking 'material' which had a very complex internal node network.

The problem again though is that while it may be possible to replace the viewability of nodes or compounds or materials in the surface editor, but that won't change the inherent nature of the difference between a classic surface and nodes, which are all just one giant multifunction shader (no opengl feedback etc).

As I mentioned previously Blender (with cycles) has this kind of expandable compressible ability. I watched a recent tutorial on this http://cgcookie.com/blender/2012/04/06/rendering-a-sports-car-in-blender-cycles-part-01/ and it does indeed look cool. Alas the surfacing system would have to be built from scratch in LW to make it truly work like this, so I'm hoping for simple viewability replacement in the surface editor pane :)

Jim M
05-16-2012, 05:16 AM
I say rewrite it. I might do it ;)

Tobian
05-16-2012, 07:35 AM
Knock yourself out Jim :)

Jim M
05-16-2012, 07:38 AM
I am doing it right now. It hurts.

Bill Carey
05-16-2012, 09:49 AM
Indeed! :D
http://www.meyemind.com/tip/za12_r4p_scc.jpg

That just looks like job security, lol

jeric_synergy
05-16-2012, 10:02 AM
Indeed! :D
http://www.meyemind.com/tip/za12_r4p_scc.jpg
Ugh.

That's what the kids at art school want to do, fer sure.

zarti
05-16-2012, 11:15 AM
Indeed! :D
http://www.meyemind.com/tip/za12_r4p_scc.jpg

Spasmic !! ! . ! . ,

jeric_synergy
05-16-2012, 02:18 PM
Its like saying "its more natural to me to drive my car everywhere in reverse".

If you want to learn to use something, its almost always best to learn it (at the very least at first) in the way it was designed to be used.

Plus I dont even know what you're talking about when u say "these conventions"...
Finally found an example, thanks xswampyx! :thumbsup:

Since you asked: TO ME, the simple network pictured below is easier to understand Right to Left because TO ME it's easier to think of it as:

the Destination Node (Displacement) running thru all the points in the mesh sequentially, saying "Where to?" and looking at its input.
That number comes from the Scale(2) node (pure number)
Which comes from the Part Move node (confusing dox) and
The Multiply node (pure number)
and here's the confusing part to me
The Weight Map node.

TO ME, the confusing part (in this very simple network) is that there seems to be a sort of "invisible channel" between the Displacement Node, which is just running thru the list of points, and the Weight Map node several connections away. The "invisible channel" tells the Weight Map node which point the network is currently addressing. It's like the Destination node requests from the Weight Map node "please present the value of point(n) at your output". Invisibly.

That because, to me, it makes "sense" that the Displacement node is the one with the point list:

'Cuz it's the one concerned with points. The w.map node has the same list (or a subset), of course.
And the Displacement node is, to me, kind of "the boss".

Sure, the w.map node could be the boss, but there could be all sorts of nodes at its level, while there will only ever be one destination node. So, the destination node should be "the boss". In my mind.

And there'd STILL be the "invisible channel", because there's no (visible) point index coming out of the Weight Map node. Somehow the proper w.map value needs to be matched to a specific point. This invisibility for me has been a stumbling block to understanding nodal methodology.

So, there's my list of misconceptions. A different way of thinking about nodes would probably be more fruitful.

Jim M
05-17-2012, 02:37 AM
Jackson Pollocks.

[EDIT] + Jeric, I like your mental sketch. What you say makes sense, and probably indicates you understand whats going on :)

jeric_synergy
05-17-2012, 07:36 AM
[EDIT] + Jeric, I like your mental sketch. What you say makes sense, and probably indicates you understand whats going on :)
Except, my conceptual issues re: the "invisible channel(s)" prevent me from constructing networks. After someone else has built one, I can sorta suss it out, but constructing them is downright painful. :(

RebelHill
05-17-2012, 08:18 AM
Ok... so i see some of what you're saying and how you're trying to think about it (though i asked for an example of what was so confusing about spot info, not why do u read backwards... but anyways).

I can understand how ur trying to think about things... I imagine that the 2 parallel networks to the left that "merge" before going to displacement cause you to want to read it backwards... but again... this one is still simpler to understand read left to right.

So lets look at it.

Ok, first of all... we need to remember exactly what it is that displacement DOES... Basically, it takes the vertices of a mesh, and moves them.

So this leaves us with 2 data components (quite obviously).

Which vertices are to be moved, and by how much.

So first lets create a selection (or selections) of verts. This is in part what DPs part move does... so we start there as part move splits out object up into "parts"... little collections of verts linked together.

Now part move is interesting, because it also performs the MOVING of those verts... So they are already going somewhere as a result of this node.

However in this case... we want to vary exactly how much each vertex will be moved, so we need to provide an instruction of "move amount/scale" for each vertex.

For this, we can just use a VERTEX MAP.

So we can now take these 2 pieces of data... the movement (displacement) of the vertices being performed by Part move, and the VMap to get more specific control.

Left to right then (and top to bottom in this case, though taht wont necessarily be the norm)... it reads as follows.

1. Select which verts to move, and move them.
2. Get/Set a value for how much each individual vert should move relative to the others.
3. Modulate the first action by the second set data.
4. Execute.

And thats it.

The multiply node only really serves to ramp the weightmap up and down... easier than going back to modeler and having to tweak it, so in a way, its kind of irrelevent to the reading of the network. But there is NO "invisible" channel... thats ur imagination, and its caused by your reading the process backwards. Honestly... just look at my simple 4 point list of actions... now read it backwards 4-1... Doesnt make sense does it. (well it does, just not as PLAIN sense). its a PROCEDURE of things happening in a certain ORDER.



Again... take a good look over my nodal thinking video... http://www.youtube.com/watch?v=nGKwqL89LaA it explains a fair amount about this "little pieces, connected together" process.

jeric_synergy
05-17-2012, 10:15 AM
First off, MANY thanks RH for taking all this time and effort. I hope I'm not the only one profiting from the discussion.

Onward:

I can understand how ur trying to think about things...
Just to clarify: I'm not trying to think this way, it's just that "this way" gets me closest to understanding (more later)-- but I'm not make an effort to shoehorn this methodology in.

I'm not defending my thought processes here ('cuz obviously they are detrimental to understanding nodes), I'm just trying to explain them.

So this leaves us with 2 data components (quite obviously).

Which vertices are to be moved, and by how much.

So first lets create a selection (or selections) of verts. This is in part what DPs part move does... so we start there as part move splits out object up into "parts"... little collections of verts linked together.

Now part move is interesting, because it also performs the MOVING of those verts... So they are already going somewhere as a result of this node.
See now, it seems to me that conceptualization is wrong: the Displacement Node is what does the actual moving. It seems to me that Part Move does the selection process as you say, and accepts transformation parameters, but the actual moving is put off until the Displacement Node because, obviously, the move is modulated by downstream nodes.

However in this case... we want to vary exactly how much each vertex will be moved, so we need to provide an instruction of "move amount/scale" for each vertex.

For this, we can just use a VERTEX MAP.

So we can now take these 2 pieces of data... the movement (displacement) of the vertices being performed by Part move, and the VMap to get more specific control.

Left to right then (and top to bottom in this case, though taht wont necessarily be the norm)... it reads as follows.

1. Select which verts to move, and move them.
2. Get/Set a value for how much each individual vert should move relative to the others.
3. Modulate the first action by the second set data.
4. Execute.

And thats it.


. But there is NO "invisible" channel... thats ur imagination, and its caused by your reading the process backwards. Honestly... just look at my simple 4 point list of actions... now read it backwards 4-1... Doesnt make sense does it. (well it does, just not as PLAIN sense). its a PROCEDURE of things happening in a certain ORDER.
No matter which direction the network is "read", specific vertices are eventually associated with specific displacement vectors. This index into which vertex is being addressed at any given time is what I mean by "invisible channels", which in my imagination are part of the internal/invisible plumbing of the nodal system.

Even in your explanation, the question arises, "how does the Weight Map node know WHICH w.map value to present at its output?" There's no visible connection between the Part Move node and the Weight Map node, if the Part Move node is doing the selecting of vertices. My notional answer is "the assumption underlying the network is that we are working on individual vertices, so nodes present information related to the current vertex." --Which btw is what I meant by "assumptions and conventions" in an earlier post. --So, in my imagination, the Displacement node holds up a vertex and says to its minions, "OK, what about this one???" Every node subservient to the Displacement node (i.e., all of them), knows that whatever value it presents must relate to that vertex.

So, my view is extremely linear-- at any given time, numbers are presented at outputs. My confusion is how those numbers are determined from the cloud of numbers available, in this case, in a Weight Map, but also from other nodal entities.

This linearity is probably not doing me any favors.

Again... take a good look over my nodal thinking video... http://www.youtube.com/watch?v=nGKwqL89LaA it explains a fair amount about this "little pieces, connected together" process.
Loading it now.

Thanks again. Just typing my thoughts have leant them clarity, although I hope I'm not just solidifying incorrect concepts.

RebelHill
05-17-2012, 10:38 AM
Displacement Node is what does the actual moving.

NO... the geometry engine in LW is what does the moving. The displacement node (along with any of the other object/mesh displacement/distorting tools) is just something you enter a value INTO in order for the geo engine to get an instruction.

The displacement node isnt "asking" the network what to do... the network is TELLING.


how does the Weight Map node know WHICH w.map value to present at its output?" There's no visible connection between the Part Move node and the Weight Map node

Cos thats what a weight map IS... Each vertex has a value assigned to it in that map. I can clearly see where you're going wrong here... you're thinking "this vert, that vert"... WRONG... its ALL verts, all the time.

And ofc there's no "visible" connection between part move and the weightmap... or rather there IS... its the vector scale node... which takes the action info from part move, the info from the weight... and drives the first using the "filtering" from the second... thats all there is to it.

rcallicotte
05-17-2012, 10:51 AM
LOL

I'm glad you visit and share with this forum, RH. Otherwise, I would not be able to learn from what you think is so simple. :D



And ofc there's no "visible" connection between part move and the weightmap... or rather there IS... its the vector scale node... which takes the action info from part move, the info from the weight... and drives the first using the "filtering" from the second... thats all there is to it.

jeric_synergy
05-17-2012, 11:21 AM
NO... the geometry engine in LW is what does the moving. The displacement node (along with any of the other object/mesh displacement/distorting tools) is just something you enter a value INTO in order for the geo engine to get an instruction.
That seems like a distinction without a difference: the Displacement Node is the entry for the geometry engine for that mesh.

The displacement node isnt "asking" the network what to do... the network is TELLING.
Well, yeah, like Bones tell the geometry engine what to do.

I can clearly see where you're going wrong here... you're thinking "this vert, that vert"... WRONG... its ALL verts, all the time.
???? But surely at a programmatic level they are addressed one at a time? 'Cuz I doubt LW is that heavily parallel coded (if at all).

Only one value, one number can be present at a time on output, no? How is that not sequential?

And ofc there's no "visible" connection between part move and the weightmap... or rather there IS... its the vector scale node... which takes the action info from part move, the info from the weight... and drives the first using the "filtering" from the second... thats all there is to it.
I still think something, some assumption, is being glossed over. Is there a practical difference between "all points, all the time" and "we'll all agree to work on the same point at the same time."?

RebelHill
05-17-2012, 11:35 AM
who CARES if internally LW is looking at each point, one at a time, or just doing them all in parallel?? The nodes provide access to ALL the points at the same time (or within the same node I should say)... thats it, end of story.

There's no assumption being glossed over.

Again... go back to my step 1,2,3,4... its just a very basic procedure. Look up one bit of info, look up another, use the second to modify/filter the first... heres the result.

I mean u say "bone tells geometry"... yes, YES... its the EXACT same thing. The bone IS a node y'know (in an under the hood sense). It just so happens that it gets drawn in the viewport and given a pointy icon, cos its pretty much only got the one (main) use. And like ANY node, it has inputs and ouputs. The inputs can be found in its properties or motion options panel... its outputs can be found in the graph editor (XYZHPBXYZ).

Tobian
05-17-2012, 11:37 AM
Yeah I think you nailed it there RH, it's not just any particular point, it's all the points that it applies too...

Nodal execution is always right to left (blame western writing :D)

Get information > apply operations to it (multiply divide etc) > Excecute.

Sometimes you don't need to 'get' the information because it's already included in a particular tool, such as say a diffuse shader. You don't need to plug a 'spot info> normal' into it, because it includes one by design (to save you having to do it) but it has a normal input, in case you do want to plug a modified normal in there, other than the one it is programmed with. Most shaders in this way are simply a complex set of operations collapsed into a single, simple to use tool. As RH shows in that example with the dot product is in essence a very basic diffuse shader, which draws a gradient on a surface based on it's facing to a null (instead of a light) you could then take that, multiply it with a colour and voila, you have an extremely simplistic diffuse shader. The classic surface is just a pre-baked compound of shaders, which you just multiply with some textures and voila.. a surface. The use of the node editor is that you can get at all of the individual bits of it and mess around with them and combine them in a custom way, which just was not possible before.

I guess the disconnect is when the 'get' and 'excecute' is invoked, as something like displacement or a shader occur at different times:

In the terms of a shader, it is invoked whenever a camera ray hits it... So a camera ray flies out of the camera, hits the geometry, and invokes the shader: The shader gets all the relevant info, for that 'spot', applies all of the operators and returns a value to the camera. In the case of a complex shader, like reflection or refraction, it will need to continue on to the next branch, and so on down the line, until it's stopped (the ray recursion limit) or it hit's the background. In terms of a shader, the number of possible samples are infinite, but the only ones which are calculated are the ones required by the camera, when it fires a ray to that point. (spot) The spot on this case is simply an abstract, representing the point which the camera ray is questioning.

In terms of a displacement, it's whenever that data needs to be computed, such as for openGL display or at render time (render time SubD might make the mesh have a different set of points.) Again.. get all of the relevant data (normals, weight maps, textures) apply the operators to them (multiply, add etc) and then compute returns that to the geometry, and therefore it's displaced. In this case the 'spot' is therefore every point of that particular mesh. If you only want it to apply to a specific part of the mesh, then that's when tools like the 'part' tool from DP or weight maps come in.

RebelHill
05-17-2012, 11:45 AM
As RH shows in that example with the dot product is in essence a very basic diffuse shader, which draws a gradient on a surface based on it's facing to a null (instead of a light) you could then take that, multiply it with a colour and voila, you have an extremely simplistic diffuse shader.

Actually thats exactly what the Lambertian shading method is. The normal vector of an incoming light ray (dot) the normal vector of a polygon its hits, with the brightness (of the colour gradient) multiplied by the light strength.

Take a mesh, and a null, setup the netwrk, the gradient etc... boom. Effectively your null is now a light and the network is a Lambert shader.

jeric_synergy
05-17-2012, 01:29 PM
who CARES if internally LW is looking at each point, one at a time, or just doing them all in parallel??
Me. Because there's a subtext/assumption of "...of this vertex" that I wasn't getting.

To me, a Weight Map node could be any of the 12,734 weights in that weight map. It's the whole enchilada. (You keep saying "it's all of them at once". But all of them are not applied at once.) Once the assumption/convention of "...of this vertex" is added, then it makes sense to me.



...... it's not just any particular point, it's all the points that it applies to...
Which (point) is defined by the destination node.

RebelHill
05-17-2012, 02:16 PM
To me, a Weight Map node could be any of the 12,734 weights in that weight map.

But WHY would you think that??? Is there ANY other area of LW where weights work that way... surface editor, bones??

No, ofc not. A weightmap contains ALL of the points which have association to that map.

I think I was right a few pages back... uve overthought, and overcomplicated things needlessly, and that's what's confusing you.

jeric_synergy
05-17-2012, 02:33 PM
But WHY would you think that??? Is there ANY other area of LW where weights work that way... surface editor, bones??

Well, let's take Bones. In my mind, when the influence area of a Bone intersects a given point, that point is queried as to its w.map, and the influence of the bone is modulated accordingly.

UnCommonGrafx
05-17-2012, 02:41 PM
Ha,
Like a petulant student, "I think it's this way so why isn't it!?"

This has been some GREAT information. Thanks for pulling it out of them, jeric. ;) And thanks to all the explainers for taking the time to be so clear with your examples.

Gonna look at RH's stuff during my two month vacation: it's so simple it's complicated - I need as much time as I can afford to digest it all.

I would enjoy seeing James' vid again with Viper, too.
Lots of node vids to be watching this summer.

RebelHill
05-17-2012, 02:48 PM
Well, let's take Bones. In my mind, when the influence area of a Bone intersects a given point, that point is queried as to its w.map, and the influence of the bone is modulated accordingly.

Yes... but it happens for ALL points... makes no difference if LW is going through the vertices one after the other, or doing them in parallel... NO DIFFERENCE, because no matter which way round it is, you CANT interfere with that process in any way... thus, its irrelevant.

My point, however, was that when u use a weightmap anywhere in LW there is NEVER a "point by point" element/control (because LW does its point by point thing in whatever way it does it) to it... why would it have so in nodes??

Its just a map.

jeric_synergy
05-17-2012, 02:53 PM
Ha,
Like a petulant student, "I think it's this way so why isn't it!?"

This has been some GREAT information. Thanks for pulling it out of them, jeric. ;)
Harumphphp, I'm not sure how to take those two statements together. :D :tongue: :bday:

I'm slowly wading thru the pile of node videos myself. It's painful.

My gratitude to RebelHill and everybody who makes a contribution. It's just a fact that some students have a heck of a time acquiring a model that allows them to be productive, no matter how natural something may seem to others.

RebelHill
05-17-2012, 02:56 PM
Not trying to be mean here Jeric... honestly.

But when someone says "this is natural to everyone else but me"... the thing that usually needs to be changed, is the person making the statement.

jeric_synergy
05-17-2012, 03:04 PM
Not trying to be mean here Jeric... honestly.

But when someone says "this is natural to everyone else but me"... the thing that usually needs to be changed, is the person making the statement.
First off, I never said that. I'm guessing it's more than just me: maybe 15% of users? 5%?

Certainly others are profiting from this exchange, so there's that.

Also, I'm not suggesting others have to change how they approach nodes, I'm trying to find a way to make sense of it that works for me. I'll try one way, then the other. But I can't find out the other ways unless I discuss it somewhere.

RebelHill
05-17-2012, 03:15 PM
I know you are... but its designed to be used a certain way, and I can guarantee you'll find it far more productive in the long run to approach it in the way it was meant to be approached rather than find some alternative that can shoehorn in somehow.

You ARE overthinking, Jeric... honestly you are. This whole "does LW do it point by point or all at once" thing which makes no difference and which is utterly irrelevant is a perfect example of that, and the result is that you are making it more complicated for yourself than it needs to be, or actually is.

dwburman
05-17-2012, 04:41 PM
Keep in mind that all the points in the mesh have unique ID numbers so the weight map is setting a particular weight value on a particular point, so the order in which it is querried doesn't matter.

You can think of a multiply node (and the vector scale node for that matter) as a volume knob. If it's turned all the way down (0.0), the value is off (brightness or position or whatever you have plugged into it). If it's at all the way up (1.0), the value is at 100%. If you turn it up to 11, you're pushing the value higher than 100%.

In terms of your part move setup, you can think of the weight map as a filter/matte for the effect. If you didn't have the weight plugged in, and set the scale to 1.0 then every point in the object will be moved the same amount. The Weight Map is being used like a matte channel on an adjustment layer in PS or AE.

The way I read that node setup is:

Part Move (taking into account where things are) tells Vector Scale, "Move the point in that direction."
Vector Scale says, "how far?"
Weight Map tells Vector Scale (with Multiply adding his two cents), "move it this far"
Then Vector Scale compiles his notes and puts the order through to dispatch (Displacement).

probiner
05-17-2012, 05:17 PM
Ahhh...

Imagine this:

Stackable Node trees. You displace the mesh with in a first event. Then you subdivide in another. Then you displace it again with new normals :D

It wouldn't be more than an item in the Stack... or instead, a Compound that solves first than the rest from where the Spot Info node can retrieve new normals.

jeric_synergy
05-17-2012, 05:28 PM
Keep in mind that all the points in the mesh have unique ID numbers so the weight map is setting a particular weight value on a particular point, so the order in which it is querried doesn't matter.
Yeah, I get that. Using the word "sequential" probably confused that. It isn't the order per se I was stressing but how the data (point index, w.map value) connected together.



The way I read that node setup is:

Part Move (taking into account where things are) tells Vector Scale, "Move the point in that direction."
Vector Scale says, "how far?"
Weight Map tells Vector Scale (with Multiply adding his two cents), "move it this far"
Then Vector Scale compiles his notes and puts the order through to dispatch (Displacement).
Thanks Dana.

Tobian
05-17-2012, 06:38 PM
Probiner.. a nodal displacement stack for the object, allowing you to decide what happened when, in a custom way would be superb, especially if subdivision was in there. Fantastic for landscapes!

and Jeric, I really am confused about what it is you don't get now. All displacements do is move a point along a user defined vector, which is multiplied with other data such as textures and weight maps. Just like you would use the move tool with a falloff, you use a texture or weight to control how much something is displaced, by multiplying that with your displacement.

The problem is most of us don't actually know how it all works either.. I just plug a bunch of sh*t into another bunch of sh*t, find what works, and then work backwards to figure out what it's doing. I didn't know what multiplying a scalar with a normal vector actually did until I had a think about it, and now it makes perfect sense, but I knew if I did it, then it worked. Sure, granted, discussing it has allowed me to expand my thinking, and grasp it, for my own internal processes, but I could use it fine before I understood the maths, because mostly I use nodes a lot and repetition is the only way to learn. It's not second nature, it's learned.

Your sticking point is you don't seem to want to accept that X does Y, you're looking for hidden channels and secret handshakes and confusing everyone. It's nodes, it's not the freemasons! :) Ok I think I have had enough now. There's only so many times I can explain it before I can't any more! :)

Ernest
05-17-2012, 08:11 PM
What if you want it to only save a reference to the compound though? I.e. have the surface update if the original compound changes?
Just as one has a surfaces using a new version of a node plugin automatically.

Cheers,
Mike

Honestly, I can't imagine anyone ever wanting that kind of behaviour. It seems nice in the short term. But imagine if you render a sequence and 2 years later you want to re-render some frames of it. You have no way of replicating the look because who knows how many changes have happened in how many compound nodes in those 2 years!

It works for versions of the renderer because you have 1 version change every year or two (or four) (and not all of them change the look of older scenes). With Compound nodes that may change 3 times per week, it would be an uncontrollable nightmare. Remember DLL hell back in the old Windows? Now imagine it with user-modifiable dlls!

What you really want is the compound node saved with your object or scene in exactly the form it had when you added it. You want a "save selected compound node" button so that, if you improve the compound node, you can save the changes permanently in the preset or create a new preset. And you want an "Update selected compound node" button to update the node to the latest version of the preset when you actually (consciously) want that to happen, and then you can save your object or scene with those changes.

dwburman
05-17-2012, 09:15 PM
Yeah, I get that. Using the word "sequential" probably confused that. It isn't the order per se I was stressing but how the data (point index, w.map value) connected together.


They are both stored in the object.

The item info is saying here's point#63 (it's position relative to the object origin). Part Move is telling Point #63 and connected points move in that direction. Meanwhile, Weight Map is saying, "point #63, ah yes... that's set to 50%"

So Item Info and and Weight Map aren't linked yet (that happens at vector scalar), but they are looking to the same location (point #63) to see what attributes it has.

You could imagine both the Item Info node and the Weight Map node having a line that goes all the way over to the object in the Scene Editor.

jeric_synergy
05-17-2012, 10:22 PM
They are both stored in the object.

The item info is saying here's point#63 (it's position relative to the object origin).
Actually, in this particular case the Item Info node is referencing a Null Object that is used to increase the kerning in the text mesh. The text mesh is what's being displaced.

But I think we're agreeing that all the pertinent nodes are looking at the same point.

Attached the scene.

zarti
05-18-2012, 02:25 AM
Honestly, I can't imagine anyone ever wanting that kind of behaviour. It seems nice in the short term. But imagine if you render a sequence and 2 years later you want to re-render some frames of it. You have no way of replicating the look because who knows how many changes have happened in how many compound nodes in those 2 years!

It works for versions of the renderer because you have 1 version change every year or two (or four) (and not all of them change the look of older scenes). With Compound nodes that may change 3 times per week, it would be an uncontrollable nightmare. Remember DLL hell back in the old Windows? Now imagine it with user-modifiable dlls!

..

a bit contradictory or too much imagination maybe ..

first , if you have models and scenes 'archived' , why wd you not 'archive' the compounds too ?!

second , the compatibility with renderer versions is in the hands of devs .
any renderer Should be backward compatible ; and when you are rerendering in the days of its 23rd version , you should have the option to tell to the renderer to behave like its 15th version .

third , if compounds itself once were part of a scene , you can and should save that scene too .

fourth , compounds should have versionin abilities too .



--
all i described above is Based on Real Life Events .. =)

.cheers

Ernest
05-18-2012, 04:48 AM
first , if you have models and scenes 'archived' , why wd you not 'archive' the compounds too ?!
Exactly! I'm glad we agree. The compounds that are used in the surfaces should be archived in the object or scene and the compound's definitions or presets should be stored in Lightwave, in the nodes panel.


second , the compatibility with renderer versions is in the hands of devs .
any renderer Should be backward compatible ; and when you are rerendering in the days of its 23rd version , you should have the option to tell to the renderer to behave like its 15th version .
Exactly! I'm glad we agree. That is why renderer changes do not cause terrible problems but compound changes would, if we saved only a pointer to the compound preset and not the full compound instance (the node compounds can be changed by users uncontrollably at any time).


third , if compounds itself once were part of a scene , you can and should save that scene too .
Exactly! I'm glad we agree. (I think)



fourth , compounds should have versionin abilities too .

Ideally, but I can live without something that might be so complicated to implement smoothly, considering what Jin called "Soviet development" or something like that. "Save Selected Compound As..." and a decent Undo are the only versioning system that would be absolutely necessary.

Lightwolf
05-18-2012, 05:24 AM
Honestly, I can't imagine anyone ever wanting that kind of behaviour.
It's probably a problem of nomenclature I suppose.
What you see as a compound is what I'd describe as a group. A compound is something that I'd consider to be more like a plugin (but built out of nodal building blocks).

If you're familiar with Fusion, the difference between their groups and macros.

Cheers,
Mike

zarti
05-18-2012, 11:38 AM
just wanted to add this :

- within "presets" should be saved two kinds of data in a tree-like structure :
ui configurations ( different exposed parameters )
parameter values ( belonging to its own ui )



imho , presets shdnt represent a compound . thats another song ..



.cheers

Taran-Q
04-21-2013, 11:03 AM
For me as an old timer the node editor is mostly chinese to me, would love to learn more but far to little documentation, tutorials and videos to explain in understandable terms.
The node setup examples I find every now and than are often complex or I can't seem to figure out it's connections, and the few times I think I can and want to try it myself I mostly get stuck somewere along the way ....

chikega
04-21-2013, 01:04 PM
For me as an old timer the node editor is mostly chinese to me, would love to learn more but far to little documentation, tutorials and videos to explain in understandable terms.
The node setup examples I find every now and than are often complex or I can't seem to figure out it's connections, and the few times I think I can and want to try it myself I mostly get stuck somewere along the way ....

RebelHill's Nodal Tutorials helped me tremendously. I happen to have Modo as well and the ShaderTree (stacked-based) was more fiddly for me.

jasonwestmas
04-21-2013, 04:12 PM
The LW node editor allows me to better visualize my usage of alpha channels and texture masks, it's a way I like to work for complex surfacing with UV maps (vertex level control projecting pixels on polygons). Someone who is unfamiliar with the way I layout things or why I work the way I do, it is useless to them. . .but for me as a creative person it's great. It's kind of like short hand writing where I am able to "sketch" things out more quickly than I can with older methods. I'm glad companies like NT give me that capability.

shrox
04-21-2013, 05:01 PM
Scary is the node editor, master it you must.

113777

I haven't yet...

adk
04-21-2013, 05:02 PM
Apart from RH nodal videos (which are brilliant), there is also this by James Willmott (which is a great intro into nodes + some advanced stuff too) ...

http://www.liberty3d.com/2012/03/node-based-surfacing-video-2/

Spend some time learning nodes & you will wonder how you did without them. Personally, nodes are one of the major reasons I use LW.

probiner
04-21-2013, 05:05 PM
It's a language, just need to learn some of the basic rules, interactions and order of things and then go crazy and prepare for a lot of sweating doing all by hand :D I like the power of Node editor and what allows, I just feel that the setup flow is quite slow.

Cheers

DrStrik9
04-21-2013, 08:32 PM
NODES! <gasp!>

113780

jeric_synergy
04-21-2013, 09:54 PM
This thread is.... un dead!!!! :)

I too recommend RH's nodal tutorials. Then watch them once a month.....

akaracquel
04-22-2013, 03:33 AM
The Rabbit Hole. Have run into Alice more than once getting lost in the node editor. Sometimes, she does very mean things to bunnies and forces them smoke pot, so the bunnies often have evil looking eyes when their heads start popping out of the ground & onto a surface.

Tobian
04-22-2013, 08:08 AM
NODES! <gasp!>

113780

Love this /\ gets me every time :D

BigHache
04-22-2013, 07:25 PM
RH's Nodal tutorials are one of the best software purchases I've made. You can live life without nodes, but that's also like living in AE without ever using expressions. You CAN, but I don't want to.

jeric_synergy
04-23-2013, 08:23 PM
Sometimes, she does very mean things to bunnies ....
Sometimes?