Re: shameful houdini question

[Jason S]

  
  

    On 04/27/17 12:17, Steven Caron wrote:
      ... ICE took most of it away ...  
  
  I would have to agree,  and add that in general, does ICE take
  most of it away.   (complication)
  
      
  
  
  
  On 04/27/17 12:17, Steven Caron wrote:


  Well at first I was using VOPs. So the looping
stuff was hard to get right. I eventually got it but it was hard
to debug and get the result I was looking for. I obviously was
just doing something wrong, I have little time right now to
actually read ever doc/tutorial. I am relying mostly on my
intuition with some docs/tutorials.


As we probably all know looping in a graph is a hard
  concept to visualize. ICE took most of it away with how it
  automatically looped over points and would do certain
  operations with arrays transparently, at the cost of making a
  simple loop not simple. VOPs has various loop blocks which is
  more general but I struggle with making sense of it (and most
  users I read don't use them). Fabric's Canvas (pre Blocks) had
  you write KL in your graph to do the loop/pex, and now with
  Blocks you have a better way of doing it with actual nodes but
  is still tricky to visualize.
  
On Wed, Apr 26, 2017 at 11:03 PM,
  Christopher Crouzet 
  wrote:
  

  Technically, VOP is just a wrapper around VEX, so
you could say that you're kinda using VEX...
indirectly! :P

  
  @Steven I actually didn't reply to your question at
  all. I don't know how I manage to misread emails that
  well but I'm pretty good at it! Anyways, the function
  `pcfind` returns point numbers, so then you can just
  loop over them and use the usual methods, such as for
  example `point` to retrieve other
  attributes.
  

  

  
  
  
  
  --
Softimage Mailing List.
To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with "unsubscribe" in the subject, and reply to confirm.


  

--
Softimage Mailing List.
To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with 
"unsubscribe" in the subject, and reply to confirm.

Re: shameful houdini question

[Steven Caron]

Well at first I was using VOPs. So the looping stuff was hard to get right.
I eventually got it but it was hard to debug and get the result I was
looking for. I obviously was just doing something wrong, I have little time
right now to actually read ever doc/tutorial. I am relying mostly on my
intuition with some docs/tutorials.

As we probably all know looping in a graph is a hard concept to visualize.
ICE took most of it away with how it automatically looped over points and
would do certain operations with arrays transparently, at the cost of
making a simple loop not simple. VOPs has various loop blocks which is more
general but I struggle with making sense of it (and most users I read don't
use them). Fabric's Canvas (pre Blocks) had you write KL in your graph to
do the loop/pex, and now with Blocks you have a better way of doing it with
actual nodes but is still tricky to visualize.

On Wed, Apr 26, 2017 at 11:03 PM, Christopher Crouzet <
christopher.crou...@gmail.com> wrote:

> Technically, VOP is just a wrapper around VEX, so you could say that
> you're kinda using VEX... indirectly! :P
>
> @Steven I actually didn't reply to your question at all. I don't know how
> I manage to misread emails that well but I'm pretty good at it! Anyways,
> the function `pcfind` returns point numbers, so then you can just loop over
> them and use the usual methods, such as for example `point
> ` to retrieve
> other attributes.
>
--
Softimage Mailing List.
To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with 
"unsubscribe" in the subject, and reply to confirm.

Re: shameful houdini question

[Andy Nicholas]

Haha. Neither am I, I'd just be after some robust critical feedback :)

On 27/04/2017 11:34, Christopher Crouzet wrote:

Sure thing but be warned that I'm far from being a noise expert! :)


On 27 April 2017 at 17:21, Andy Nicholas > wrote:


Yes, exactly, I found the same. I'm quite relieved your experience
mirrors mine as otherwise I've just been wasting a lot of my time! :)

Would love you to beta test when it's ready (if you're interested).
A


On 27/04/2017 11:17, Christopher Crouzet wrote:

I've just tried what you said and in fact the unified noise
doesn't even seem to use the full [0, 1] range as one would
expect from reading the doc. At least not in H13. Or maybe I did
something wrong. If this turns out to be true, it'd kill the
primary purpose of the node to bring coherency between the
different noise types. Not great for lookdev as you said.

This bring back blurry memories where I digged into the unified
noise a couple of years ago and ended up coding my own, maybe
because of this exact reason. But then I eventually lost the
digital asset that I had built and ended up using the default
noises instead :)


On 27 April 2017 at 16:42, Andy Nicholas > wrote:


The `Unified Noise VOP`, which is a fairly useful node that
outputs all the noise values in the [0, 1] range, takes
pretty much all of its logic from the `pyro_noise.h` include
file. Which means that you can easily have access to the
same functionalities in VEX, like so:

#include 
v@perlin = vnwrap_perlin3(v@P, 0, 0);
f@pflow = fnwrap_pflow1(v@P, {1, 2, 3}, 0);



Aah, thanks for that Chris. Didn't realise you could access
the noise functions like that. Good to know :)


Also, it's interesting to see how they managed to unify the
noise values in `pyro_noise.h`: they basically ran a lot of
samples and picked the min/max values of each noise to
approximate their range. Statistics for the win! :)


Yep, that's what I've been doing. I'm concentrating on FBM
modes of evaluating the basic noise functions (noise(),
xnoise(), snoise(), onoise(), anoise) as that's what I tend
to use the most. Unified Noise is okay, but I still find
problems with shifting offsets in the noise.

For example, make a grid with 150 divisions, create a Unified
Noise in a Point VOP and set it to use Signature:->"3D Input,
3D noise", Noise Type->"Perlin", Fractal Type "Standard
(fBm)" add the vector output to the point position and then
try playing around with the Max Octaves, Lacunarity, and
Roughness. You'll see that you get a global uniform "DC"
offset along the each axis. That's not cool! If I'm using
that as a noise force, then it has just pushed all my
particles in the (1,1,1) direction. You'll also find that
switching between noise types noticably changes the amplitude
range. Again, not great if I'm doing lookdev and I just want
to try a different noise type without changing the general
magnitude force amount.

In addition to sampling the noise values, I'm doing some
curve fitting to that data in Python's scipy which smooths
out some of the statistical glitches with the sampling. It's
giving some good results that don't exhibit the DC offset
that I mentioned above. All this should let me create a
replacement for the Anti-Aliased Noise VOP. I'm not dealing
with the anti-aliasing aspect yet though, so it won't be as
good for shaders, but the offset isn't quite so important in
that context as it is for using it for forces.

Still need to do some testing and then package them up into
VOPs, but once they're ready I'll release them in siLib for
everyone to try.

A



--
Softimage Mailing List.
To unsubscribe, send a mail to
softimage-requ...@listproc.autodesk.com
 with
"unsubscribe" in the subject, and reply to confirm.




-- 
Christopher Crouzet

/https://christophercrouzet.com/



--
Softimage Mailing List.
To unsubscribe, send a mail tosoftimage-requ...@listproc.autodesk.com
  with "unsubscribe" in the 
subject, and reply to confirm.

-- Softimage Mailing List. To unsubscribe, send a mail to
softimage-requ...@listproc.autodesk.com
 with
"unsubscribe" in the subject, and reply to confirm. 


--
Christopher Crouzet /https://christophercrouzet.com/

--
Softimage Mailing List.
To unsubscribe, 

Re: shameful houdini question

[Christopher Crouzet]

Sure thing but be warned that I'm far from being a noise expert! :)


On 27 April 2017 at 17:21, Andy Nicholas  wrote:

> Yes, exactly, I found the same. I'm quite relieved your experience mirrors
> mine as otherwise I've just been wasting a lot of my time! :)
>
> Would love you to beta test when it's ready (if you're interested).
> A
>
>
> On 27/04/2017 11:17, Christopher Crouzet wrote:
>
> I've just tried what you said and in fact the unified noise doesn't even
> seem to use the full [0, 1] range as one would expect from reading the doc.
> At least not in H13. Or maybe I did something wrong. If this turns out to
> be true, it'd kill the primary purpose of the node to bring coherency
> between the different noise types. Not great for lookdev as you said.
>
> This bring back blurry memories where I digged into the unified noise a
> couple of years ago and ended up coding my own, maybe because of this exact
> reason. But then I eventually lost the digital asset that I had built and
> ended up using the default noises instead :)
>
>
> On 27 April 2017 at 16:42, Andy Nicholas  wrote:
>
>> The `Unified Noise VOP`, which is a fairly useful node that outputs all
>> the noise values in the [0, 1] range, takes pretty much all of its logic
>> from the `pyro_noise.h` include file. Which means that you can easily have
>> access to the same functionalities in VEX, like so:
>>
>> #include 
>> v@perlin = vnwrap_perlin3(v@P, 0, 0);
>> f@pflow = fnwrap_pflow1(v@P, {1, 2, 3}, 0);
>>
>>
>>
>> Aah, thanks for that Chris. Didn't realise you could access the noise
>> functions like that. Good to know :)
>>
>> Also, it's interesting to see how they managed to unify the noise values
>> in `pyro_noise.h`: they basically ran a lot of samples and picked the
>> min/max values of each noise to approximate their range. Statistics for the
>> win! :)
>>
>>
>> Yep, that's what I've been doing. I'm concentrating on FBM modes of
>> evaluating the basic noise functions (noise(), xnoise(), snoise(),
>> onoise(), anoise) as that's what I tend to use the most. Unified Noise is
>> okay, but I still find problems with shifting offsets in the noise.
>>
>> For example, make a grid with 150 divisions, create a Unified Noise in a
>> Point VOP and set it to use Signature:->"3D Input, 3D noise", Noise
>> Type->"Perlin", Fractal Type "Standard (fBm)" add the vector output to the
>> point position and then try playing around with the Max Octaves,
>> Lacunarity, and Roughness. You'll see that you get a global uniform "DC"
>> offset along the each axis. That's not cool! If I'm using that as a noise
>> force, then it has just pushed all my particles in the (1,1,1) direction.
>> You'll also find that switching between noise types noticably changes the
>> amplitude range. Again, not great if I'm doing lookdev and I just want to
>> try a different noise type without changing the general magnitude force
>> amount.
>>
>> In addition to sampling the noise values, I'm doing some curve fitting to
>> that data in Python's scipy which smooths out some of the statistical
>> glitches with the sampling. It's giving some good results that don't
>> exhibit the DC offset that I mentioned above. All this should let me create
>> a replacement for the Anti-Aliased Noise VOP. I'm not dealing with the
>> anti-aliasing aspect yet though, so it won't be as good for shaders, but
>> the offset isn't quite so important in that context as it is for using it
>> for forces.
>>
>> Still need to do some testing and then package them up into VOPs, but
>> once they're ready I'll release them in siLib for everyone to try.
>>
>> A
>>
>>
>>
>> --
>> Softimage Mailing List.
>> To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com
>> with "unsubscribe" in the subject, and reply to confirm.
>>
>
>
>
> --
> Christopher Crouzet
> *https://christophercrouzet.com* 
>
>
>
> --
> Softimage Mailing List.
> To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with 
> "unsubscribe" in the subject, and reply to confirm.
>
>
>
> --
> Softimage Mailing List.
> To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com
> with "unsubscribe" in the subject, and reply to confirm.
>



-- 
Christopher Crouzet
*https://christophercrouzet.com* 
--
Softimage Mailing List.
To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with 
"unsubscribe" in the subject, and reply to confirm.

Re: shameful houdini question

[Andy Nicholas]

Yes, exactly, I found the same. I'm quite relieved your experience 
mirrors mine as otherwise I've just been wasting a lot of my time! :)


Would love you to beta test when it's ready (if you're interested).
A

On 27/04/2017 11:17, Christopher Crouzet wrote:
I've just tried what you said and in fact the unified noise doesn't 
even seem to use the full [0, 1] range as one would expect from 
reading the doc. At least not in H13. Or maybe I did something wrong. 
If this turns out to be true, it'd kill the primary purpose of the 
node to bring coherency between the different noise types. Not great 
for lookdev as you said.


This bring back blurry memories where I digged into the unified noise 
a couple of years ago and ended up coding my own, maybe because of 
this exact reason. But then I eventually lost the digital asset that I 
had built and ended up using the default noises instead :)



On 27 April 2017 at 16:42, Andy Nicholas > wrote:



The `Unified Noise VOP`, which is a fairly useful node that
outputs all the noise values in the [0, 1] range, takes pretty
much all of its logic from the `pyro_noise.h` include file. Which
means that you can easily have access to the same functionalities
in VEX, like so:

#include 
v@perlin = vnwrap_perlin3(v@P, 0, 0);
f@pflow = fnwrap_pflow1(v@P, {1, 2, 3}, 0);



Aah, thanks for that Chris. Didn't realise you could access the
noise functions like that. Good to know :)


Also, it's interesting to see how they managed to unify the noise
values in `pyro_noise.h`: they basically ran a lot of samples and
picked the min/max values of each noise to approximate their
range. Statistics for the win! :)


Yep, that's what I've been doing. I'm concentrating on FBM modes
of evaluating the basic noise functions (noise(), xnoise(),
snoise(), onoise(), anoise) as that's what I tend to use the most.
Unified Noise is okay, but I still find problems with shifting
offsets in the noise.

For example, make a grid with 150 divisions, create a Unified
Noise in a Point VOP and set it to use Signature:->"3D Input, 3D
noise", Noise Type->"Perlin", Fractal Type "Standard (fBm)" add
the vector output to the point position and then try playing
around with the Max Octaves, Lacunarity, and Roughness. You'll see
that you get a global uniform "DC" offset along the each axis.
That's not cool! If I'm using that as a noise force, then it has
just pushed all my particles in the (1,1,1) direction. You'll also
find that switching between noise types noticably changes the
amplitude range. Again, not great if I'm doing lookdev and I just
want to try a different noise type without changing the general
magnitude force amount.

In addition to sampling the noise values, I'm doing some curve
fitting to that data in Python's scipy which smooths out some of
the statistical glitches with the sampling. It's giving some good
results that don't exhibit the DC offset that I mentioned above.
All this should let me create a replacement for the Anti-Aliased
Noise VOP. I'm not dealing with the anti-aliasing aspect yet
though, so it won't be as good for shaders, but the offset isn't
quite so important in that context as it is for using it for forces.

Still need to do some testing and then package them up into VOPs,
but once they're ready I'll release them in siLib for everyone to try.

A



--
Softimage Mailing List.
To unsubscribe, send a mail to
softimage-requ...@listproc.autodesk.com
 with
"unsubscribe" in the subject, and reply to confirm.




--
Christopher Crouzet
/https://christophercrouzet.com/



--
Softimage Mailing List.
To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with 
"unsubscribe" in the subject, and reply to confirm.


--
Softimage Mailing List.
To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with 
"unsubscribe" in the subject, and reply to confirm.

Re: shameful houdini question

[Olivier Jeannel]

Agree Christopher @primnum ;)

2017-04-27 12:17 GMT+02:00 Christopher Crouzet <
christopher.crou...@gmail.com>:

> I've just tried what you said and in fact the unified noise doesn't even
> seem to use the full [0, 1] range as one would expect from reading the doc.
> At least not in H13. Or maybe I did something wrong. If this turns out to
> be true, it'd kill the primary purpose of the node to bring coherency
> between the different noise types. Not great for lookdev as you said.
>
> This bring back blurry memories where I digged into the unified noise a
> couple of years ago and ended up coding my own, maybe because of this exact
> reason. But then I eventually lost the digital asset that I had built and
> ended up using the default noises instead :)
>
>
> On 27 April 2017 at 16:42, Andy Nicholas  wrote:
>
>> The `Unified Noise VOP`, which is a fairly useful node that outputs all
>> the noise values in the [0, 1] range, takes pretty much all of its logic
>> from the `pyro_noise.h` include file. Which means that you can easily have
>> access to the same functionalities in VEX, like so:
>>
>> #include 
>> v@perlin = vnwrap_perlin3(v@P, 0, 0);
>> f@pflow = fnwrap_pflow1(v@P, {1, 2, 3}, 0);
>>
>>
>>
>> Aah, thanks for that Chris. Didn't realise you could access the noise
>> functions like that. Good to know :)
>>
>> Also, it's interesting to see how they managed to unify the noise values
>> in `pyro_noise.h`: they basically ran a lot of samples and picked the
>> min/max values of each noise to approximate their range. Statistics for the
>> win! :)
>>
>>
>> Yep, that's what I've been doing. I'm concentrating on FBM modes of
>> evaluating the basic noise functions (noise(), xnoise(), snoise(),
>> onoise(), anoise) as that's what I tend to use the most. Unified Noise is
>> okay, but I still find problems with shifting offsets in the noise.
>>
>> For example, make a grid with 150 divisions, create a Unified Noise in a
>> Point VOP and set it to use Signature:->"3D Input, 3D noise", Noise
>> Type->"Perlin", Fractal Type "Standard (fBm)" add the vector output to the
>> point position and then try playing around with the Max Octaves,
>> Lacunarity, and Roughness. You'll see that you get a global uniform "DC"
>> offset along the each axis. That's not cool! If I'm using that as a noise
>> force, then it has just pushed all my particles in the (1,1,1) direction.
>> You'll also find that switching between noise types noticably changes the
>> amplitude range. Again, not great if I'm doing lookdev and I just want to
>> try a different noise type without changing the general magnitude force
>> amount.
>>
>> In addition to sampling the noise values, I'm doing some curve fitting to
>> that data in Python's scipy which smooths out some of the statistical
>> glitches with the sampling. It's giving some good results that don't
>> exhibit the DC offset that I mentioned above. All this should let me create
>> a replacement for the Anti-Aliased Noise VOP. I'm not dealing with the
>> anti-aliasing aspect yet though, so it won't be as good for shaders, but
>> the offset isn't quite so important in that context as it is for using it
>> for forces.
>>
>> Still need to do some testing and then package them up into VOPs, but
>> once they're ready I'll release them in siLib for everyone to try.
>>
>> A
>>
>>
>>
>> --
>> Softimage Mailing List.
>> To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com
>> with "unsubscribe" in the subject, and reply to confirm.
>>
>
>
>
> --
> Christopher Crouzet
> *https://christophercrouzet.com* 
>
>
> --
> Softimage Mailing List.
> To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com
> with "unsubscribe" in the subject, and reply to confirm.
>
--
Softimage Mailing List.
To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with 
"unsubscribe" in the subject, and reply to confirm.

Re: shameful houdini question

[Christopher Crouzet]

I've just tried what you said and in fact the unified noise doesn't even
seem to use the full [0, 1] range as one would expect from reading the doc.
At least not in H13. Or maybe I did something wrong. If this turns out to
be true, it'd kill the primary purpose of the node to bring coherency
between the different noise types. Not great for lookdev as you said.

This bring back blurry memories where I digged into the unified noise a
couple of years ago and ended up coding my own, maybe because of this exact
reason. But then I eventually lost the digital asset that I had built and
ended up using the default noises instead :)


On 27 April 2017 at 16:42, Andy Nicholas  wrote:

> The `Unified Noise VOP`, which is a fairly useful node that outputs all
> the noise values in the [0, 1] range, takes pretty much all of its logic
> from the `pyro_noise.h` include file. Which means that you can easily have
> access to the same functionalities in VEX, like so:
>
> #include 
> v@perlin = vnwrap_perlin3(v@P, 0, 0);
> f@pflow = fnwrap_pflow1(v@P, {1, 2, 3}, 0);
>
>
>
> Aah, thanks for that Chris. Didn't realise you could access the noise
> functions like that. Good to know :)
>
> Also, it's interesting to see how they managed to unify the noise values
> in `pyro_noise.h`: they basically ran a lot of samples and picked the
> min/max values of each noise to approximate their range. Statistics for the
> win! :)
>
>
> Yep, that's what I've been doing. I'm concentrating on FBM modes of
> evaluating the basic noise functions (noise(), xnoise(), snoise(),
> onoise(), anoise) as that's what I tend to use the most. Unified Noise is
> okay, but I still find problems with shifting offsets in the noise.
>
> For example, make a grid with 150 divisions, create a Unified Noise in a
> Point VOP and set it to use Signature:->"3D Input, 3D noise", Noise
> Type->"Perlin", Fractal Type "Standard (fBm)" add the vector output to the
> point position and then try playing around with the Max Octaves,
> Lacunarity, and Roughness. You'll see that you get a global uniform "DC"
> offset along the each axis. That's not cool! If I'm using that as a noise
> force, then it has just pushed all my particles in the (1,1,1) direction.
> You'll also find that switching between noise types noticably changes the
> amplitude range. Again, not great if I'm doing lookdev and I just want to
> try a different noise type without changing the general magnitude force
> amount.
>
> In addition to sampling the noise values, I'm doing some curve fitting to
> that data in Python's scipy which smooths out some of the statistical
> glitches with the sampling. It's giving some good results that don't
> exhibit the DC offset that I mentioned above. All this should let me create
> a replacement for the Anti-Aliased Noise VOP. I'm not dealing with the
> anti-aliasing aspect yet though, so it won't be as good for shaders, but
> the offset isn't quite so important in that context as it is for using it
> for forces.
>
> Still need to do some testing and then package them up into VOPs, but once
> they're ready I'll release them in siLib for everyone to try.
>
> A
>
>
>
> --
> Softimage Mailing List.
> To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com
> with "unsubscribe" in the subject, and reply to confirm.
>



-- 
Christopher Crouzet
*https://christophercrouzet.com* 
--
Softimage Mailing List.
To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with 
"unsubscribe" in the subject, and reply to confirm.

Re: shameful houdini question

[Christopher Crouzet]

Sorry, I can't really help as there are no `primpoints` function nor array
attributes in H13, so I can't try any of that. That being said you are
using @ptnum instead of @primnum.


On 27 April 2017 at 16:21, Olivier Jeannel  wrote:

> Thank's Christopher, I'm just realizing that now :/
> i[]@toto  = primpoints(0, @ptnum);
> Won't work in a VOP Snippet, but I can bind the array in VOP later.
>
> crazy, it's one of the most used function...
>
> 2017-04-27 10:06 GMT+02:00 Christopher Crouzet <
> christopher.crou...@gmail.com>:
>
>> I think remembering that I also had the same thought back when I started
>> using Houdini but then it probably just sinked in... the logic in Houdini
>> is strong! :)
>>
>>
>> On 27 April 2017 at 14:53, Jonathan Moore 
>> wrote:
>>
>>>
>>>
>>> No complaints from me Christopher. It just spun my head a little the
>>> first time I found out. Although now it makes complete sense even if it is
>>> all a little 'like a circle in a circle, like a wheel within a wheel’.  ;)
>>>
>>>
>>>
>>> On 27 Apr 2017, at 08:27, Christopher Crouzet <
>>> christopher.crou...@gmail.com> wrote:
>>>
>>> @Olivier: Not all VEX functions have been ported to VOP nodes, so maybe
>>> `primpoints` is one of these? Use a wrangle! ;)
>>>
>>> @Jonathan: I guess the rationale is that there was no need write a brand
>>> new node only to repeat the same features already available elsewhere?
>>> Seems fair enough to me and it also follows Houdini's philosophy of putting
>>> together a few building blocks together to provide higher-level nodes.
>>>
>>>
>>> On 27 April 2017 at 13:54, Jonathan Moore 
>>> wrote:
>>>

 Funnily enough it all get’s a bit ‘pop will eat itself’ in that a VEX
 Wrangle is in fact a digital asset and in that digital asset is a VOP and
 in the VOP is a VEX snippet node and that generates that actual VEX code!

 As they used to say in one of my favourite 80’s US comedies ‘Soap’ -
 “Confused, you will be!”.  :)



 On 27 Apr 2017, at 07:03, Christopher Crouzet <
 christopher.crou...@gmail.com> wrote:

 Technically, VOP is just a wrapper around VEX, so you could say that
 you're kinda using VEX... indirectly! :P

 @Steven I actually didn't reply to your question at all. I don't know
 how I manage to misread emails that well but I'm pretty good at it!
 Anyways, the function `pcfind` returns point numbers, so then you can just
 loop over them and use the usual methods, such as for example `point
 ` to retrieve
 other attributes.


 On 27 April 2017 at 12:33, Olivier Jeannel 
 wrote:

> Still in the VOP band wagon here :/
>
> 2017-04-27 7:22 GMT+02:00 Christopher Crouzet <
> christopher.crou...@gmail.com>:
>
>> The `Unified Noise VOP`, which is a fairly useful node that outputs
>> all the noise values in the [0, 1] range, takes pretty much all of its
>> logic from the `pyro_noise.h` include file. Which means that you can 
>> easily
>> have access to the same functionalities in VEX, like so:
>>
>> #include 
>> v@perlin = vnwrap_perlin3(v@P, 0, 0);
>> f@pflow = fnwrap_pflow1(v@P, {1, 2, 3}, 0);
>>
>>
>> The naming convention of these wrappers is detailed in the file. And
>> in newer versions of Houdini than my H13, they have added a 
>> `unified_noise`
>> function that makes it even easier to use.
>>
>> Also, it's interesting to see how they managed to unify the noise
>> values in `pyro_noise.h`: they basically ran a lot of samples and picked
>> the min/max values of each noise to approximate their range. Statistics 
>> for
>> the win! :)
>>
>>
>> @Steven To answer your initial question, you can use
>> `pcimport(my_pc_handle, "point.number", my_ptnum_var);` to retrieve the
>> point number.
>>
>> The function `pcfilter` is handy only if you exactly want the
>> behaviour as they documented it. If for example you'd like to use a
>> slightly different weighting formula (based not only on distance but also
>> on mass, for example), then you'd have to write your own.
>>
>>
>> On 27 April 2017 at 11:27, Andy Goehler > > wrote:
>>
>>> Hi Steven,
>>>
>>> same as Andy (Nicholas) here, VOPs mostly for Noise stuff, Wrangles
>>> for anything else.
>>>
>>> Cheers and have fun.
>>> Andy
>>>
>>> On Apr 27, 2017, at 12:47 AM, Steven Caron  wrote:
>>>
>>> Just to understand how the power users are using this. Are you using
>>> wrangle nodes with vex snippets 100% of the time or are you using the 
>>> VOP
>>> sub graph for somethings?
>>>
>>>
>>>
>>> --
>>> Softimage Mailing 

Re: shameful houdini question

[Andy Nicholas]

Yep, Unified Noise is definitely very slow when tweaking the UI 
parameters. Haven't done any profiling yet though to see if that's due 
to recompiling issues vs actual performance of evaluation.


On 27/04/2017 10:49, Olivier Jeannel wrote:

I found the Unified noise slower than the other noises. No ?

2017-04-27 11:42 GMT+02:00 Andy Nicholas >:



The `Unified Noise VOP`, which is a fairly useful node that
outputs all the noise values in the [0, 1] range, takes pretty
much all of its logic from the `pyro_noise.h` include file. Which
means that you can easily have access to the same functionalities
in VEX, like so:

#include 
v@perlin = vnwrap_perlin3(v@P, 0, 0);
f@pflow = fnwrap_pflow1(v@P, {1, 2, 3}, 0);



Aah, thanks for that Chris. Didn't realise you could access the
noise functions like that. Good to know :)


Also, it's interesting to see how they managed to unify the noise
values in `pyro_noise.h`: they basically ran a lot of samples and
picked the min/max values of each noise to approximate their
range. Statistics for the win! :)


Yep, that's what I've been doing. I'm concentrating on FBM modes
of evaluating the basic noise functions (noise(), xnoise(),
snoise(), onoise(), anoise) as that's what I tend to use the most.
Unified Noise is okay, but I still find problems with shifting
offsets in the noise.

For example, make a grid with 150 divisions, create a Unified
Noise in a Point VOP and set it to use Signature:->"3D Input, 3D
noise", Noise Type->"Perlin", Fractal Type "Standard (fBm)" add
the vector output to the point position and then try playing
around with the Max Octaves, Lacunarity, and Roughness. You'll see
that you get a global uniform "DC" offset along the each axis.
That's not cool! If I'm using that as a noise force, then it has
just pushed all my particles in the (1,1,1) direction. You'll also
find that switching between noise types noticably changes the
amplitude range. Again, not great if I'm doing lookdev and I just
want to try a different noise type without changing the general
magnitude force amount.

In addition to sampling the noise values, I'm doing some curve
fitting to that data in Python's scipy which smooths out some of
the statistical glitches with the sampling. It's giving some good
results that don't exhibit the DC offset that I mentioned above.
All this should let me create a replacement for the Anti-Aliased
Noise VOP. I'm not dealing with the anti-aliasing aspect yet
though, so it won't be as good for shaders, but the offset isn't
quite so important in that context as it is for using it for forces.

Still need to do some testing and then package them up into VOPs,
but once they're ready I'll release them in siLib for everyone to try.

A



--
Softimage Mailing List.
To unsubscribe, send a mail to
softimage-requ...@listproc.autodesk.com
 with
"unsubscribe" in the subject, and reply to confirm.




--
Softimage Mailing List.
To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with 
"unsubscribe" in the subject, and reply to confirm.


--
Softimage Mailing List.
To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with 
"unsubscribe" in the subject, and reply to confirm.

Re: shameful houdini question

[Olivier Jeannel]

I found the Unified noise slower than the other noises. No ?

2017-04-27 11:42 GMT+02:00 Andy Nicholas :

> The `Unified Noise VOP`, which is a fairly useful node that outputs all
> the noise values in the [0, 1] range, takes pretty much all of its logic
> from the `pyro_noise.h` include file. Which means that you can easily have
> access to the same functionalities in VEX, like so:
>
> #include 
> v@perlin = vnwrap_perlin3(v@P, 0, 0);
> f@pflow = fnwrap_pflow1(v@P, {1, 2, 3}, 0);
>
>
>
> Aah, thanks for that Chris. Didn't realise you could access the noise
> functions like that. Good to know :)
>
> Also, it's interesting to see how they managed to unify the noise values
> in `pyro_noise.h`: they basically ran a lot of samples and picked the
> min/max values of each noise to approximate their range. Statistics for the
> win! :)
>
>
> Yep, that's what I've been doing. I'm concentrating on FBM modes of
> evaluating the basic noise functions (noise(), xnoise(), snoise(),
> onoise(), anoise) as that's what I tend to use the most. Unified Noise is
> okay, but I still find problems with shifting offsets in the noise.
>
> For example, make a grid with 150 divisions, create a Unified Noise in a
> Point VOP and set it to use Signature:->"3D Input, 3D noise", Noise
> Type->"Perlin", Fractal Type "Standard (fBm)" add the vector output to the
> point position and then try playing around with the Max Octaves,
> Lacunarity, and Roughness. You'll see that you get a global uniform "DC"
> offset along the each axis. That's not cool! If I'm using that as a noise
> force, then it has just pushed all my particles in the (1,1,1) direction.
> You'll also find that switching between noise types noticably changes the
> amplitude range. Again, not great if I'm doing lookdev and I just want to
> try a different noise type without changing the general magnitude force
> amount.
>
> In addition to sampling the noise values, I'm doing some curve fitting to
> that data in Python's scipy which smooths out some of the statistical
> glitches with the sampling. It's giving some good results that don't
> exhibit the DC offset that I mentioned above. All this should let me create
> a replacement for the Anti-Aliased Noise VOP. I'm not dealing with the
> anti-aliasing aspect yet though, so it won't be as good for shaders, but
> the offset isn't quite so important in that context as it is for using it
> for forces.
>
> Still need to do some testing and then package them up into VOPs, but once
> they're ready I'll release them in siLib for everyone to try.
>
> A
>
>
>
> --
> Softimage Mailing List.
> To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com
> with "unsubscribe" in the subject, and reply to confirm.
>
--
Softimage Mailing List.
To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with 
"unsubscribe" in the subject, and reply to confirm.

Re: shameful houdini question

[Andy Nicholas]

The `Unified Noise VOP`, which is a fairly useful node that outputs 
all the noise values in the [0, 1] range, takes pretty much all of its 
logic from the `pyro_noise.h` include file. Which means that you can 
easily have access to the same functionalities in VEX, like so:


#include 
v@perlin = vnwrap_perlin3(v@P, 0, 0);
f@pflow = fnwrap_pflow1(v@P, {1, 2, 3}, 0);



Aah, thanks for that Chris. Didn't realise you could access the noise 
functions like that. Good to know :)


Also, it's interesting to see how they managed to unify the noise 
values in `pyro_noise.h`: they basically ran a lot of samples and 
picked the min/max values of each noise to approximate their range. 
Statistics for the win! :)


Yep, that's what I've been doing. I'm concentrating on FBM modes of 
evaluating the basic noise functions (noise(), xnoise(), snoise(), 
onoise(), anoise) as that's what I tend to use the most. Unified Noise 
is okay, but I still find problems with shifting offsets in the noise.


For example, make a grid with 150 divisions, create a Unified Noise in a 
Point VOP and set it to use Signature:->"3D Input, 3D noise", Noise 
Type->"Perlin", Fractal Type "Standard (fBm)" add the vector output to 
the point position and then try playing around with the Max Octaves, 
Lacunarity, and Roughness. You'll see that you get a global uniform "DC" 
offset along the each axis. That's not cool! If I'm using that as a 
noise force, then it has just pushed all my particles in the (1,1,1) 
direction. You'll also find that switching between noise types noticably 
changes the amplitude range. Again, not great if I'm doing lookdev and I 
just want to try a different noise type without changing the general 
magnitude force amount.


In addition to sampling the noise values, I'm doing some curve fitting 
to that data in Python's scipy which smooths out some of the statistical 
glitches with the sampling. It's giving some good results that don't 
exhibit the DC offset that I mentioned above. All this should let me 
create a replacement for the Anti-Aliased Noise VOP. I'm not dealing 
with the anti-aliasing aspect yet though, so it won't be as good for 
shaders, but the offset isn't quite so important in that context as it 
is for using it for forces.


Still need to do some testing and then package them up into VOPs, but 
once they're ready I'll release them in siLib for everyone to try.


A


--
Softimage Mailing List.
To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with 
"unsubscribe" in the subject, and reply to confirm.

Re: shameful houdini question

[Olivier Jeannel]

Thank's Christopher, I'm just realizing that now :/
i[]@toto  = primpoints(0, @ptnum);
Won't work in a VOP Snippet, but I can bind the array in VOP later.

crazy, it's one of the most used function...

2017-04-27 10:06 GMT+02:00 Christopher Crouzet <
christopher.crou...@gmail.com>:

> I think remembering that I also had the same thought back when I started
> using Houdini but then it probably just sinked in... the logic in Houdini
> is strong! :)
>
>
> On 27 April 2017 at 14:53, Jonathan Moore 
> wrote:
>
>>
>>
>> No complaints from me Christopher. It just spun my head a little the
>> first time I found out. Although now it makes complete sense even if it is
>> all a little 'like a circle in a circle, like a wheel within a wheel’.  ;)
>>
>>
>>
>> On 27 Apr 2017, at 08:27, Christopher Crouzet <
>> christopher.crou...@gmail.com> wrote:
>>
>> @Olivier: Not all VEX functions have been ported to VOP nodes, so maybe
>> `primpoints` is one of these? Use a wrangle! ;)
>>
>> @Jonathan: I guess the rationale is that there was no need write a brand
>> new node only to repeat the same features already available elsewhere?
>> Seems fair enough to me and it also follows Houdini's philosophy of putting
>> together a few building blocks together to provide higher-level nodes.
>>
>>
>> On 27 April 2017 at 13:54, Jonathan Moore 
>> wrote:
>>
>>>
>>> Funnily enough it all get’s a bit ‘pop will eat itself’ in that a VEX
>>> Wrangle is in fact a digital asset and in that digital asset is a VOP and
>>> in the VOP is a VEX snippet node and that generates that actual VEX code!
>>>
>>> As they used to say in one of my favourite 80’s US comedies ‘Soap’ -
>>> “Confused, you will be!”.  :)
>>>
>>>
>>>
>>> On 27 Apr 2017, at 07:03, Christopher Crouzet <
>>> christopher.crou...@gmail.com> wrote:
>>>
>>> Technically, VOP is just a wrapper around VEX, so you could say that
>>> you're kinda using VEX... indirectly! :P
>>>
>>> @Steven I actually didn't reply to your question at all. I don't know
>>> how I manage to misread emails that well but I'm pretty good at it!
>>> Anyways, the function `pcfind` returns point numbers, so then you can just
>>> loop over them and use the usual methods, such as for example `point
>>> ` to retrieve
>>> other attributes.
>>>
>>>
>>> On 27 April 2017 at 12:33, Olivier Jeannel 
>>> wrote:
>>>
 Still in the VOP band wagon here :/

 2017-04-27 7:22 GMT+02:00 Christopher Crouzet <
 christopher.crou...@gmail.com>:

> The `Unified Noise VOP`, which is a fairly useful node that outputs
> all the noise values in the [0, 1] range, takes pretty much all of its
> logic from the `pyro_noise.h` include file. Which means that you can 
> easily
> have access to the same functionalities in VEX, like so:
>
> #include 
> v@perlin = vnwrap_perlin3(v@P, 0, 0);
> f@pflow = fnwrap_pflow1(v@P, {1, 2, 3}, 0);
>
>
> The naming convention of these wrappers is detailed in the file. And
> in newer versions of Houdini than my H13, they have added a 
> `unified_noise`
> function that makes it even easier to use.
>
> Also, it's interesting to see how they managed to unify the noise
> values in `pyro_noise.h`: they basically ran a lot of samples and picked
> the min/max values of each noise to approximate their range. Statistics 
> for
> the win! :)
>
>
> @Steven To answer your initial question, you can use
> `pcimport(my_pc_handle, "point.number", my_ptnum_var);` to retrieve the
> point number.
>
> The function `pcfilter` is handy only if you exactly want the
> behaviour as they documented it. If for example you'd like to use a
> slightly different weighting formula (based not only on distance but also
> on mass, for example), then you'd have to write your own.
>
>
> On 27 April 2017 at 11:27, Andy Goehler 
> wrote:
>
>> Hi Steven,
>>
>> same as Andy (Nicholas) here, VOPs mostly for Noise stuff, Wrangles
>> for anything else.
>>
>> Cheers and have fun.
>> Andy
>>
>> On Apr 27, 2017, at 12:47 AM, Steven Caron  wrote:
>>
>> Just to understand how the power users are using this. Are you using
>> wrangle nodes with vex snippets 100% of the time or are you using the VOP
>> sub graph for somethings?
>>
>>
>>
>> --
>> Softimage Mailing List.
>> To unsubscribe, send a mail to softimage-requ...@listproc.aut
>> odesk.com with "unsubscribe" in the subject, and reply to confirm.
>>
>
>
>
> --
> Christopher Crouzet
> *https://christophercrouzet.com* 
>
>
> --
> Softimage Mailing List.
> To unsubscribe, send a mail to 

Re: shameful houdini question

[Christopher Crouzet]

I think remembering that I also had the same thought back when I started
using Houdini but then it probably just sinked in... the logic in Houdini
is strong! :)


On 27 April 2017 at 14:53, Jonathan Moore  wrote:

>
>
> No complaints from me Christopher. It just spun my head a little the first
> time I found out. Although now it makes complete sense even if it is all a
> little 'like a circle in a circle, like a wheel within a wheel’.  ;)
>
>
>
> On 27 Apr 2017, at 08:27, Christopher Crouzet <
> christopher.crou...@gmail.com> wrote:
>
> @Olivier: Not all VEX functions have been ported to VOP nodes, so maybe
> `primpoints` is one of these? Use a wrangle! ;)
>
> @Jonathan: I guess the rationale is that there was no need write a brand
> new node only to repeat the same features already available elsewhere?
> Seems fair enough to me and it also follows Houdini's philosophy of putting
> together a few building blocks together to provide higher-level nodes.
>
>
> On 27 April 2017 at 13:54, Jonathan Moore 
> wrote:
>
>>
>> Funnily enough it all get’s a bit ‘pop will eat itself’ in that a VEX
>> Wrangle is in fact a digital asset and in that digital asset is a VOP and
>> in the VOP is a VEX snippet node and that generates that actual VEX code!
>>
>> As they used to say in one of my favourite 80’s US comedies ‘Soap’ -
>> “Confused, you will be!”.  :)
>>
>>
>>
>> On 27 Apr 2017, at 07:03, Christopher Crouzet <
>> christopher.crou...@gmail.com> wrote:
>>
>> Technically, VOP is just a wrapper around VEX, so you could say that
>> you're kinda using VEX... indirectly! :P
>>
>> @Steven I actually didn't reply to your question at all. I don't know how
>> I manage to misread emails that well but I'm pretty good at it! Anyways,
>> the function `pcfind` returns point numbers, so then you can just loop over
>> them and use the usual methods, such as for example `point
>> ` to retrieve
>> other attributes.
>>
>>
>> On 27 April 2017 at 12:33, Olivier Jeannel 
>> wrote:
>>
>>> Still in the VOP band wagon here :/
>>>
>>> 2017-04-27 7:22 GMT+02:00 Christopher Crouzet <
>>> christopher.crou...@gmail.com>:
>>>
 The `Unified Noise VOP`, which is a fairly useful node that outputs all
 the noise values in the [0, 1] range, takes pretty much all of its logic
 from the `pyro_noise.h` include file. Which means that you can easily have
 access to the same functionalities in VEX, like so:

 #include 
 v@perlin = vnwrap_perlin3(v@P, 0, 0);
 f@pflow = fnwrap_pflow1(v@P, {1, 2, 3}, 0);


 The naming convention of these wrappers is detailed in the file. And in
 newer versions of Houdini than my H13, they have added a `unified_noise`
 function that makes it even easier to use.

 Also, it's interesting to see how they managed to unify the noise
 values in `pyro_noise.h`: they basically ran a lot of samples and picked
 the min/max values of each noise to approximate their range. Statistics for
 the win! :)


 @Steven To answer your initial question, you can use
 `pcimport(my_pc_handle, "point.number", my_ptnum_var);` to retrieve the
 point number.

 The function `pcfilter` is handy only if you exactly want the behaviour
 as they documented it. If for example you'd like to use a slightly
 different weighting formula (based not only on distance but also on mass,
 for example), then you'd have to write your own.


 On 27 April 2017 at 11:27, Andy Goehler 
 wrote:

> Hi Steven,
>
> same as Andy (Nicholas) here, VOPs mostly for Noise stuff, Wrangles
> for anything else.
>
> Cheers and have fun.
> Andy
>
> On Apr 27, 2017, at 12:47 AM, Steven Caron  wrote:
>
> Just to understand how the power users are using this. Are you using
> wrangle nodes with vex snippets 100% of the time or are you using the VOP
> sub graph for somethings?
>
>
>
> --
> Softimage Mailing List.
> To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com
> with "unsubscribe" in the subject, and reply to confirm.
>



 --
 Christopher Crouzet
 *https://christophercrouzet.com* 


 --
 Softimage Mailing List.
 To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com
 with "unsubscribe" in the subject, and reply to confirm.

>>>
>>>
>>> --
>>> Softimage Mailing List.
>>> To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com
>>> with "unsubscribe" in the subject, and reply to confirm.
>>>
>>
>>
>>
>> --
>> Christopher Crouzet
>> *https://christophercrouzet.com* 
>>
>> --
>> Softimage Mailing List.
>> To unsubscribe, send 

Re: shameful houdini question

[Jonathan Moore]

No complaints from me Christopher. It just spun my head a little the first time 
I found out. Although now it makes complete sense even if it is all a little 
'like a circle in a circle, like a wheel within a wheel’.  ;)



> On 27 Apr 2017, at 08:27, Christopher Crouzet  
> wrote:
> 
> @Olivier: Not all VEX functions have been ported to VOP nodes, so maybe 
> `primpoints` is one of these? Use a wrangle! ;)
> 
> @Jonathan: I guess the rationale is that there was no need write a brand new 
> node only to repeat the same features already available elsewhere? Seems fair 
> enough to me and it also follows Houdini's philosophy of putting together a 
> few building blocks together to provide higher-level nodes.
> 
> 
> On 27 April 2017 at 13:54, Jonathan Moore  > wrote:
> 
> Funnily enough it all get’s a bit ‘pop will eat itself’ in that a VEX Wrangle 
> is in fact a digital asset and in that digital asset is a VOP and in the VOP 
> is a VEX snippet node and that generates that actual VEX code!
> 
> As they used to say in one of my favourite 80’s US comedies ‘Soap’ - 
> “Confused, you will be!”.  :)
> 
> 
> 
>> On 27 Apr 2017, at 07:03, Christopher Crouzet > > wrote:
>> 
>> Technically, VOP is just a wrapper around VEX, so you could say that you're 
>> kinda using VEX... indirectly! :P
>> 
>> @Steven I actually didn't reply to your question at all. I don't know how I 
>> manage to misread emails that well but I'm pretty good at it! Anyways, the 
>> function `pcfind` returns point numbers, so then you can just loop over them 
>> and use the usual methods, such as for example `point 
>> ` to retrieve other 
>> attributes.
>> 
>> 
>> On 27 April 2017 at 12:33, Olivier Jeannel > > wrote:
>> Still in the VOP band wagon here :/
>> 
>> 2017-04-27 7:22 GMT+02:00 Christopher Crouzet > >:
>> The `Unified Noise VOP`, which is a fairly useful node that outputs all the 
>> noise values in the [0, 1] range, takes pretty much all of its logic from 
>> the `pyro_noise.h` include file. Which means that you can easily have access 
>> to the same functionalities in VEX, like so:
>> 
>> #include 
>> v@perlin = vnwrap_perlin3(v@P, 0, 0);
>> f@pflow = fnwrap_pflow1(v@P, {1, 2, 3}, 0);
>> 
>> 
>> The naming convention of these wrappers is detailed in the file. And in 
>> newer versions of Houdini than my H13, they have added a `unified_noise` 
>> function that makes it even easier to use.
>> 
>> Also, it's interesting to see how they managed to unify the noise values in 
>> `pyro_noise.h`: they basically ran a lot of samples and picked the min/max 
>> values of each noise to approximate their range. Statistics for the win! :)
>> 
>> 
>> @Steven To answer your initial question, you can use `pcimport(my_pc_handle, 
>> "point.number", my_ptnum_var);` to retrieve the point number.
>> 
>> The function `pcfilter` is handy only if you exactly want the behaviour as 
>> they documented it. If for example you'd like to use a slightly different 
>> weighting formula (based not only on distance but also on mass, for 
>> example), then you'd have to write your own.
>> 
>> 
>> On 27 April 2017 at 11:27, Andy Goehler > > wrote:
>> Hi Steven,
>> 
>> same as Andy (Nicholas) here, VOPs mostly for Noise stuff, Wrangles for 
>> anything else.
>> 
>> Cheers and have fun.
>> Andy
>> 
>>> On Apr 27, 2017, at 12:47 AM, Steven Caron >> > wrote:
>>> 
>>> Just to understand how the power users are using this. Are you using 
>>> wrangle nodes with vex snippets 100% of the time or are you using the VOP 
>>> sub graph for somethings?
>> 
>> 
>> --
>> Softimage Mailing List.
>> To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com 
>>  with "unsubscribe" in the 
>> subject, and reply to confirm.
>> 
>> 
>> 
>> -- 
>> Christopher Crouzet
>> https://christophercrouzet.com 
>> 
>> 
>> --
>> Softimage Mailing List.
>> To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com 
>>  with "unsubscribe" in the 
>> subject, and reply to confirm.
>> 
>> 
>> --
>> Softimage Mailing List.
>> To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com 
>>  with "unsubscribe" in the 
>> subject, and reply to confirm.
>> 
>> 
>> 
>> -- 
>> Christopher Crouzet
>> https://christophercrouzet.com 
>> 
>> --
>> Softimage Mailing List.
>> To unsubscribe, send a mail 

RE: Up vector on particles flowing on a path

[Sven Constable]

There is also emtools from Eric Mootz that contains a compound for driving
particle orientation with lots of options. IIRC called Align Orientation or
similar.

Sven

-Original Message-
From: softimage-boun...@listproc.autodesk.com
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Kris Rivel
Sent: Thursday, April 27, 2017 12:37 AM
To: softimage@listproc.autodesk.com
Subject: Up vector on particles flowing on a path

I'm sure this has come up but how can I get a proper up vector on particles
flowing along a path? The align on velocity in the flow on path node
overrides anything else. I want them to align on velocity/direction but also
stand straight up pointing at Y. 

Kris
--
Softimage Mailing List.
To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with
"unsubscribe" in the subject, and reply to confirm.

--
Softimage Mailing List.
To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with 
"unsubscribe" in the subject, and reply to confirm.

Re: shameful houdini question

[Christopher Crouzet]

@Olivier: Not all VEX functions have been ported to VOP nodes, so maybe
`primpoints` is one of these? Use a wrangle! ;)

@Jonathan: I guess the rationale is that there was no need write a brand
new node only to repeat the same features already available elsewhere?
Seems fair enough to me and it also follows Houdini's philosophy of putting
together a few building blocks together to provide higher-level nodes.


On 27 April 2017 at 13:54, Jonathan Moore  wrote:

>
> Funnily enough it all get’s a bit ‘pop will eat itself’ in that a VEX
> Wrangle is in fact a digital asset and in that digital asset is a VOP and
> in the VOP is a VEX snippet node and that generates that actual VEX code!
>
> As they used to say in one of my favourite 80’s US comedies ‘Soap’ -
> “Confused, you will be!”.  :)
>
>
>
> On 27 Apr 2017, at 07:03, Christopher Crouzet <
> christopher.crou...@gmail.com> wrote:
>
> Technically, VOP is just a wrapper around VEX, so you could say that
> you're kinda using VEX... indirectly! :P
>
> @Steven I actually didn't reply to your question at all. I don't know how
> I manage to misread emails that well but I'm pretty good at it! Anyways,
> the function `pcfind` returns point numbers, so then you can just loop over
> them and use the usual methods, such as for example `point
> ` to retrieve
> other attributes.
>
>
> On 27 April 2017 at 12:33, Olivier Jeannel  wrote:
>
>> Still in the VOP band wagon here :/
>>
>> 2017-04-27 7:22 GMT+02:00 Christopher Crouzet <
>> christopher.crou...@gmail.com>:
>>
>>> The `Unified Noise VOP`, which is a fairly useful node that outputs all
>>> the noise values in the [0, 1] range, takes pretty much all of its logic
>>> from the `pyro_noise.h` include file. Which means that you can easily have
>>> access to the same functionalities in VEX, like so:
>>>
>>> #include 
>>> v@perlin = vnwrap_perlin3(v@P, 0, 0);
>>> f@pflow = fnwrap_pflow1(v@P, {1, 2, 3}, 0);
>>>
>>>
>>> The naming convention of these wrappers is detailed in the file. And in
>>> newer versions of Houdini than my H13, they have added a `unified_noise`
>>> function that makes it even easier to use.
>>>
>>> Also, it's interesting to see how they managed to unify the noise values
>>> in `pyro_noise.h`: they basically ran a lot of samples and picked the
>>> min/max values of each noise to approximate their range. Statistics for the
>>> win! :)
>>>
>>>
>>> @Steven To answer your initial question, you can use
>>> `pcimport(my_pc_handle, "point.number", my_ptnum_var);` to retrieve the
>>> point number.
>>>
>>> The function `pcfilter` is handy only if you exactly want the behaviour
>>> as they documented it. If for example you'd like to use a slightly
>>> different weighting formula (based not only on distance but also on mass,
>>> for example), then you'd have to write your own.
>>>
>>>
>>> On 27 April 2017 at 11:27, Andy Goehler 
>>> wrote:
>>>
 Hi Steven,

 same as Andy (Nicholas) here, VOPs mostly for Noise stuff, Wrangles for
 anything else.

 Cheers and have fun.
 Andy

 On Apr 27, 2017, at 12:47 AM, Steven Caron  wrote:

 Just to understand how the power users are using this. Are you using
 wrangle nodes with vex snippets 100% of the time or are you using the VOP
 sub graph for somethings?



 --
 Softimage Mailing List.
 To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com
 with "unsubscribe" in the subject, and reply to confirm.

>>>
>>>
>>>
>>> --
>>> Christopher Crouzet
>>> *https://christophercrouzet.com* 
>>>
>>>
>>> --
>>> Softimage Mailing List.
>>> To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com
>>> with "unsubscribe" in the subject, and reply to confirm.
>>>
>>
>>
>> --
>> Softimage Mailing List.
>> To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com
>> with "unsubscribe" in the subject, and reply to confirm.
>>
>
>
>
> --
> Christopher Crouzet
> *https://christophercrouzet.com* 
>
> --
> Softimage Mailing List.
> To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com
> with "unsubscribe" in the subject, and reply to confirm.
>
>
>
> --
> Softimage Mailing List.
> To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com
> with "unsubscribe" in the subject, and reply to confirm.
>



-- 
Christopher Crouzet
*https://christophercrouzet.com* 
--
Softimage Mailing List.
To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with 
"unsubscribe" in the subject, and reply to confirm.

Re: shameful houdini question

[Jonathan Moore]

Funnily enough it all get’s a bit ‘pop will eat itself’ in that a VEX Wrangle 
is in fact a digital asset and in that digital asset is a VOP and in the VOP is 
a VEX snippet node and that generates that actual VEX code!

As they used to say in one of my favourite 80’s US comedies ‘Soap’ - “Confused, 
you will be!”.  :)


> On 27 Apr 2017, at 07:03, Christopher Crouzet  
> wrote:
> 
> Technically, VOP is just a wrapper around VEX, so you could say that you're 
> kinda using VEX... indirectly! :P
> 
> @Steven I actually didn't reply to your question at all. I don't know how I 
> manage to misread emails that well but I'm pretty good at it! Anyways, the 
> function `pcfind` returns point numbers, so then you can just loop over them 
> and use the usual methods, such as for example `point 
> ` to retrieve other 
> attributes.
> 
> 
> On 27 April 2017 at 12:33, Olivier Jeannel  > wrote:
> Still in the VOP band wagon here :/
> 
> 2017-04-27 7:22 GMT+02:00 Christopher Crouzet  >:
> The `Unified Noise VOP`, which is a fairly useful node that outputs all the 
> noise values in the [0, 1] range, takes pretty much all of its logic from the 
> `pyro_noise.h` include file. Which means that you can easily have access to 
> the same functionalities in VEX, like so:
> 
> #include 
> v@perlin = vnwrap_perlin3(v@P, 0, 0);
> f@pflow = fnwrap_pflow1(v@P, {1, 2, 3}, 0);
> 
> 
> The naming convention of these wrappers is detailed in the file. And in newer 
> versions of Houdini than my H13, they have added a `unified_noise` function 
> that makes it even easier to use.
> 
> Also, it's interesting to see how they managed to unify the noise values in 
> `pyro_noise.h`: they basically ran a lot of samples and picked the min/max 
> values of each noise to approximate their range. Statistics for the win! :)
> 
> 
> @Steven To answer your initial question, you can use `pcimport(my_pc_handle, 
> "point.number", my_ptnum_var);` to retrieve the point number.
> 
> The function `pcfilter` is handy only if you exactly want the behaviour as 
> they documented it. If for example you'd like to use a slightly different 
> weighting formula (based not only on distance but also on mass, for example), 
> then you'd have to write your own.
> 
> 
> On 27 April 2017 at 11:27, Andy Goehler  > wrote:
> Hi Steven,
> 
> same as Andy (Nicholas) here, VOPs mostly for Noise stuff, Wrangles for 
> anything else.
> 
> Cheers and have fun.
> Andy
> 
>> On Apr 27, 2017, at 12:47 AM, Steven Caron > > wrote:
>> 
>> Just to understand how the power users are using this. Are you using wrangle 
>> nodes with vex snippets 100% of the time or are you using the VOP sub graph 
>> for somethings?
> 
> 
> --
> Softimage Mailing List.
> To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com 
>  with "unsubscribe" in the 
> subject, and reply to confirm.
> 
> 
> 
> -- 
> Christopher Crouzet
> https://christophercrouzet.com 
> 
> 
> --
> Softimage Mailing List.
> To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com 
>  with "unsubscribe" in the 
> subject, and reply to confirm.
> 
> 
> --
> Softimage Mailing List.
> To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com 
>  with "unsubscribe" in the 
> subject, and reply to confirm.
> 
> 
> 
> -- 
> Christopher Crouzet
> https://christophercrouzet.com 
> 
> --
> Softimage Mailing List.
> To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with 
> "unsubscribe" in the subject, and reply to confirm.

--
Softimage Mailing List.
To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with 
"unsubscribe" in the subject, and reply to confirm.

Re: shameful houdini question

[Olivier Jeannel]

:)

A question : What would be the exact equivalent of vex "primpoints" in VOP
? Primpoints returns an ordered integer ptnum array per primitive.

2017-04-27 8:03 GMT+02:00 Christopher Crouzet :

> Technically, VOP is just a wrapper around VEX, so you could say that
> you're kinda using VEX... indirectly! :P
>
> @Steven I actually didn't reply to your question at all. I don't know how
> I manage to misread emails that well but I'm pretty good at it! Anyways,
> the function `pcfind` returns point numbers, so then you can just loop over
> them and use the usual methods, such as for example `point
> ` to retrieve
> other attributes.
>
>
> On 27 April 2017 at 12:33, Olivier Jeannel  wrote:
>
>> Still in the VOP band wagon here :/
>>
>> 2017-04-27 7:22 GMT+02:00 Christopher Crouzet <
>> christopher.crou...@gmail.com>:
>>
>>> The `Unified Noise VOP`, which is a fairly useful node that outputs all
>>> the noise values in the [0, 1] range, takes pretty much all of its logic
>>> from the `pyro_noise.h` include file. Which means that you can easily have
>>> access to the same functionalities in VEX, like so:
>>>
>>> #include 
>>> v@perlin = vnwrap_perlin3(v@P, 0, 0);
>>> f@pflow = fnwrap_pflow1(v@P, {1, 2, 3}, 0);
>>>
>>>
>>> The naming convention of these wrappers is detailed in the file. And in
>>> newer versions of Houdini than my H13, they have added a `unified_noise`
>>> function that makes it even easier to use.
>>>
>>> Also, it's interesting to see how they managed to unify the noise values
>>> in `pyro_noise.h`: they basically ran a lot of samples and picked the
>>> min/max values of each noise to approximate their range. Statistics for the
>>> win! :)
>>>
>>>
>>> @Steven To answer your initial question, you can use
>>> `pcimport(my_pc_handle, "point.number", my_ptnum_var);` to retrieve the
>>> point number.
>>>
>>> The function `pcfilter` is handy only if you exactly want the behaviour
>>> as they documented it. If for example you'd like to use a slightly
>>> different weighting formula (based not only on distance but also on mass,
>>> for example), then you'd have to write your own.
>>>
>>>
>>> On 27 April 2017 at 11:27, Andy Goehler 
>>> wrote:
>>>
 Hi Steven,

 same as Andy (Nicholas) here, VOPs mostly for Noise stuff, Wrangles for
 anything else.

 Cheers and have fun.
 Andy

 On Apr 27, 2017, at 12:47 AM, Steven Caron  wrote:

 Just to understand how the power users are using this. Are you using
 wrangle nodes with vex snippets 100% of the time or are you using the VOP
 sub graph for somethings?



 --
 Softimage Mailing List.
 To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com
 with "unsubscribe" in the subject, and reply to confirm.

>>>
>>>
>>>
>>> --
>>> Christopher Crouzet
>>> *https://christophercrouzet.com* 
>>>
>>>
>>> --
>>> Softimage Mailing List.
>>> To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com
>>> with "unsubscribe" in the subject, and reply to confirm.
>>>
>>
>>
>> --
>> Softimage Mailing List.
>> To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com
>> with "unsubscribe" in the subject, and reply to confirm.
>>
>
>
>
> --
> Christopher Crouzet
> *https://christophercrouzet.com* 
>
>
> --
> Softimage Mailing List.
> To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com
> with "unsubscribe" in the subject, and reply to confirm.
>
--
Softimage Mailing List.
To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with 
"unsubscribe" in the subject, and reply to confirm.

Re: Up vector on particles flowing on a path

[Matt Lind]

A few cross products:

direction vector x global Y axis = binormal
binormal x direction = your desired up vector

order is important.  Also normalize the resulting vector to be a unit vector 
to make other downstream operations predictable.


Matt





Date: Wed, 26 Apr 2017 18:37:03 -0400
From: Kris Rivel 
Subject: Up vector on particles flowing on a path
To: softimage@listproc.autodesk.com

I'm sure this has come up but how can I get a proper up vector on particles 
flowing along a path? The align on velocity in the flow on path node 
overrides anything else. I want them to align on velocity/direction but also 
stand straight up pointing at Y.

Kris


--
Softimage Mailing List.
To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with 
"unsubscribe" in the subject, and reply to confirm.

Re: shameful houdini question

[Christopher Crouzet]

Technically, VOP is just a wrapper around VEX, so you could say that you're
kinda using VEX... indirectly! :P

@Steven I actually didn't reply to your question at all. I don't know how I
manage to misread emails that well but I'm pretty good at it! Anyways, the
function `pcfind` returns point numbers, so then you can just loop over
them and use the usual methods, such as for example `point
` to retrieve other
attributes.


On 27 April 2017 at 12:33, Olivier Jeannel  wrote:

> Still in the VOP band wagon here :/
>
> 2017-04-27 7:22 GMT+02:00 Christopher Crouzet <
> christopher.crou...@gmail.com>:
>
>> The `Unified Noise VOP`, which is a fairly useful node that outputs all
>> the noise values in the [0, 1] range, takes pretty much all of its logic
>> from the `pyro_noise.h` include file. Which means that you can easily have
>> access to the same functionalities in VEX, like so:
>>
>> #include 
>> v@perlin = vnwrap_perlin3(v@P, 0, 0);
>> f@pflow = fnwrap_pflow1(v@P, {1, 2, 3}, 0);
>>
>>
>> The naming convention of these wrappers is detailed in the file. And in
>> newer versions of Houdini than my H13, they have added a `unified_noise`
>> function that makes it even easier to use.
>>
>> Also, it's interesting to see how they managed to unify the noise values
>> in `pyro_noise.h`: they basically ran a lot of samples and picked the
>> min/max values of each noise to approximate their range. Statistics for the
>> win! :)
>>
>>
>> @Steven To answer your initial question, you can use
>> `pcimport(my_pc_handle, "point.number", my_ptnum_var);` to retrieve the
>> point number.
>>
>> The function `pcfilter` is handy only if you exactly want the behaviour
>> as they documented it. If for example you'd like to use a slightly
>> different weighting formula (based not only on distance but also on mass,
>> for example), then you'd have to write your own.
>>
>>
>> On 27 April 2017 at 11:27, Andy Goehler 
>> wrote:
>>
>>> Hi Steven,
>>>
>>> same as Andy (Nicholas) here, VOPs mostly for Noise stuff, Wrangles for
>>> anything else.
>>>
>>> Cheers and have fun.
>>> Andy
>>>
>>> On Apr 27, 2017, at 12:47 AM, Steven Caron  wrote:
>>>
>>> Just to understand how the power users are using this. Are you using
>>> wrangle nodes with vex snippets 100% of the time or are you using the VOP
>>> sub graph for somethings?
>>>
>>>
>>>
>>> --
>>> Softimage Mailing List.
>>> To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com
>>> with "unsubscribe" in the subject, and reply to confirm.
>>>
>>
>>
>>
>> --
>> Christopher Crouzet
>> *https://christophercrouzet.com* 
>>
>>
>> --
>> Softimage Mailing List.
>> To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com
>> with "unsubscribe" in the subject, and reply to confirm.
>>
>
>
> --
> Softimage Mailing List.
> To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com
> with "unsubscribe" in the subject, and reply to confirm.
>



-- 
Christopher Crouzet
*https://christophercrouzet.com* 
--
Softimage Mailing List.
To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with 
"unsubscribe" in the subject, and reply to confirm.