Seems to me like you confound things a little.
First you say it's downstream

This really is a pipe with data pushed down through the nodes.

Then you suddenly say it's upstream

Well, the truth is, it's all about upstream, not downstream. Node with display/render flag asks for a geometry its input node and so one recursively. Does't matter. The theory is quite correct. CopySOP isn't any exception from that. That's why you have to use stamp(), which the only reason to exists is to ask downstream node for the attribute existing there

I would say Houdini is all about downstreambecause that's the only answer why there is something like detail() or stamp() necessary anyway. If it would be upstream these wouldn't be needed because the attribute/variable is created before it is evaluated and it everything is fine. So the upstream theory doesn't work out as well.

Now, back to Maya, the familiarity effect last two weeks, and then you end up with usability issues for the rest of the time. Adsk decision for mirroring MEL commands with Python was good only for people using ~15 commands casually. Anyone using scripting intensively curse Adsk. It's ironic you compare the worst Python implementation in business with one of the best saying how good is to actually break Python, lost its object oriented nature and mirror it with ancient and horrible dialect that no one really wants to use these days. Thank god ,the Foundry wasn't doing the same with TCL to Python transition in Nuke…

I think we should get clear about the difference of Python as a scripting language and Python as an expression language. As a scripting language it should keep its object oriented structure but as a expression language this is like taking a sledgehammer to crack a nut.

You can actually use AttributeCopy there. Just use the attribute after you have copied it… Leave Line Sop alone, copy your attribute, add PointSOP for example, ad type in TY field the same expression with $PT multiplication:

detail(“../attributecreate1”, “height”, 0) * $PT

I have to copy the attribute and then I still would have to use detail() to get the attribute?
This is more workaround then just using the expression on the line SOP or am I missing something?

You can, with AttributeCopy

No I can't. I can't shuffle that attribute in before the line SOP, so that it is utilizable there. I can only shuffle it in after the line SOP where it is basicly needless.

Korny Klown2
I would say Houdini is all about downstreambecause that's the only answer why there is something like detail() or stamp() necessary anyway. If it would be upstream these wouldn't be needed because the attribute/variable is created before it is evaluated and it everything is fine. So the upstream theory doesn't work out as well.

That's cool but does it fit with Mr Lait's “Cooking is Bottom-Up” notes:

http://www.multithreadingandvfx.org/course_notes/MultithreadingHoudini.pdf [multithreadingandvfx.org]

Korny Klown2
Seems to me like you confound things a little.

I did it for a sake of explanation. It's doesn't really matter how things are internally, since as far as I know they are much more complicated to allow this kind of ingenious which SOPs are. Conceptually particular nodes handle each other complete copy of a geometry (which isn't completly true these days, but anyways), which flows down like in bucket of water in a pipe.

So the upstream theory doesn't work out as well.

It's not theory. The node with a display/render flag turned on starts to cook. First it asks its first input node for a geometry to work with, so this first input node starts working on that geometry by first asking its first input node for a result of work, the geometry, so this third node in a row starts cooking by asking the node before for the geometry…. and so on.

I think we should get clear about the difference of Python as a scripting language and Python as an expression language. As a scripting language it should keep its object oriented structure but as a expression language this is like taking a sledgehammer to crack a nut.

That's exactly what I was trying to explain here, don't use Python in expressions. Period. There are rare cases it fits, most of the time, it does't.

You can actually use AttributeCopy there. Just use the attribute after you have copied it… Leave Line Sop alone, copy your attribute, add PointSOP for example, ad type in TY field the same expression with $PT multiplication:

detail(“../attributecreate1”, “height”, 0) * $PT

I have to copy the attribute and then I still would have to use detail() to get the attribute?
This is more workaround then just using the expression on the line SOP or am I missing something?

You have two choices: anytime you want to use custom attribute you either use expression or variable (if variable mapping is present). If you copy two detail attributes present there in your file, height and varmap, you can use $HEIGHT instead of detail()

It's not workaround, it's the same thing you've been doing. It's pointless, true, because instead of creating detail attribute, copy it and such, you can reference both extrudes parms in LineSOP parameter, but it wasn't my idea You should simply copy/paste the expression from attribcreate1 to distance parm of LineSOP.

You can, with AttributeCopy

No I can't. I can't shuffle that attribute in before the line SOP, so that it is utilizable there. I can only shuffle it in after the line SOP where it is basicly needless.

You can't for the same reason you can't shuffle channels in Read node in Nuke. It's a generator, you don't have geometry to copy on yet. But it doesn't mean you can't shuffle after Read node, and the same here. Sorry I don't get why it's needless? You create line, then you modify its shape as you go. There are dozen of ways of doing your setup, from which detail attribute is perhaps the least handful, but it does work too.

This topic could be renamed ‘Attribute Create and the Atomic structure of Houdini’

On the issue of understanding AttributCreate; there appears to be a lot of baggage and pre-conceived ideas confusing its operation.

It's interesting that experienced SI or Maya users find Houdini a god-send whilst people with less experience don't. Why is that?

MartybNz
It's interesting that experienced SI or Maya users find Houdini a god-send whilst people with less experience don't. Why is that?

Probably because the less one is expirienced, the less “poluted” one is.
I'm just kidding but the true concept I see behind that is that the longer you are dealing with something and the more expirienced you are the more you start to “get used to it”, getting used to bad habits and so. However the less you are expirienced, the less you are used to bad habits and still have the fire in your heart to make the world a better place. This maybe, for some (arrogant) people, sounds stupid/naive but look at the history. Changes were always made by people that were either young/unexpirienced or kept the fire inside burning as if they were young and unexpirienced. Anyway, there's one thing they all have in common, they didn't “get used to it”. But this probably is a more general discussion instead of Houdini specific.

This may be a little different but usually the younger would go and create it themselves, though, not ask others to change things.

It's the ‘screw you, I can do it better ’ attitude. Works if it is actually better

If I would have a little more programming expirience, MUCH more time and a few freaky friends that are willed to help me on this for free, because I don't have the money to pay them, I surely would have already started something on my own.
Something like an open source procedually, nodebased 3D software project….but I'm just daydreaming

Korny Klown2
Changes were always made by people that were either young/unexpirienced or kept the fire inside burning as if they were young and unexpirienced. A

Let me disabuse you of this paperback myth; hint age is not the key, vision and skills are.


Exhibit one. The Internet, packet switching not the WWW.

Licklider
http://en.wikipedia.org/wiki/J.C.R._Licklider [en.wikipedia.org]

Taylor
http://www.utexas.edu/ogs/alumni/events/taylor/recap.html [utexas.edu]


Exhibit two. Personal computer usage.

Parc research, ~ the right 30 people and in todays dollars. an investment of $10 million a year for 4-5 years, $billions for Xerox- laser printer, world economy returned ~33 trillion over the years for others, ehternet, postscript, wyswyg Dip, Pc gui, bitmap screen, peer-peer client / server etc
http://en.wikipedia.org/wiki/Xerox_PARC [en.wikipedia.org]

Exhibit three: Computer interaction

Sutherland's Sketchpad
http://images.designworldonline.com.s3.amazonaws.com/CADhistory/Sketchpad_A_Man-Machine_Graphical_Communication_System_Jan63.pdf [images.designworldonline.com.s3.amazonaws.com]

edited: the Parc research details

MartybNz
Let me disabuse you of this paperback myth; hint age is not the key, vision and skills are.

Of course age is not the only thing that matters in this context but anyway, you got my point.

ya - but what I read in this topic here is not so much a bad implementation of Python or Attributes but the need to skill up in these areas. What do you think?

Although I generally agree with you, that one should never stop learning and skilling up it's not so mush about skilling up for me, my concern is rather work efficiency. It's not that I'm not skilled enough to use Python the way it is right now, it's just inefficient/brain and time consuming. As I said, we should distinguish Python for scripting and Python for expression. First of all having entirly different functionnames for the same tasks sucks because this is right the point Bret Victor discribes in his Learnable Programming article you linked here. He correctly complains about that as a programmer you spend too much time looking up documentations and this, in this context, could be easily prevented if Python expression functions would have similar names as HScript expression functions.
A nice quote from the article:

…so the learner can concentrate on high-level concepts, not vocabulary.

I absolutely endorse Sesi hiring Bret Victor as a consultant for future visionary Houdini development!

Quite an impressive CV too. i.e original iPad interface work and many amazing tools and ideas. The Kill Math project is rad.

The whole site is rad.
http://worrydream.com [worrydream.com]

This is so true for Houdini. Amen brother!

http://vimeo.com/71278954 [vimeo.com]

…technologie changes quickly, peoples minds change slowly.

Korny Klown2

…technologie changes quickly, peoples minds change slowly.

This is the classic innovator's dilemma . If you change a product too much then old customers flee bankrupting the company, don't change it and the customer's flee to the new innovative product.

Interestingly Bret might have been part of the team that redesigned FCPX at Apple, according to his CV, when that released it was junked by the industry and has taken a few years to start becoming accepted. Whilst Apple's deep pockets and multiple product categories can sustain that, how could Sesi.

One solution for a radical change is to introduce it slowly, or to keep selling the older version whilst having the newer version available.

Well, I don't know if so many customers flee that a company will crash, though I get your point and I know that some/many might will. But on the other hand you gain new customers (like me ).

I think the best solution would be to have a second product parallel on the market. SESI could keep Houdini but also release a new modernized Houdini, let's call it “Copperfield” (just kidding).

A software that is just like Houdini but 2014
- less networks to deal with (I think I could reduce it down to 3-4)
- nicely implemented Python (scripting and expressions)
- all the improments that were already discussed about modeling, animation, UVs and so
- a nicer initial shading
- material icons that update on the fly
- proper naming of operators and such
- more intuitivity
- and so much more I don't remember at the moment
I mean with Houdini the base is already there, so they wouldn't have to start the development from scratch unlike competitive companies.

With two product on the market parallel, customers don't flee that easy and if they intent to do, they have the option to flee to “Copperfield” so SESI wouldn't even lose customers. But I think the amount of customers SESI would gain by this, is worth the effort.
Look at nodebased compositing. This is not a new idea, it exists almost as long as the industry itself. Many companies had many, more or less different, approaches for this but some day The Foundry came up with Nuke and they just nailed it. It took Nuke a while to fully take over the market but that's mostly because the industry at that time was a bit “sleepy” and noone was really interrested in another nodebased compositor. But as soon as they realized what power lies within it, the industry “awake” and nowadays the whole industry is crazy for nodebased (procedural) software. Maya just got a new node editor, Realflow just introduced nodes and let's face it Houdinis procedural nodebased 3D idea is the holy grail for digital 3D all along. It just lacks popularity because it still has a touch of a 25 year old Prism to it, which probably was groundbreaking at that time but that time is 25 years ago. What todays user call “…proven in over 25 years of production…” is what I call “outdated”. Modernize Houdini and designed well it surely will run the market very soon.

But again….I'm daydreaming

Jeff Wagner mentioned the possibility of merging all contexts here, which I would really love to see personally:

http://forums.odforce.net/topic/17550-is-there-a-houdini-like-2d-app-similar-to-photoshop/page-2#entry107707 [forums.odforce.net]

One context to rule them all! sounds just like my wettest dreams.
Although I still like the idea of grouping nodes to a subnet node, especially for DAs and VOP network for custom shaders. The rest can easily be merged.

Subnets would not be a problem in a single context as they are still in the same context, except they collapse multiple nodes into one to provide organizational value.

Korny Klown2
Many companies had many, more or less different, approaches for this but some day The Foundry came up with Nuke and they just nailed it.

You made my day , thanks for a good mood charge

Nuke was conceived, developed and refined at Digital Domain for over 10 years. The Foundry inherited Nuke and added needed polish and support. Very Powerful tool available to everyone.

Just to set the record straight.