Hello, In the Old point SOP you could do sin($PT) to get the sin location for every point on just the Y value.

What is the equivalent in the new Point SOP. I'm not finding a way to isolate just the Y value.

Also is the Vector attribute class now gone in the new Point SOP?

Thanks!

Trying to replicate the picture below using the new method

try sin(@ptnum)

Yea I have been reading up on the change to attribute syntax but I'm not sure which VEXpression in the drop down to unitize. In this example the sin gets applied to all axis.

It's a little different now:

-b

Thank you bonsak!

I went with to get it extremely close to the other point SOP. Out of curiosity would you happen to know why there is a discrepancy in the result of sin. Why I need to multiply by .01745 in the new one?

VEX trig functions use radians, hscript uses degrees. You can use the function radians() to convert if you don't know the constant to scale by.

awesome thank you guys!

Another approach is to do:


Then change the “Constant Value” from the default 0, 0, 0 to 0, 1, 0. The constant value is available as value. This then lets you control which axis you apply the sine to without having to edit your expression.

Going a bit farther down the rabbit hole,


After putting that in the VEXpression, press the slider button. You'll see two new parameters appear, Period and Amplitude. Change them to 1, then you can adjust your sine behaviour without typing.

In the old Point SOP, we could simply put sin(@ptnum) in the PY parameter field. I believe this is a much simpler approach for beginners to get used to expressions and the concept of variables and attributes. Also the old Point SOP had relevant @attributes placed in the parameter fields. This was a great way for new users to see: oh: @P.x, @P.y, @P.z is how you would access the different components of the Position. Or @N.x, @N.y, @N.z for Normals.

If the default is now:
Set Constant Value to: 0, 1, 0
Set VEXpression to: self + value * sin(radians(@ptnum))

That's a lot of additional work - and possible “human error”, just to get a sine wave.

It's beginning to feel much more verbose. It also doesn't have any visual clues as to how you might want to reference a particular attribute (such as position). While, yes, you see Position(P) in the drop-down menu, it doesn't visually show it being used like: @P.x, @P.y. @P.z

While, this workflow is probably fine for older, more seasoned users, who are used to typing expressions, referencing attributes, using variables - newer users - (In my opinion) are not going to find this as simple.

Possible solution:
What if the Attribute Expression SOP included a “self” field - vector or scalar, depending on the attribute. In the fields, are the relevant references - @P.x, @P.y, @P.z for Position for example. This would kind of mimic the “old” Point SOP in that specific respect.

This will have two benefits: 1) Newer users will get some visual reference as to “how” to go about accessing specific attributes. 2) Less verbose - we could just set the self.y field to sin(radians(@ptnum) and call it a day.

Thoughts?

I've kind of missed out on the whole transition issue from the old Point SOP. I've found wrangles a really fast way of setting these kinds of things, almost exactly like @itriix mentioned: @P.y = sin(@ptnum) for example.

Maybe I've just sucked up more programming than is good for me, but this still seems to me the most straightforward way of going about things. Am I missing any advantages to using VEXpressions vs wrangles?

I too have lamented the demise of the Point SOP having it be the corner stone of scene files I've been crafting since 1993. Yes I thought long and hard when it was deprecated in H16 along with the Copy SOP and the Group SOP. The Point SOP's use of local variables in simple expressions is a real good tool for teaching trig and linear algebra over the years. To open the door to artists the ability to work in geometry is liberating. Not to be minimized by the programmers in the audience.

Point SOP has serious issues wrt performance. It works on three floats in turn. No parallel computation here. We tried to add vector computation to Point SOP way back but no one used it as it was a bit of an edge case.
What ultimately deprecated the Point SOP? This node will not work with the new compile SOP workflow which does offer substantial memory and performance gains in certain cases that are quickly becoming more general.

When we decided to add VEX as a general point expression language for POP Wrangling we quickly moved this in to SOPs and other contexts. I rarely used the Point SOP after this, only for demos actually. I haven't used the Point SOP for quite some time in personal files. I go straight for wrangling in an Attribute Wrangle SOP and/or VOPs.


Reasons to use Wrangling in VEX type operators over Point SOP:

- common language applied to all supported contexts in Houdini, including H16 CHOPs!
You learn it once and use it for ever everywhere. Including Shading! You learn how to do a sin() in VEX and it's the same expression in all contexts with VEX.

- common variable names across all Nodes. If you want P, it's @P. Everywhere! If you want point number, it's @ptnum. Everywhere! But if you are using SOPs, for those nodes that had local variables (had to go to help to see if it did) the variables would be different across all these SOPs. Using help was mandatory for those operators you didn't use that often.
Having a common and logical naming schema for all variables removes all this ambiguity. And to find out the variable name and type, just pop up the node info with a MMB. H16 node info in advanced view shows you all the attributes around a variable including it's signature, etc. Very very handy! Thank-you R&D! Makes this even easier to teach.

- VEX gives you threading for free. Well you need to be processing more than 1000 points/prims but still you get threading for free. Never possible with any of the SOPs that use local variables.

- VEX is easy to learn and consistent to apply.
I stand by that and the many new users I've helped get up with the new ways quickly. Especially the Softimage users where our illogical treatment of local variables to actual variable names drove them nutty. $VX for @v.x. Why capitalized when “v” isn't? And on and on…
And using a point(opinputpath(“.”,0),$PT,“my_var”,0) to fetch “my_var” is nutty as you just want f@my_var. Wrangling gives you that! So yes the simple case is slightly more complicated but everything else is the same. No seemingly random use of local variables to fetch common variables by name to do your work.

- Wrangling = VOPs through the Snippet VOP. VOPs is always a visual alternative and fits in naturally with Wrangling.
There's always VOPs as an alternative to visually build up your VEX code. And wrangling slips in here quite nicely.
VEX wrangling is exposed at the top of the node through the use of a Snippet VOP. It is the Snippet VOP's code parameter that is raised to the top level of the asset. Wrangling really is deeply embedded VOPs so using it means you are indeed working in a VOP context down below. And I bet few of you have gone in to the VOP network to have a look. It's very cool what you can do around a Snippet VOP. Have a look at the various POP type DOPs that work with points directly. Very cool stuff Mr. Lait has added in there.
I debug VEX wranglers by inspecting the VEX code. The RMB menu on the node and go to the view vex code option to see how the @variable_name is expanded and how your code is treated as a function in the body of the VEX code.
This is really important as it is a single unified way to do stuff.

- In H16 VEX type operators are supported inside Compile Blocks, but not SOPs using local variables as they are not supported.
This is very important moving forward as we look for further ways to thread and parallelize workflows.
The ambiguity of expressions in parameters such as the old Point SOP makes it almost impossible to thread efficiently.
Learning and using Wrangling is mandatory moving forward for ad-hoc access to munging or wrangling attributes, hence the name.



Does VEX replace hscrpt?
I assume this question will come up at some point.

Yes and no is the answer. Mostly yes though.

We ported most of the hscript commands in to VEX, I believe in H14, H14.5 and H15, and continue to follow up on RFE's for the more ambiguous hscript functions to port over that make sense. For example ch(), chs(), etc to do channel referencing right in VEX. Well be careful in H16 compile blocks but ch() is still supported.
There are some things that are just handier to do in hscript so that is always an option.
Then there are the functions that have not been implemented in VEX. Just yesterday I wanted to access the maximum value of an incoming volume. That is done with the hscript command volumemax() with no VEX equivalent function while there are a bunch of other volume type vex functions that were ported over from hscript. Since the maximum volume value is a constant coming in for the current evaluated time, just create a Parameter VOP and at the top level, put your hscript command in there. Done!

We even added pythonic like slicing to VEX string wrangling a couple releases ago so even text manipulation has gotten much better in VEX and in wrangling. For advanced string support, there is always Python, so use that where it makes sense, then feed VEX the string through a parameter.

—-

For the minimal added complexity to a sin() function, the benefits of VEX wrangling and moving workflows to VOPs in H16 is hugely beneficial. Wrangling and VEX/VOPs are now the way forward for custom geometry manipulation.

Point SOP has been deprecated. Move on I say!

I have to agree with what jeff is saying.

I started Houdini over a year ago, and to keep my need to learn and remember different syntaxes to a minimum I decided to go with Python with simple things like parameter expressions, rather than hscript and of course vex.

I'm not a programmer at heart nor in skill, but I did start a number of years ago learning how to program with c.

Writting very short console programs working on simple things like sort algorithms.

Although vex is not c ( the non-use of pointers as an example ) it is very close in syntax structure.

So even with this small background in c helped me to easily jump into vex.

If one has no prior experience in a vex like language and is just starting to use vex I can understand someone having reservations about any ‘removal’ of Hscript use.

Like I've inferred before I didn't go down the Hscript route when I started Houdini, but there is so many examples of ‘how’ to do things in Houdini from forum references to video tutorials. You just can't miss it.

As such, I have seen how in alot of cases doing simple things in conjunction with ‘node’ work, Hscript really shines.

I think SideFx did a great job in developing HScript.

But when I want to develop my own algorithms for dealing with points/data, vex really shines.

When it comes to vex/c like languages I find I can structure my code in a way that when I come back to it later when I have forgotten what I have done; The layout of my code, and the ‘strict type’ nature of vex/c easily helps me to read and remember what I have done.

Just yesterday I was working in a point wrangle node and learning how to use the vex setpointgroup function and work out some group patterning with my code.

Then I came across the new groupexpression node. And realized something pretty cool, for me at least.

I could write my base function in the point wrangle node where it needs many lines of code because of its' complexity.

But with the group expression node, I could write short snippets in the group expression node that ‘ride on top’ of that base code I have in the point wrangler. And because both are using vex, things like your own defined attributes can be referenced easily. It becomes ‘seamless’ to work across nodes like this when only using vex.

Plus with the new network layout ability in H16; Setting up a scene/network based on vex usage is getting easier and better.

I personally am looking forward to additional changes like what has been done with the new Point SOP and groupexpression node.

There's probably more current similar changes I have yet to come across as well.

I would like to say thanks to SideFX for moving in this direction.

I'm all about the efficiency improvements and I understand measures needed to be taken to make that happen. For myself and many others, i'm sure it didn't take long to adapt to the new approaches, but my initial response was from the perspective of an educator, teaching students between undergrad to grad level - with widely varying experience in cg.

At the one end of the spectrum, the changes are welcomed, at the other end, a little more technical explanation is now needed to get them up and running. Not that it's a bad thing, it just requires approaching educational material from a different angle. In the end, it's for the benefit of all the Houdini artists.

So, I guess it's time to say goodbye to those we've lost - I surely hope the Point, Copy and Group SOP's got proper burials. It better have been epic! We had some amazing adventures! Out with the old, in with the new! I look forward to the better, brighter future of Houdini.

~ I still retain that the Attribute Expression SOP could use some work.

I still retain that the Attribute Expression SOP could use some work.

As you find concrete stuff that is lackluster/missing, please submit RFEs. In particular, useful presets are always desired.

The idea of having @P, @N be the defaults I think was done for an early iteration of Attribute Expression. The problem with using @P rather than self is that you can't use the same expression for other attributes. We may need a more context-sensitive expression list to avoid this.

The other issue I see is that it isn't clear that the constant value isn't used if it isn't in the attribute expression. This causes one to naturally try to type something into the constant value and wonder why it isn't working.

Will do.

Yeah - a context-sensitive expression list sounds pretty good too.

Probably something flawed with my logic here but my thoughts were to just have an additional “Attribute/Self Value” parameter field that could represent “self” sitting right under the Constant parameter text boxes.

In the VEXpression box - “self” could then just reference this “Attribute Value” just like “value” references the “Constant Value”. When you change the “Attribute” pull-down menu option, it updates the “pre-defined” values, like @P.x, @P.y, @P.z in the “Attribute/Self Value” parameter fields. Something like in the image below:

I guess this doesn't really solve the original issue with the Point SOP - because it looks like it would just re-introduce the same problems as before. Hmmm… Maybe 3 VEX snippet boxes instead of 3 parameter value boxes? Each pre-set to write to an individual attribute component under the hood?

As for Constant Value - yeah that one seems a bit tricky. Possibly have a toggle for it.

While I sympathize with the simplicity of just changing Y; by far the most common complaint/refrain about the old Point SOP was that you had to type everything thrice. Any non-trivial expression is always cut & paste and slightly modified to make three copies….

Even the case of adding a Y-sine wave is probably best expressed in terms of 3 space rather than adjusting Y. This preempts the question of “How do I do this about another direction than one of the primary…”

So I'd personally rather the default Attribute for P be “@P”.

The problem then arises: what happens when you change that attribute menu? Do we replace the vexpression with the new value? But then it is hard to change an attribute after the fact, such as when you've built something for Cd and then decide you want to manipulate your own custom attribute instead….

It is rather annoying trying to set just a single component, however.

Maybe have a component mode that instead gives you three vexpressions that default to self.x, self.y, and self.z?

Cause I do agree using set() is very esoteric. Will be tricky to find where to put that toggle without further cluttering things… I really would like this UI to be as streamlined as possible for simple things. It already has too much chrome.

Fwiw moving the Generated Code field to be visible whilst editing is really useful, feels too abstracted otherwise, and, makes the transition to a Wrangle work-flow easier I reckon.

Only wish it would auto-update too.

jlait
Cause I do agree using set() is very esoteric.

This is one of the transition issues that could have been resolved by better docs and guides. Though there are some minor references to basics like “set” and “opinput” they are well hidden within quite extensive documentation.

It genarally feels like the docs was written in the pre-wrangle era. A sentence like “It also supports shading-specific statements such as the illuminance() and gather()” should probably not be one of the first things to tell a new user. I think a good place to start would be restructuring the current docs and adding a transition guide for people new to wrangling but not expressions. Basically, people shouldn't have to think about “vcc”, “pragmas” and “shader calls” when they just wanted to plus 1 to the y component.

That said, the docs that are new since wranglings, “half edges” and “geometry functions” is very nicely made.

http://www.sidefx.com/docs/houdini/vex/snippets [sidefx.com] is always a good starting point.

Hi, I have an Houdini 18 but I do not have a node point old. Which node should I bring instead of this node?