from:"Christopher"

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* <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* <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

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* <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

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
>>>> <http://www.sidefx.com/docs/houdini/vex/functions/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! :)
>>>>>>
>>>>>>
>>>>>&

Re: shameful houdini question

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
>> <http://www.sidefx.com/docs/houdini/vex/functions/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?
>>>>>
>>>>>

Re: shameful houdini question

@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
> <http://www.sidefx.com/docs/houdini/vex/functions/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* <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* <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* <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

2017-04-26 Thread 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
<http://www.sidefx.com/docs/houdini/vex/functions/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* <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* <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

2017-04-26 Thread 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* <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: Houdini Digital Assets for Softies

2017-03-30 Thread Christopher Crouzet

Ah, I see. Might be worth submitting a bug to see what they say?



On 30 March 2017 at 18:47, Andy Nicholas  wrote:

> Hi Chris,
> You get an error saying "Input data type does not match output for input
> 'input1'." I agree with you that it should work. If you look at passing in
> a non-array value, the VEX code looks like it would be perfectly happy
> receiving an array as it just calls "min(parm)".
>
> I figure it must be some sort of validation that's happening at a higher
> level in the Network Editor that's forbidding the array to be hooked up to
> it.
>
>
>
> On 30/03/2017 10:42, Christopher Crouzet wrote:
>
> Hey Andy,
>
> Seems reasonable?
>>
>
> I am not arguing against the creation of a GetArrayMinimum node, I was
> just being curious to understand what I was missing (the min() VEX
> function always seemed to work for me), so thanks for taking the time to
> explain!
>
> In fact I'm now curious to know why the MinVOP wouldn't work on arrays but
> unfortunately I don't have access to any of the *Array*VOP nodes in Houdini
> 13 so I cannot try it on my end. Does the node errors out when you connect
> a single array into the first input? If not, maybe you can check "View VEX
> Code" to see what's happening there? Since VOP compiles directly to VEX, I
> wouldn't have expected that it'd work in one case but not the other.
>
>
> On 30 March 2017 at 15:58, Andy Nicholas  wrote:
>
>> Hi Chris,
>> Yes, the min() VEX function does indeed work on arrays, but the Min VOP
>> unfortunately doesn’t.
>>
>> It works as a good example though. I don’t want to confuse things, but if
>> we assume for a moment that the Min VOP did actually work on arrays, I
>> think it wouldn’t be unreasonable to find a way to expose the functionality
>> better to an artist, as it’s fairly unusual to have a function that finds
>> the minimum of several inputs, as well as coping with feeding an array in.
>> Creating a node called "Get Array Min” that wraps the “Min” VOP, would make
>> things clearer at a small expense of duplication. Also, if someone hits Tab
>> and types “Array”, then they get to see all the nodes that work on arrays
>> include the new “Get Array Min” node. Without it, they wouldn’t ever see
>> the Min VOP and would risk overlooking that functionality.
>>
>> This way of thinking is similar to what SideFX have been doing with the
>> wrangle SOPs. (For those who don’t know, the Attribute Wrangle,Vertex
>> Wrangle, Point Wrangle, and Primitive Wrangle are all exactly the same
>> nodes, just with different presets applied.) I think this added verbosity
>> of “macro” nodes is okay in situations where it provides clarity and
>> requires the user to remember less. Just as long as you don’t end up with a
>> library of nodes that does nothing but translate the linguistic differences
>> between Softimage and Houdini, as that wouldn’t really help anyone in the
>> long run.
>>
>> But since the Min VOP doesn’t work, I imagine we would just wrap a VEX
>> snippet calling the min() function and make sure it looks as similar as
>> possible to the other VOPs. Seems reasonable?
>>
>> I rarely feel the need for storing arrays in attributes
>>
>>
>> Yep, arrays aren’t needed that often in attributes, but they’re essential
>> for some types of operations, e.g. edge relaxing, where you need to store
>> rest edge lengths. I would imagine that most people who have used a lot of
>> ICE find it quite comfortable to use arrays (e.g strands) and are an
>> essential part of their toolkit, so it makes sense to streamline Houdini's
>> workflow to support it.
>>
>> Maybe the first thing to do before porting a node/workflow from Softimage
>> would be to figure out how to do it best in Houdini, as a way to get more
>> familiar with Houdini's philosophy, and then balance the pros/cons of each
>> approach.
>>
>>
>> Exactly. See what I wrote in the first paragraph in my reply to Jordi
>> yesterday at 20:08 and I think you’ll see we’re thinking on the same lines.
>> Whatever gets made must feel like a natural extension of Houdini and be
>> highly compatible with the standard way of working in Houdini, rather than
>> working against it.
>>
>> I think there’ll be a lot of back and forth about how nodes are authored
>> and what expectations we need to have of them, so do get involved when it
>> moves across to the Google group.
>>
>> A
>>
>>
>>
>> On 30 Mar 2017, at 02:09, Christopher Crouzet <
>> c

Re: Houdini Digital Assets for Softies

2017-03-30 Thread Christopher Crouzet

Hey Andy,

Seems reasonable?
>

I am not arguing against the creation of a GetArrayMinimum node, I was just
being curious to understand what I was missing (the min() VEX function
always seemed to work for me), so thanks for taking the time to explain!

In fact I'm now curious to know why the MinVOP wouldn't work on arrays but
unfortunately I don't have access to any of the *Array*VOP nodes in Houdini
13 so I cannot try it on my end. Does the node errors out when you connect
a single array into the first input? If not, maybe you can check "View VEX
Code" to see what's happening there? Since VOP compiles directly to VEX, I
wouldn't have expected that it'd work in one case but not the other.


On 30 March 2017 at 15:58, Andy Nicholas  wrote:

> Hi Chris,
> Yes, the min() VEX function does indeed work on arrays, but the Min VOP
> unfortunately doesn’t.
>
> It works as a good example though. I don’t want to confuse things, but if
> we assume for a moment that the Min VOP did actually work on arrays, I
> think it wouldn’t be unreasonable to find a way to expose the functionality
> better to an artist, as it’s fairly unusual to have a function that finds
> the minimum of several inputs, as well as coping with feeding an array in.
> Creating a node called "Get Array Min” that wraps the “Min” VOP, would make
> things clearer at a small expense of duplication. Also, if someone hits Tab
> and types “Array”, then they get to see all the nodes that work on arrays
> include the new “Get Array Min” node. Without it, they wouldn’t ever see
> the Min VOP and would risk overlooking that functionality.
>
> This way of thinking is similar to what SideFX have been doing with the
> wrangle SOPs. (For those who don’t know, the Attribute Wrangle,Vertex
> Wrangle, Point Wrangle, and Primitive Wrangle are all exactly the same
> nodes, just with different presets applied.) I think this added verbosity
> of “macro” nodes is okay in situations where it provides clarity and
> requires the user to remember less. Just as long as you don’t end up with a
> library of nodes that does nothing but translate the linguistic differences
> between Softimage and Houdini, as that wouldn’t really help anyone in the
> long run.
>
> But since the Min VOP doesn’t work, I imagine we would just wrap a VEX
> snippet calling the min() function and make sure it looks as similar as
> possible to the other VOPs. Seems reasonable?
>
> I rarely feel the need for storing arrays in attributes
>
>
> Yep, arrays aren’t needed that often in attributes, but they’re essential
> for some types of operations, e.g. edge relaxing, where you need to store
> rest edge lengths. I would imagine that most people who have used a lot of
> ICE find it quite comfortable to use arrays (e.g strands) and are an
> essential part of their toolkit, so it makes sense to streamline Houdini's
> workflow to support it.
>
> Maybe the first thing to do before porting a node/workflow from Softimage
> would be to figure out how to do it best in Houdini, as a way to get more
> familiar with Houdini's philosophy, and then balance the pros/cons of each
> approach.
>
>
> Exactly. See what I wrote in the first paragraph in my reply to Jordi
> yesterday at 20:08 and I think you’ll see we’re thinking on the same lines.
> Whatever gets made must feel like a natural extension of Houdini and be
> highly compatible with the standard way of working in Houdini, rather than
> working against it.
>
> I think there’ll be a lot of back and forth about how nodes are authored
> and what expectations we need to have of them, so do get involved when it
> moves across to the Google group.
>
> A
>
>
>
> On 30 Mar 2017, at 02:09, Christopher Crouzet <
> christopher.crou...@gmail.com> wrote:
>
> Regarding GetArrayMinimum: there is a min()
> <http://www.sidefx.com/docs/houdini/vex/functions/min> function in VEX,
> or were you referring to something else?
>
> Note that I'm still using Houdini 13 where support for arrays is not as
> extended as in later versions, but I rarely feel the need for storing
> arrays in attributes, or even using arrays at all in my code. An example of
> exception would be to store the list of neighbouring indices for the
> downstream nodes to use, but then it's likely that putting all the logic in
> a single monolithic VEX instead wouldn't be such a bad approach.
>
> Maybe the first thing to do before porting a node/workflow from Softimage
> would be to figure out how to do it best in Houdini, as a way to get more
> familiar with Houdini's philosophy, and then balance the pros/cons of each
> approach.
>
>
> PS: I personally find it cool to see the list revived with Hou

Re: Houdini Digital Assets for Softies

2017-03-29 Thread Christopher Crouzet

nts
>
> to chime in. Final decision can happen tomorrow.
>
>
>
>
>
>
> On 29/03/2017 17:38, Olivier Jeannel
>
> wrote:
>
>
>
>
> Autodesk lib ?
>
> N too rancorous...
>
>
>
>
>
> On Wednesday, March 29, 2017, Andy Nicholas 
>
> wrote:
>
>
>
> I'd probably go with
>
> something like Andy's siLib or softLib - it's a bit more
>
> obvious what it is. Probably the latter if it was up to me.
>
>
>
>
>
> What do you guys think? Any other suggestions?
>
>
>
>
> On 29/03/2017 17:14, Jonathan Moore wrote:
>
>
>
>
>
>
> I was thinking H20...
>
>
>
>
>
> On 29 March 2017 at 17:12, Andy
>
> Goehler 
>
> wrote:
>
> In
>
> honor of inspiration how about?
>
>
>
>
>
> • softLib
>
>
> • siLib
>
>
> • ICELib
>
>
>
>
>
>
>
>
>
> > On Mar 29, 2017, at 6:08 PM, Andy Nicholas
>
> 
>
> wrote:
>
>
> >
>
>
> > Continuing the thread here:
>
>
> >
>
>
> > Any suggestions for a name?
>
>
> > A
>
>
> >
>
>
> > On 29/03/2017 17:00, Andy Nicholas wrote:
>
>
> >> I'm more than happy to help. I'm just
>
> unsure how much time I'll be
>
>
> >> able to devote to this as I'm pretty
>
> busy with some personal work at
>
>
> >> the moment.
>
>
> >>
>
>
> >> How about I set up something similar to
>
> Nick's on Github and we go
>
>
> >> from there?
>
>
> >>
>
>
> >> We need a name for it. Let's start a
>
> new thread on the list and move
>
>
> >> discussions over to that. Is that okay?
>
>
> >>
>
>
> >> 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.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> --
>
> 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.
>
>
>
> --
> 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.
>



-- 
Christopher Crouzet
*https://christophercrouzet.com* <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: Emit particles frm surfaces facing a particular direction?

2017-03-14 Thread Christopher Crouzet

> > > >
> > > > >
> > > > > > Den 14. marts 2017 klokken 11:11 skrev p...@bustykelp.com:
> > > > > >
> > > > > >
> > > > > > You can either
> > > > > >
> > > > > > Emit from the whole and delete the ones that aren't pointing in
> > > > > > the
> > > > > > right
> > > > > > direction, (based on comparing the normal angle to your preferred
> > > > > > vector)
> > > > > >
> > > > > > Or create a weightmap on the object and use ICE to set the values
> > > > > > based
> > > > > > upon
> > > > > > the normal angle and use the weightmap in the Emit node. (This
> > > > > > wont
> > > > > > work
> > > > > > on
> > > > > > low poly meshes for obvious reasons)
> > > > > >
> > > > > > Or make a duplicate of the surface, and use ICE to delete Polys
> > > > > > that
> > > > > > aren't
> > > > > > pointing in the right direction, then emit from the resulting
> > > > > > object.
> > > > > >
> > > > > >
> > > > > > Number 1 is the easiest to set up.
> > > > > >
> > > > > > Paul
> > > > > >
> > > > > >
> > > > > > -Original Message-
> > > > > > From: Morten Bartholdy
> > > > > > Sent: Tuesday, March 14, 2017 10:05 AM
> > > > > > To: Userlist, Softimage
> > > > > > Subject: Emit particles frm surfaces facing a particular
> > > > > > direction?
> > > > > >
> > > > > > I have looked through the sample scenes but could not find
> > > > > > something
> > > > > > that
> > > > > > does this. I want to emit particles from surfaces of an object
> > > > > > that
> > > > > > faces
> > > > > > in
> > > > > > a particular direction, either a custom vector or fom polygons
> > > > > > facing
> > > > > > a
> > > > > > null.
> > > > > >
> > > > > > How can I do this?
> > > > > >
> > > > > > Thanks.
> > > > > >
> > > > > > Morten
> > > > > > --
> > > > > > 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.aut
> odesk.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.
> > --
> > 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.
>



-- 
Christopher Crouzet
*https://christophercrouzet.com* <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: houdini question (and where to ask)

2017-03-07 Thread Christopher Crouzet

I naively compared the AttribPromote with an AttribWrangle in detail mode,
and the results were much (much) faster with the AttribPromote, so I assume
it is multi-threaded and would be hard to beat with any sort of wrangle
trickery.

I'm still stuck with H13 so I didn't know about the numbers mode, that's
neat!


On 7 March 2017 at 16:43, Andy Nicholas  wrote:

> Andy, the O(N) thing got me thinking and realized that instead of running
> the attrib wrangle in detail mode, which uses only a single thread, it'd be
> possible to generate say 4 points and, in a point wrangle, let each of
> these points process 1/4th of the array, thus effectively running the same
> logic on 4 threads! Another attrib wrangle is then needed in post to sum up
> the result from each point. Well, in all honesty I don't think there'll
> ever be a use case for it :)
>
>
> Yes absolutely! Definitely a good approach if you're after performance.
> It'd be interesting to do a comparison between that and an Attribute
> Promote SOP to see which is faster. I suspect (i.e. hope) the Attribute
> Promote SOP is multithreaded, so probably no major advantage.
>
> BTW, you don't even need to generate the 4 points as you've got the Run
> Over "Numbers" mode which will do the same. You can save the result into a
> detail array attribute and analyse it in a Detail Wrangle. Just takes a bit
> more management to set it up.
>
>
>
>
> On 07/03/2017 01:35, Christopher Crouzet wrote:
>
> Wow, I shouldn't have wrote that late last night, I completely mixed
> things up in my previous post, sorry!
>
> I'll try again! With a ramp, you have the source (input) values on the X
> axis, and the target (output) values on the Y axis. If either your source
> or target values aren't in the range [0, 1], you can remap them using a
> simple float parameter (to use as a simple multiplier if your desired lower
> bound is 0), or a float2 parameter to precisely control the desired range.
>
> It seems to be a standard practice in Houdini since they use it for some
> built-in nodes, such as the Pyro SHOP.
>
> Andy, the O(N) thing got me thinking and realized that instead of running
> the attrib wrangle in detail mode, which uses only a single thread, it'd be
> possible to generate say 4 points and, in a point wrangle, let each of
> these points process 1/4th of the array, thus effectively running the same
> logic on 4 threads! Another attrib wrangle is then needed in post to sum up
> the result from each point. Well, in all honesty I don't think there'll
> ever be a use case for it :)
>
>
> On 7 March 2017 at 01:14, Olivier Jeannel  wrote:
>
>> Ok we agree.
>>
>>
>> On Monday, March 6, 2017, Jonathan Moore 
>> wrote:
>>
>>> As far as I understood it Oliver, the spline version of the Houdini Ramp
>>> only operates in the zero to one range. You re-fit the values pre/post/ or
>>> both to suite your needs.
>>>
>>>
>>>
>>> I get that this doesn’t match the UX of FCurves in XSI, but I’ve always
>>> understood Ramp’s in Houdini to be more of a lower level discrete element
>>> in visual programing terms.
>>>
>>>
>>>
>>> *From:* softimage-boun...@listproc.autodesk.com [mailto:
>>> softimage-boun...@listproc.autodesk.com] *On Behalf Of *Olivier Jeannel
>>> *Sent:* 06 March 2017 17:31
>>> *To:* Official Softimage Users Mailing List.
>>> https://groups.google.com/forum/#!forum/xsi_list <
>>> softimage@listproc.autodesk.com>
>>> *Subject:* Re: houdini question (and where to ask)
>>>
>>>
>>>
>>> Not sure I get it Christopher (not in front of H)
>>>
>>> Does your trick actualy change the graph visualy ?
>>>
>>> In short, can I see the negative x & y values ?
>>>
>>> On Monday, March 6, 2017, Christopher Crouzet <
>>> christopher.crou...@gmail.com> wrote:
>>>
>>> Indeed, which is why I mentioned the “detail” mode which brings you back
>>> to O(N). Not saying that one approach is better than the other though, only
>>> that it is possible.
>>>
>>>
>>>
>>> On 7 March 2017 at 00:12, Andy Nicholas  wrote:
>>>
>>> Yep it is possible, but you wouldn't want to do it because each
>>> calculation of the maximum value would be running across N points to
>>> calculate that. That'd make it an O(N^2) operation, albeit spread over
>>> multiple threads.
>>>
>>> It might seem like a pain to have to do this in advance usi

Re: houdini question (and where to ask)

2017-03-06 Thread Christopher Crouzet

Wow, I shouldn't have wrote that late last night, I completely mixed things
up in my previous post, sorry!

I'll try again! With a ramp, you have the source (input) values on the X
axis, and the target (output) values on the Y axis. If either your source
or target values aren't in the range [0, 1], you can remap them using a
simple float parameter (to use as a simple multiplier if your desired lower
bound is 0), or a float2 parameter to precisely control the desired range.

It seems to be a standard practice in Houdini since they use it for some
built-in nodes, such as the Pyro SHOP.

Andy, the O(N) thing got me thinking and realized that instead of running
the attrib wrangle in detail mode, which uses only a single thread, it'd be
possible to generate say 4 points and, in a point wrangle, let each of
these points process 1/4th of the array, thus effectively running the same
logic on 4 threads! Another attrib wrangle is then needed in post to sum up
the result from each point. Well, in all honesty I don't think there'll
ever be a use case for it :)


On 7 March 2017 at 01:14, Olivier Jeannel  wrote:

> Ok we agree.
>
>
> On Monday, March 6, 2017, Jonathan Moore 
> wrote:
>
>> As far as I understood it Oliver, the spline version of the Houdini Ramp
>> only operates in the zero to one range. You re-fit the values pre/post/ or
>> both to suite your needs.
>>
>>
>>
>> I get that this doesn’t match the UX of FCurves in XSI, but I’ve always
>> understood Ramp’s in Houdini to be more of a lower level discrete element
>> in visual programing terms.
>>
>>
>>
>> *From:* softimage-boun...@listproc.autodesk.com [mailto:
>> softimage-boun...@listproc.autodesk.com] *On Behalf Of *Olivier Jeannel
>> *Sent:* 06 March 2017 17:31
>> *To:* Official Softimage Users Mailing List.
>> https://groups.google.com/forum/#!forum/xsi_list <
>> softimage@listproc.autodesk.com>
>> *Subject:* Re: houdini question (and where to ask)
>>
>>
>>
>> Not sure I get it Christopher (not in front of H)
>>
>> Does your trick actualy change the graph visualy ?
>>
>> In short, can I see the negative x & y values ?
>>
>> On Monday, March 6, 2017, Christopher Crouzet <
>> christopher.crou...@gmail.com> wrote:
>>
>> Indeed, which is why I mentioned the “detail” mode which brings you back
>> to O(N). Not saying that one approach is better than the other though, only
>> that it is possible.
>>
>>
>>
>> On 7 March 2017 at 00:12, Andy Nicholas  wrote:
>>
>> Yep it is possible, but you wouldn't want to do it because each
>> calculation of the maximum value would be running across N points to
>> calculate that. That'd make it an O(N^2) operation, albeit spread over
>> multiple threads.
>>
>> It might seem like a pain to have to do this in advance using an
>> Attribute Promote, but by doing so, it's actually forcing you to work in a
>> more efficient way. Go with it ;)
>>
>>
>>
>> On 06/03/2017 16:32, Christopher Crouzet wrote:
>>
>> It *is* possible to retrieve the maximum value in a VOP since nothing
>> stops anyone from manually iterating through all the points of the
>> geometry. This kind of operation might be more suited in “detail” mode
>> though.
>>
>> Also, having the ramp normalized to the [0, 1] range in both the X and Y
>> axis is usually “workarounded” by adding a float parameter for the
>> amplitude (Y axis) that is used as a global multiplier (making later
>> tweakings convenient!), and a float2 parameter for the target range (X
>> axis) that is then remapped using `fit("my_ramp", 0.0, 1.0, range_min,
>> range_max)` (which is also convenient for later tweakings!).
>>
>> Now, if you really want to have an actual FCurve, then just create a
>> simple float parameter, add all the keys however you want, then query it in
>> using `chf("my_param", the_time_in_seconds)` in VEX/VOP, or using the
>> equivalent expression.
>>
>>
>>
>> On 6 March 2017 at 23:29, Jonathan Moore 
>> wrote:
>>
>> Fabricio ,
>>
>>
>>
>> The Attribute Promote help page has approx 15 examples you can load.
>> Hopefully you might find something within the examples to inspires a
>> solution.
>>
>>
>>
>> *From:* softimage-boun...@listproc.autodesk.com [mailto:
>> softimage-boun...@listproc.autodesk.com] *On Behalf Of *Olivier Jeannel
>> *Sent:* 06 March 2017 15:56
>> *To:* Official Softimage Users Mailing List.
>> https://groups.google.com/forum/#!forum/xs

Re: houdini question (and where to ask)

2017-03-06 Thread Christopher Crouzet

Indeed, which is why I mentioned the “detail” mode which brings you back to
O(N). Not saying that one approach is better than the other though, only
that it is possible.


On 7 March 2017 at 00:12, Andy Nicholas  wrote:

> Yep it is possible, but you wouldn't want to do it because each
> calculation of the maximum value would be running across N points to
> calculate that. That'd make it an O(N^2) operation, albeit spread over
> multiple threads.
>
> It might seem like a pain to have to do this in advance using an Attribute
> Promote, but by doing so, it's actually forcing you to work in a more
> efficient way. Go with it ;)
>
>
>
> On 06/03/2017 16:32, Christopher Crouzet wrote:
>
> It *is* possible to retrieve the maximum value in a VOP since nothing
> stops anyone from manually iterating through all the points of the
> geometry. This kind of operation might be more suited in “detail” mode
> though.
>
> Also, having the ramp normalized to the [0, 1] range in both the X and Y
> axis is usually “workarounded” by adding a float parameter for the
> amplitude (Y axis) that is used as a global multiplier (making later
> tweakings convenient!), and a float2 parameter for the target range (X
> axis) that is then remapped using `fit("my_ramp", 0.0, 1.0, range_min,
> range_max)` (which is also convenient for later tweakings!).
>
> Now, if you really want to have an actual FCurve, then just create a
> simple float parameter, add all the keys however you want, then query it in
> using `chf("my_param", the_time_in_seconds)` in VEX/VOP, or using the
> equivalent expression.
>
>
> On 6 March 2017 at 23:29, Jonathan Moore 
> wrote:
>
>> Fabricio ,
>>
>>
>>
>> The Attribute Promote help page has approx 15 examples you can load.
>> Hopefully you might find something within the examples to inspires a
>> solution.
>>
>>
>>
>> *From:* softimage-boun...@listproc.autodesk.com [mailto:
>> softimage-boun...@listproc.autodesk.com] *On Behalf Of *Olivier Jeannel
>> *Sent:* 06 March 2017 15:56
>> *To:* Official Softimage Users Mailing List.
>> https://groups.google.com/forum/#!forum/xsi_list <
>> softimage@listproc.autodesk.com>
>>
>> *Subject:* Re: houdini question (and where to ask)
>>
>>
>>
>> You can't get the "get maximum in set" when inside a vop.
>>
>> But, you get those options with the promote attribute sop.
>>
>>
>>
>>
>> On Monday, March 6, 2017, Oscar Juarez  wrote:
>>
>> I would like to be proven wrong, but that would be the way, I mean in
>> your second pointvop you don't need to add another noise, your noise is
>> already saved in an attribute, when you promote just check off delete
>> original and you can access the same noise. Also noises have specific
>> output ranges, they come in the documentation, so you can always add a fit
>> node to change your range to what you need, in the geometry spreadsheet you
>> can also sort by value so you can see max and min.
>>
>>
>>
>> If you press X with your mouse over the noise output it will add a
>> visualization node, you can visualize on the viewport or in the geometry
>> spreadsheet the values. I know its not the same but as far as I know their
>> is no way to do the same as the get maximum in set node in a vopsop context.
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Mar 6, 2017 at 3:57 PM, Fabricio Chamon 
>> wrote:
>>
>> thanks everyone. The ramp parameter kind of works but as you say, is not
>> that user friendly and does not show the points below 0. (that's ok, but I
>> wonder if it is possible to write a custom widget in houdini)
>>
>>
>>
>> anyway, the thing I could not get right just yet is that sort of "get
>> maximum in set" thing. Sorry for using ICE language, I'm trying to be open
>> minded here, so please tell me if that`s not the correct mindset.
>>
>>
>>
>> so on this graph:
>>
>>
>>
>> [image: Imagem inline 1]
>>
>>
>>
>> ...how could I get the maximum value of the output noise node and compare
>> to a single point output of the same node?
>>
>>
>>
>> From what I can tell, I'd have to:
>>
>>
>>
>> 1- create this pointvop node with a turbnoise, then store the output
>> noise into an attribute (via bindexport?)
>>
>> 2- up one level -> drop an attrib promote (detail), set to maximum
>>
>> 3- drop another pointvop node with another noise node inside (same
>

Re: houdini question (and where to ask)

2017-03-06 Thread Christopher Crouzet

node will get an set datas.
>
> Ramp Parameters is sort of fcurve.
>
> It's a bit weak in terms of curve manipulation, but does the job.
>
> It has 2 modes rgb (ramp) and spline.
>
> If you use several ramps in the same vop, name them with different name or
> they might not export.
>
>
>
> Le 6 mars 2017 14:28, "Fabricio Chamon"  a écrit :
>
> ..sorry, hit send too soon.
>
>
>
> Question #1: are there any equivalents to ICE "get ... in set"? or or do I
> have to iterate and store values for later comparision? In other words:
> what is the best or recommended workflow to compare single point data with
> global point data?
>
>
>
> Question #2: any nodes that resemble a fCurve node, like we have in ICE?
> if not, what is the alternative?
>
>
>
> and finally, I can see this list is becoming more and more houdini-esque
> than ever..but, what is the best place to ask beginner questions like the
> above? houdini foruns, houdini list, odForce...
>
>
>
> thanks!
>
>
>
> 2017-03-06 14:23 GMT+01:00 Fabricio Chamon :
>
> Hi, I'm slowly getting into houdini and this is my first attempt to port a
> really simple ridged fractal deformer made in ICE to houdini (using
> pointvop).
>
>
>
> Question #1: are there any equivalents to ICE "get ... in set"? or or do I
> have to iterate and store values for later comparision? In other words:
> what is the best or recommended workflow to compare single point data with
>
>
>
>
> --
> 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.
>
>
>
>
> --
> 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* <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: Houdini - Using an Attribute to drive an operator value

2017-03-02 Thread Christopher Crouzet

I also had issues figuring that out at first. There doesn't seem to be any
hard rule nor consitency and that's simply because not every node operates
on the same kind of data (nor provide support for the same feature set).
One way to know is to check if the $PT variable is available when typing an
HScript expression in a parameter. Which is not the case for the Peak SOP,
at least for me in Houdini 13.

But you know what? You can have the same result with a custom operator made
in less than 2 minutes. Create a VOP SOP, or an Attribute Wrangle SOP, and
for each point you only have to add the normal to the position, with the
coefficient value from your painted attribute.

Example in VEX: v@P += normalize(v@N) * f@my_painted_attribute;

On 2 March 2017 at 20:38,  wrote:

>
> Hi,
>
> I’ve just started learning Houdini. I’m finding it hard to find knowledge
> on how to have an attribute, that I’ve created then painted, to drive ,say
> the per point value of a peak deformer node
>
> I have tried the point expression, but I get a load of errors.
>
> does anyone know please?
>
> thanks
> Paul ‘pooby’ Smith
>
> --
> 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* <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: [Houdini] Working with strands the Softimage way

2017-03-02 Thread Christopher Crouzet

If it can help, here's a basic scene showing one common approach for making
strands: https://filebin.net/6ml27y3atb6qd7iq


On 2 March 2017 at 20:17, Tim Bolland  wrote:

> Thank you Andy that's a really helpful summation, I'm going to give it a
> go :)
>
>
> --
> *From:* softimage-boun...@listproc.autodesk.com <
> softimage-boun...@listproc.autodesk.com> on behalf of Andy Nicholas <
> a...@andynicholas.com>
> *Sent:* 02 March 2017 13:12
>
> *To:* softimage@listproc.autodesk.com
> *Subject:* Re: [Houdini] Working with strands the Softimage way
>
>
> Just to confirm how I'm thinking about this, a strand in Houdini is
> typically made up of point positions, not points with arrays as attributes.
> You can manually add an attribute to each point position to say which
> strand it's part of, there's a node that generates lines that will
> then understand this?
>
>
> What I'm saying is that's something you can implement yourself. There are
> no nodes in Houdini that understand a point with a vector array is a
> strand, and no shaders that will do that automatically either. Again, you
> can build that yourself if you like, but it's quite advanced if you're
> going to be delving into procedural geometry shaders.
>
> Otherwise you can create polyline primitives and feed point IDs into it.
> This will generate a polygon line (polyline) between the vertices in the
> primitive, and in some ways this is just like the point[pointarray]
> technique.
>
>
> Yep. A polyline is nothing special. Just an unclosed polygon. As others
> have pointed out, you can apply attributes to the points to set things like
> width and color. Or you can use something like the PolyWire SOP to generate
> your own rendertime geometry.
>
> The key is how do you create these point clusters and the order. In ICE I
> would make strands using a build linearly interpolated array with two
> vectors feeding into it. I guess I could try and recreate this using
> vex/vops, and maybe that's what I'm after, I just need to find a way to
> manipulate all these points in the right order.
>
>
> Easiest way (assuming you already have some animated points) is to use the
> Trail SOP with it set to "Connect as Polygons", turn "Close rows" off, and
> set "Trail Length" to something like 10. Next stop after that is to take a
> look at the Resample SOP. Especially the "Treat Polygons As" parameter, as
> that'll let you create interpolated shapes to your trails which is kind
> handy.
>
> A
>
>
>
>
> On 02/03/2017 12:58, Tim Bolland wrote:
>
> That's a good point Andy, and in my mind this would make the most sense!
> But like you say maybe not the most supported.
>
>
> Just to confirm how I'm thinking about this, a strand in Houdini is
> typically made up of point positions, not points with arrays as attributes.
> You can manually add an attribute to each point position to say which
> strand it's part of, there's a node that generates lines that will
> then understand this?
>
>
> Otherwise you can create polyline primitives and feed point IDs into it.
> This will generate a polygon line (polyline) between the vertices in the
> primitive, and in some ways this is just like the point[pointarray]
> technique.
>
> The key is how do you create these point clusters and the order. In ICE I
> would make strands using a build linearly interpolated array with two
> vectors feeding into it. I guess I could try and recreate this using
> vex/vops, and maybe that's what I'm after, I just need to find a way to
> manipulate all these points in the right order.
>
> I'm rambling a bit here, but hopefully getting somewhere!
>
> Cheers,
>
> Tim
>
> --
> *From:* softimage-boun...@listproc.autodesk.com
> 
>  on behalf of Andy Nicholas
>  
> *Sent:* 02 March 2017 12:27
> *To:* softimage@listproc.autodesk.com
> *Subject:* Re: [Houdini] Working with strands the Softimage way
>
> Hi Tim,
> Did you notice that you can do per-point array attributes in VEX? There's
> nothing stopping you setting up position vector arrays on each point, just
> like in ICE, and then using a Point Wrangle at the end to use that array to
> generate a polyline. The problem is that you then have to write all those
> handy ICE nodes like "Simulate Strands", etc. yourself.
>
> That's why generally, you're better off just trying to use polylines as a
> primitive as they're more supported by Houdini's other frameworks (e.g.
> wire solver) and constraints.
>
> A
>
&g

Re: [Houdini] Working with strands the Softimage way

2017-03-02 Thread Christopher Crouzet

I've never used Softimage's strands but from looking at this page
<http://softimage.wiki.softimage.com/xsidocs/ICE_strands_CreatingStrands.htm>,
it seems straighforward to reproduce in Houdini. If you emit particles and
advect their position by the velocity of your volume, then you can use the
Trail SOP to retrieve the position of each particle at each frame up to say
5 frames before, which will give you 5 points for each particle that you
only need to connect together using Add SOP (Polygons -> By Group -> Add By
Attribute -> 'id'). Then you can edit/animate your velocity field in SOP to
give some variation to your particles, or use some POP nodes in your DOP
network. Finally, you can define a 'width' attribute representing the width
of the resulting curves at each point and render as-is, or plug-in a
Polywire SOP as you mentioned to output some polygons.

On 2 March 2017 at 18:05, Tim Bolland  wrote:

> Hey guys, I'm after a little advice. I'm currently looking at building a
> some nice fluffy clouds made up of strands and from what I can see there a
> load of different ways to achieve something like this Houdini. Quite of few
> of the results I've seen demonstrated online are achieved by creating a
> velocity volume and drawing these the velocities out. These look nice but I
> cant really figure out a way to edit them afterwards. Other methods I've
> seen that look promising take points and running them through a Polywire,
> however there seem to a load of ways to group these points together and
> nothing is as succinct at position / strandposition
>
>
> What I'm wondering is what do you recommend? Is there a method of strand
> creation / manipulation that gives you a nice amount of flexibility and
> control? I've always been a huge fan of ICE strands, and the concept of
> starting with some points, building up strandpositions a long these points
> and controlling the properties of the strands by either the point ID or the
> strandposition ID.
>
>
> From what I can see there is not equivalent workflow that I can find, at
> least not out of the box. I can make polywires with ID's and manipulate
> this, but I'm still a little confused about the ID vs strandID context
> equivalent and how to manipulate each of them. Any advice would be
> appreciated.
>
> Cheers,
>
>
> Tim
>
> --
> 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* <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: slowing down particles

2017-02-23 Thread Christopher McCabe

Excuse my post... I have not used XSI in over a year now. But I *think* you
could plot the particles with a "shape" plot? Then adjust the speed once
you bring it back in as a animation clip.

I had to do this to slow down a syflex simulation. Should work the same for
your situation?



On Thu, Feb 23, 2017 at 4:25 PM, Sven Constable 
wrote:

> If you plug in into the last ICE port just before the Simulate Particles
> node it should override the other stuff. Or create another ICE tree below
> all others (if you have more than one, driving the particles).
>
>
>
> *From:* softimage-boun...@listproc.autodesk.com [mailto:softimage-bounces@
> listproc.autodesk.com] *On Behalf Of *Kris Rivel
> *Sent:* Thursday, February 23, 2017 11:05 PM
>
> *To:* Official Softimage Users Mailing List. https://groups.google.com/
> forum/#!forum/xsi_list
> *Subject:* Re: slowing down particles
>
>
>
> no I have other noise stuff going on that ignores that. Wish there was a
> global effect I could use.
>
>
>
> On Thu, Feb 23, 2017 at 4:35 PM, Sven Constable 
> wrote:
>
> Maybe just using a drag force?
>
>
>
> *From:* softimage-boun...@listproc.autodesk.com [mailto:softimage-bounces@
> listproc.autodesk.com] *On Behalf Of *Kris Rivel
> *Sent:* Thursday, February 23, 2017 10:28 PM
> *To:* Official Softimage Users Mailing List. https://groups.google.com/
> forum/#!forum/xsi_list
> *Subject:* Re: slowing down particles
>
>
>
> Yes ice particles...that kind of does it but I have them emitting so its
> doing it based on age...new particles are still moving quickly. I want to
> slow all of them down globally.
>
>
>
> On Thu, Feb 23, 2017 at 4:16 PM, Eric Thivierge 
> wrote:
>
> If you're talking ICE particles then you could get the particle velocity >
> Mulitply Scalar (0.9) > set particle velocity or something like that.
>
>
> 
> Eric Thivierge
> http://www.ethivierge.com
>
>
>
> On Thu, Feb 23, 2017 at 4:13 PM, Kris Rivel  wrote:
>
> I have a nice effect for my particles...some turbulent snow. But now I
> want to slowly slow them down till they freeze in place. Is this possible?
> I want a gradual deceleration till they're locked in space.
>
> 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.
>
>
>
>
> --
> 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: thickness - avoiding self intersections

2016-12-12 Thread Christopher Crouzet

Have you tried using `AttribTransfer SOP` to transfer the UVs from the
original mesh onto the output of the node 'polyreduce1', and then merging?


On 12 December 2016 at 22:41, toonafish  wrote:

> you could try Meshmixer, it’s free and used for 3D printing but has a
> “hollowing” feature that might work.
>
> -Ronald
>
>
>
> On 12 Dec 2016, at 16:25, Fabricio Chamon  wrote:
>
> ...well and minutes after writing the e-mail I found a really reliable
> solution in houdini, that is messing with vdb to smooth the internal part.
> The vdbsmooth op retains the nice sharp corners while reducing
> intersections, that is exactly what I want! The only problem is how to
> merge both parts back while mantaining UVs. Houdini is giving me this
> warning: *"A mis-match of attributes on the inputs was detected. Some of
> the attribute values may not be initialized to expected values, i.e.: name,
> path, N, uv."*
>
> Of course this is me not handling the attribute transfer correctly, so any
> help is much appreciated! =)
>
> Tree and results:
>
> 
>
> 2016-12-12 12:55 GMT-02:00 Fabricio Chamon :
>
>> Hey everybody,
>>
>> what are your choices when it comes to thickness/solidify (or whatever
>> you call it) geometry?
>> What software/operator or plugin you find most reliable to ouput a good
>> geo?
>>
>> I'm doing some fracture work lately, and I've always had problems to
>> solidify complex geometry (with varying thickness/sharp angles and
>> corners/etc). It ends up self-intersecting the inside part, which obviusly
>> causes problems when you have to shatter later on.
>>
>> Here's a good example, this is a corner piece from a rubiks cube (left
>> original, right solidified, bottom isolated internal result geo):
>>
>> 
>>
>> I've tried some options like:
>>
>> - apply the operator, then select the internal part and relax/smooth the
>> geo (not ideal, since it starts to degrade the original shape, to the point
>> it starts creating some internal/external intersections in some areas)
>>
>> - using blender, that has a nice feature on its thickness operator called
>> "clamp". It is exaclty what I need, but it's limited and does not work good
>> in this piece for some reason.
>>
>> I'm sure there are more smart options out there...maybe a vdb stuff for
>> the internal part, then converting it back to geo, but I'm out of ideas
>> right now.
>>
>> How would you approach this ? (mesh is attached, in case someone wants to
>> give it a shot).
>>
>> Thanks a lot guys!
>>
>
> --
> 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
*http://christophercrouzet.com* <http://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: Houdini voronoi to Soft - disconnected faces?

2016-12-06 Thread Christopher Crouzet

For information, I also had issues with the Voronoi SOP creating a
suboptimal mesh output (disconnected points here and there) and found that
the scale of the object can greatly influence the quality of the fracture.
So just crank up the scale to reach a bounding box of around 100-1000 units
(don't go too high or this might cause floating-point issues), apply the
Voronoi SOP, and revert the scale back. Another helpful thing to do, as
recommended by SESI, is to avoid an input geometry with non-planar faces by
inserting a Divide SOP before the fracture.

Well, even with these 2 tips it still might not work depending on the input
geometry.


On 6 December 2016 at 21:29, Fabricio Chamon  wrote:

> ok solved exporting through a ROP node instead of file node. Now alembic
> imports fine and all faces are good. =)
>
> 2016-12-06 12:15 GMT-02:00 Fabricio Chamon :
>
>> Well, unfortunatelly soft crashes everytime I try to import this alembic
>> mesh from houdini... so I went for objs.
>>
>> And I'm afraid I can't merge them in Soft because a) it will take quite
>> some time as the whole geo is dense and b) I'd have to leave a gap between
>> the pieces or else any adjacent pieces would get merged together... and I
>> want them to be single pieces.
>>
>> is that an export thing ? Because it works nicely inside houdini...
>>
>> 2016-12-06 12:07 GMT-02:00 nikaragua86 :
>>
>>> hi, i had the same issue, exported simulation from houdini to maya with
>>> alembic, i just merged vertices in maya
>>>
>>> 2016-12-06 17:00 GMT+03:00 Fabricio Chamon :
>>>
>>>> Hey gang,
>>>>
>>>> I'm doing a voronoi shatter in houdini and want to bring the result
>>>> back into softimage (exporting .obj to Soft 2015 SP2). The outside pieces
>>>> are disconected from the inside pieces, like this:
>>>>
>>>> [image: Imagem inline 1]
>>>>
>>>> I'm pretty sure it's me doing something wrong in houdini... My setup is
>>>> really simple: Import alembic mesh > vdb from polys > scatter > voronoi
>>>> with those points. Already tried to mess with all the voronoi parameters
>>>> and add a fuse node at the very end just before exporting. But I can't find
>>>> a way to have the outside/inside faces merged for each piece.
>>>>
>>>> any hints?
>>>>
>>>> Thank you
>>>>
>>>> --
>>>> 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.
>



-- 
Christopher Crouzet
*http://christophercrouzet.com* <http://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: OT: Softs Duplicate Symmetry in Maya?

2016-07-18 Thread Christopher McCabe

Actually. Get rid of renameChildren,

duplicate -rr -un; scale -r -1 1 1;
searchReplaceNames "l_" "r_" "hierarchy";


On Mon, Jul 18, 2016 at 10:45 AM, Christopher McCabe <
christopher.mccabe...@gmail.com> wrote:

> I don't know how complicated of a rig this will work for but... I created
> a joint chain and constrained primitives to several of the joints with
> parent, and point constraints. Put everything under a group located at
> world 0.
>
> Ran in MEL:
> duplicate -rr -renameChildren -un; scale -r -1 1 1;
>
> Then run this to rename:
> searchReplaceNames "l_" "r_" "hierarchy";
>
>
>
>
> On Mon, Jul 18, 2016 at 8:11 AM, Oz Adi  wrote:
>
>> Thanks,
>>
>>
>>
>> Seems like a basic rigging tool that needs to be in every 3d package, to
>> be able to mirror a complete rig..
>> I’ve already built the other side from scratch, it wasn’t a big complex
>> rig, but it was a waste of time :/
>>
>> I have not scripted for a few years now.. I’ll have to refresh my Jscript
>> knowledge, and try to use it on learning some python I guess.
>>
>>
>> so far switching to maya feels like a huge regression, I am sure it’ll
>> get easier over time, but maya sure has some sickness to it, and sometimes
>> feels like it came from the 80’s…
>>
>> (no offence to people born in the 80’s, myself is from the early 70’s J )
>>
>>
>>
>>
>>
>>
>>
>>
>> *To:* softimage@listproc.autodesk.com
>> *Subject:* Re: OT: Softs Duplicate Symmetry in Maya?
>>
>>
>>
>> There sure is no 100 percent accurate way to do it. You can use Skeleton
>> > Mirror Joint but that only mirrors joints + IK Handles, no constraints or
>> objects. It might be an opportunity for you to dig into some scripting work
>> to make that happen. Again, there is no full-proof way of doing that,
>> AFAIK. You can use scripting to do major bulk of work in modules, like
>> building a stretchy leg or reverse foot etc. and then combine all the units
>> together. I wouldn't call myself an expert when it comes to rigging in Maya
>> but that is how I think it is done in most of the production work.
>>
>>
>> This communication (including any attachments) is sent on behalf of
>> Playtech plc or one of its subsidiaries (Playtech Group). It contains
>> information which is confidential and privileged. If you are not the
>> intended recipient, please notify the sender immediately and destroy any
>> copies of this communication. Unless expressly stated to the contrary,
>> nothing in this communication constitutes a contractual offer capable of
>> acceptance or indicates intention to create legal relations or grant any
>> rights. The Playtech Group monitors communications sent or received by it
>> for security and other purposes. Any views or opinions presented are solely
>> those of the author and do not necessarily represent those of the Playtech
>> Group
>>
>> --
>> 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: OT: Softs Duplicate Symmetry in Maya?

2016-07-18 Thread Christopher McCabe

I don't know how complicated of a rig this will work for but... I created a
joint chain and constrained primitives to several of the joints with
parent, and point constraints. Put everything under a group located at
world 0.

Ran in MEL:
duplicate -rr -renameChildren -un; scale -r -1 1 1;

Then run this to rename:
searchReplaceNames "l_" "r_" "hierarchy";




On Mon, Jul 18, 2016 at 8:11 AM, Oz Adi  wrote:

> Thanks,
>
>
>
> Seems like a basic rigging tool that needs to be in every 3d package, to
> be able to mirror a complete rig..
> I’ve already built the other side from scratch, it wasn’t a big complex
> rig, but it was a waste of time :/
>
> I have not scripted for a few years now.. I’ll have to refresh my Jscript
> knowledge, and try to use it on learning some python I guess.
>
>
> so far switching to maya feels like a huge regression, I am sure it’ll get
> easier over time, but maya sure has some sickness to it, and sometimes
> feels like it came from the 80’s…
>
> (no offence to people born in the 80’s, myself is from the early 70’s J )
>
>
>
>
>
>
>
>
> *To:* softimage@listproc.autodesk.com
> *Subject:* Re: OT: Softs Duplicate Symmetry in Maya?
>
>
>
> There sure is no 100 percent accurate way to do it. You can use Skeleton >
> Mirror Joint but that only mirrors joints + IK Handles, no constraints or
> objects. It might be an opportunity for you to dig into some scripting work
> to make that happen. Again, there is no full-proof way of doing that,
> AFAIK. You can use scripting to do major bulk of work in modules, like
> building a stretchy leg or reverse foot etc. and then combine all the units
> together. I wouldn't call myself an expert when it comes to rigging in Maya
> but that is how I think it is done in most of the production work.
>
>
> This communication (including any attachments) is sent on behalf of
> Playtech plc or one of its subsidiaries (Playtech Group). It contains
> information which is confidential and privileged. If you are not the
> intended recipient, please notify the sender immediately and destroy any
> copies of this communication. Unless expressly stated to the contrary,
> nothing in this communication constitutes a contractual offer capable of
> acceptance or indicates intention to create legal relations or grant any
> rights. The Playtech Group monitors communications sent or received by it
> for security and other purposes. Any views or opinions presented are solely
> those of the author and do not necessarily represent those of the Playtech
> Group
>
> --
> 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: Modulo ? Modulo ?

2016-04-11 Thread Christopher Crouzet

The 6/4 result is to be expected and is not related to a rounding issue but
simply to the nature of randomness—setting a ratio of 0.5 doesn't guarantee
a 50-50% split, it only means that the distribution will tend towards this
goal, especially when the number of samples will be high enough (and 10
samples definitely isn't much at all).


On 11 April 2016 at 17:06, Olivier Jeannel  wrote:

> Thank's both of you :) Yes, I did use random probability, and it's exactly
> the translation of the Houdini expression explained by Christopher !
> I guess I was confused because (in Ice) when I input a ratio of 0.5, It
> returns 6 particles and 4 particles, instead of 5 and 5.
> I guess some rounding integer issue ...
> But thank's for the clarification :) I'm ashamed it was so obvious :/
>
>
> On Mon, Apr 11, 2016 at 11:34 AM, elhemp  wrote:
>
>> Test Random Probability Node?
>>
>> Cheers,
>> Stephan.
>>
>> Am 11.04.2016, 10:57 Uhr, schrieb Olivier Jeannel > >:
>>
>> > Hi guys,
>> >
>> > This is a case that keeps coming every once in a while. I'm scratching
>> > my head on it this morning.
>> > In Ice, lets say you have 10 particles, and you want to "select" 60% of
>> > them randomly.
>> > ("select" means 60% with an attribute of 1, and 40% with an attribute of
>> > 0)
>> >
>> >
>> > How would you do that ?
>> --
>> 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
*http://christophercrouzet.com* <http://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: Modulo ? Modulo ?

2016-04-11 Thread Christopher Crouzet

I haven't used ICE in 6+ years so I can't tell exactly how to do it in
there but assuming that you have access to a random function returning
uniform distributions in the range 0 to 1, it would be as simple as:

ratio = 0.6
do_select = rand(particle_id + some_sort_of_seed) < ratio

A random function with uniform distributions (the default implemetation in
CG softwares) means that the generated numbers are evenly distributed
across the 0 to 1 range, so you've got 60% of chance to end up with a
number comprised between 0 and 0.6, and 40% of chance to have it between
0.6 and 1.


On 11 April 2016 at 15:57, Olivier Jeannel  wrote:

> Hi guys,
>
> This is a case that keeps coming every once in a while. I'm scratching my
> head on it this morning.
> In Ice, lets say you have 10 particles, and you want to "select" 60% of
> them randomly.
> ("select" means 60% with an attribute of 1, and 40% with an attribute of 0)
>
>
> How would you do that ?
>
> --
> 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
*http://christophercrouzet.com* <http://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: OT Houdini build Array VOP question (and a bit of rant)

2016-03-03 Thread Christopher Crouzet

VOP graphs are being converted to VEX code, which means that for each VOP
node you'll find a corresponding VEX function, and most likely vice versa
too. If you want to see the generated code, just right click on the VOP
node, and select “View VEX Code...”. It can be informative to check it out
sometimes to help with debugging, but it's overly cluttered in comparison
to hand-written VEX code and thus can be hard to read.

Regarding the line `int pt1 = min(neighbours(input, pt0));`, it's picking
the neighbour with the smallest point number. The reason is simple—the
`Sort SOP` node reorder the points so for example the lowest point numbers
for a sort by X become the ones having the lowest X value. And hence, you
want the neighbour of `pt0` with the lowest point number to have `pt0` and
`pt1` representing the edge that matches the best to what's expected from
the sorting. If instead you'd simply do `int pt1 = neighbours(input,
pt0)[0];`, then you'd sometimes get what you'd hope, sometimes not.

Also yeah, there's never a single way to do things. If you compute a sort
of normal as you say for each point, that you can make in a predictable way
accross the entire mesh, then you'd probably avoid the problem that I
mentionned in my previous email. Maybe the `PolyFrame SOP` could be used
for that, but I don't know how it internally works and thus I don't know
how predictable it is. Worth a try! I only provided the scene this way to
give the idea that the essential of it can be done easily enough in
VOP/VEX. But it's always the remaining 10% that takes 90% of the time! :)

On 3 March 2016 at 21:28, Olivier Jeannel  wrote:

> You seem very dispointed by Houdini Anto, are you ?
>
> On Thu, Mar 3, 2016 at 2:16 PM, Anto Matkovic  wrote:
>
>> Thank you kindly Christopher,
>> Yes as far as I know, FE presents the whole points data as an array.
>> Beside that, at this moment I just feel FE as much better solution for me
>> (and for Olivier of course :) ), instead of H. Can't really say more for
>> now. Also really need to say, while I'm not programmer, unfortunately or
>> not I have to communicate with them every day, even in private life, so
>> maybe I become a bit resistant. I think we all know how is going with this
>> kind of people -  one has this or that opinion, another has completely
>> opposite, all long stories full of smart words. No need to waste your time
>> on me, let's say in short :)  Of course I've read everything you said here.
>> thanks again...
>>
>> --
>> *From:* Christopher Crouzet 
>> *To:* Softimage Mailing List 
>> *Sent:* Thursday, March 3, 2016 4:40 AM
>> *Subject:* Re: OT Houdini build Array VOP question (and a bit of rant)
>>
>> You can think of each geometry attribute as an array which length equals
>> the number of points (if dealing with points). VOPs simply iterate over
>> these points and process the graph for each of them. Since each attribute
>> is an array, at any time you can pick the value of any element with `Get
>> Attribute` provided you know the point number. This is so straightforward
>> that you can even do this outside of VOP/VEX, with the `point` expression
>> for example.
>>
>> Sometimes it can be useful to define attributes that can themselves hold
>> arrays, for example a list of neighbours, to then pass these down to other
>> nodes for further processing. That's why they added that feature in H14,
>> but otherwise there's no real need to directly create arrays yourself.
>> Shamefully, I haven't used Fabric Engine yet but from what you're saying
>> maybe they're just presenting the data differently by providing you with
>> the whole points data as an array instead of letting you directly work on a
>> per-point context? In any case, there's plently of good reasons to use
>> Fabric Engine but this definitely isn't one of them—just wrap your head
>> around how Houdini works instead, everything will eventually start to make
>> sense :)
>>
>> On 3 March 2016 at 05:43, Anto Matkovic  wrote:
>>
>> Nope. I think the only way to create an array directly in VOP, is pcfind
>> (pcopen that returns array), or array version of point neighbors. Or, to
>> stack the 'append' node several times :). There are examples how to loop
>> over arrays of indices, later in network, here:
>>
>> https://www.sidefx.com/index.php?option=com_content&task=view&id=3148&Itemid=412
>> By the way, had to do some pretty interesting networks :) for Kristinka
>> Hair for H - while everything worked at the end of day, anyway.
>>
>> If you'r

Re: OT Houdini build Array VOP question (and a bit of rant)

You can think of each geometry attribute as an array which length equals
the number of points (if dealing with points). VOPs simply iterate over
these points and process the graph for each of them. Since each attribute
is an array, at any time you can pick the value of any element with `Get
Attribute` provided you know the point number. This is so straightforward
that you can even do this outside of VOP/VEX, with the `point` expression
for example.

Sometimes it can be useful to define attributes that can themselves hold
arrays, for example a list of neighbours, to then pass these down to other
nodes for further processing. That's why they added that feature in H14,
but otherwise there's no real need to directly create arrays yourself.
Shamefully, I haven't used Fabric Engine yet but from what you're saying
maybe they're just presenting the data differently by providing you with
the whole points data as an array instead of letting you directly work on a
per-point context? In any case, there's plently of good reasons to use
Fabric Engine but this definitely isn't one of them—just wrap your head
around how Houdini works instead, everything will eventually start to make
sense :)

Olivier, assuming that two poins are neighbour based on their point number
is quite a risky bet. Instead, there is a `Neighbour VOP` node for that so
you can pick P1 as being the first neighbour of P0. But then, to reflect
the sorting order of your points, it'd be better to retrieve the array of
all the neighbours and retrieve only the neighbour with the smallest point
number.

I've made an example scene for you—everything is happening in the node
named `rotate_each_prim`, where you'll find an `angle` parameter to play
with. I tried to keep the code as simple as possible and documented every
line to help you understanding it.

An issue is that the `Sort SOP` node fails when for example sorting the
points of the grid along the X axis since many points in that grid share
the same position in X, leaving no hint for the `Sort SOP` node to
prioritize one point over the other. In fact, sorting points by an axis
might be troublesome even on more organic geometries, so basing this effect
on the `Sort SOP` alone won't be enough to have predictible results, and
you'll end up with primitives rotating in a different direction than their
neighbours.

On 3 March 2016 at 05:43, Anto Matkovic  wrote:

> Nope. I think the only way to create an array directly in VOP, is pcfind
> (pcopen that returns array), or array version of point neighbors. Or, to
> stack the 'append' node several times :). There are examples how to loop
> over arrays of indices, later in network, here:
>
> https://www.sidefx.com/index.php?option=com_content&task=view&id=3148&Itemid=412
> By the way, had to do some pretty interesting networks :) for Kristinka
> Hair for H - while everything worked at the end of day, anyway.
>
> If you're around arrays and nodes, Fabric is waiting for You
>
>
> --
> *From:* Olivier Jeannel 
> *To:* "softimage@listproc.autodesk.com" 
> *Sent:* Wednesday, March 2, 2016 1:29 PM
> *Subject:* OT Houdini build Array VOP question (and a bit of rant)
>
> Hello serious list :)
>
> I'm a bit confused with houdini vop array.
> While I managed to do it in vex, I would like to make a build array (like
> build array from set) of the pointposition (P) in VOP.
>
> I understand you need to for-loop on each Ptnum and probably append the P
> values and this will buid an array of P.
> But you know what ? Well I can't manage to make it work.
>
> I found no example on the net (sideFX, odforce).
> The doc is just words, no schemes, no graphics.
> The examples hips are bizarre, not so simple, and use the old loop node.
>
> So I'm wondering if someone from here could provide a screen shot of how
> that should be connected ?
>
> Thank you :)
>
>
> --
> 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
*http://christophercrouzet.com* <http://christophercrouzet.com>

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

Re: OT Houdini build Array VOP question (and a bit of rant)

Maybe I'm misunderstanding but if you already know which point you want an
attribute value of, then why would you want to store the values for every
point in an array? That'd be a lot of processing for nothing. No need to
iterate with a for loop neither. In VOP there's the `Get Attribute VOP`
node where you can specify a point/primitive/vertex number and retrieve an
attribute from it.

Cheers!


On 2 March 2016 at 22:12, Olivier Jeannel  wrote:

> Thank you so much for your time, explanations and examples Christopher.
> I'm taking those picture and will reproduce them :)
>
> Well, I wanted an array because I need to see if I could be able to
> retrieve the second element of an array (Ptnum =1 ) using  Get Element (I
> guess).
>
>
>
>
> On Wed, Mar 2, 2016 at 3:55 PM, Christopher Crouzet <
> christopher.crou...@gmail.com> wrote:
>
>> Basically, arrays are a convenient structure to pass data around (and to
>> potentially make your code more readable, which won't apply to VOP). If all
>> you need is to perform a computation in place and directly use the result
>> in your VOP graph, then iterating over your points is all it takes—no array
>> needed.
>>
>> I don't know what what you're planning to do with that array of point
>> positions but I've attached a screenshot with a simple example. It iterates
>> over all the points, retrieve their position, and outputs the centre of
>> mass. Note that it's better to run this specific example in “detail” mode
>> to perform the computation only once, instead of once per point.
>>
>>
>> On 2 March 2016 at 21:32, Olivier Jeannel  wrote:
>>
>>> Yes I saw it, sorry, I thought there was another additionnal method with
>>> For Loop :
>>> "Instead, you should be able to just loop over each point with a `For
>>> Loop VOP` and do your computation directly in there"
>>> Have I misunderstood ? You're doing a for-loop without building an array
>>> in the end.
>>>
>>> On Wed, Mar 2, 2016 at 3:26 PM, Christopher Crouzet <
>>> christopher.crou...@gmail.com> wrote:
>>>
>>>> I did attach a screenshot in my previous email, are you not seeing
>>>> anything? Or are you asking for the H13 for loop?
>>>>
>>>>
>>>> On 2 March 2016 at 21:20, Olivier Jeannel 
>>>> wrote:
>>>>
>>>>> Ah THANK YOU !
>>>>>
>>>>> I'm "aware" of the PCOpen+PcFilter to gather infos based on distance.
>>>>> I also use the PrimUV a bit and XYZ+PrimUV for location things.
>>>>>
>>>>> I'd be curious on the For Loop Vop, if you have any pictures :/ Sorry
>>>>> to ask.
>>>>>
>>>>> It's a shame there's no tutorial or phylosophycal explanations of
>>>>> these basic loops ... It's like if everybody was a natural born coder...
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Mar 2, 2016 at 3:13 PM, Christopher Crouzet <
>>>>> christopher.crou...@gmail.com> wrote:
>>>>>
>>>>>> It seems like they've extended the support for arrays in H14, which
>>>>>> makes it now possible to use them as geometry attributes. In the previous
>>>>>> versions I guess that there was no real point (but convenience) in 
>>>>>> creating
>>>>>> arrays in VOP since you couldn't pass them downstream with the geometry
>>>>>> data.
>>>>>>
>>>>>> So if you're on H14+, it seems like you were on the right path? I've
>>>>>> attached a working screenshot that stores every point position in a
>>>>>> “output” vector array attribute.
>>>>>>
>>>>>> If like me you're stuck with H13, you probably don't need to store
>>>>>> your point positions in an array at all. Instead, you should be able to
>>>>>> just loop over each point with a `For Loop VOP` and do your computation
>>>>>> directly in there. Now I've never used VOPs since I prefer writing 
>>>>>> directly
>>>>>> in VEX so I might be wrong :)
>>>>>>
>>>>>> Also don't forget to use point clouds if you're after
>>>>>> distance-related queries.
>>>>>>
>>>>>>
>>>>>> On 2 March 2016 at 19:29, Olivier Jeannel 
>>>>>>

Re: OT Houdini build Array VOP question (and a bit of rant)

Basically, arrays are a convenient structure to pass data around (and to
potentially make your code more readable, which won't apply to VOP). If all
you need is to perform a computation in place and directly use the result
in your VOP graph, then iterating over your points is all it takes—no array
needed.

I don't know what what you're planning to do with that array of point
positions but I've attached a screenshot with a simple example. It iterates
over all the points, retrieve their position, and outputs the centre of
mass. Note that it's better to run this specific example in “detail” mode
to perform the computation only once, instead of once per point.


On 2 March 2016 at 21:32, Olivier Jeannel  wrote:

> Yes I saw it, sorry, I thought there was another additionnal method with
> For Loop :
> "Instead, you should be able to just loop over each point with a `For
> Loop VOP` and do your computation directly in there"
> Have I misunderstood ? You're doing a for-loop without building an array
> in the end.
>
> On Wed, Mar 2, 2016 at 3:26 PM, Christopher Crouzet <
> christopher.crou...@gmail.com> wrote:
>
>> I did attach a screenshot in my previous email, are you not seeing
>> anything? Or are you asking for the H13 for loop?
>>
>>
>> On 2 March 2016 at 21:20, Olivier Jeannel  wrote:
>>
>>> Ah THANK YOU !
>>>
>>> I'm "aware" of the PCOpen+PcFilter to gather infos based on distance.
>>> I also use the PrimUV a bit and XYZ+PrimUV for location things.
>>>
>>> I'd be curious on the For Loop Vop, if you have any pictures :/ Sorry to
>>> ask.
>>>
>>> It's a shame there's no tutorial or phylosophycal explanations of these
>>> basic loops ... It's like if everybody was a natural born coder...
>>>
>>>
>>>
>>> On Wed, Mar 2, 2016 at 3:13 PM, Christopher Crouzet <
>>> christopher.crou...@gmail.com> wrote:
>>>
>>>> It seems like they've extended the support for arrays in H14, which
>>>> makes it now possible to use them as geometry attributes. In the previous
>>>> versions I guess that there was no real point (but convenience) in creating
>>>> arrays in VOP since you couldn't pass them downstream with the geometry
>>>> data.
>>>>
>>>> So if you're on H14+, it seems like you were on the right path? I've
>>>> attached a working screenshot that stores every point position in a
>>>> “output” vector array attribute.
>>>>
>>>> If like me you're stuck with H13, you probably don't need to store your
>>>> point positions in an array at all. Instead, you should be able to just
>>>> loop over each point with a `For Loop VOP` and do your computation directly
>>>> in there. Now I've never used VOPs since I prefer writing directly in VEX
>>>> so I might be wrong :)
>>>>
>>>> Also don't forget to use point clouds if you're after distance-related
>>>> queries.
>>>>
>>>>
>>>> On 2 March 2016 at 19:29, Olivier Jeannel 
>>>> wrote:
>>>>
>>>>> Hello serious list :)
>>>>>
>>>>> I'm a bit confused with houdini vop array.
>>>>> While I managed to do it in vex, I would like to make a build array
>>>>> (like build array from set) of the pointposition (P) in VOP.
>>>>>
>>>>> I understand you need to for-loop on each Ptnum and probably append
>>>>> the P values and this will buid an array of P.
>>>>> But you know what ? Well I can't manage to make it work.
>>>>>
>>>>> I found no example on the net (sideFX, odforce).
>>>>> The doc is just words, no schemes, no graphics.
>>>>> The examples hips are bizarre, not so simple, and use the old loop
>>>>> node.
>>>>>
>>>>> So I'm wondering if someone from here could provide a screen shot of
>>>>> how that should be connected ?
>>>>>
>>>>> Thank you :)
>>>>>
>>>>>
>>>>> --
>>>>> 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
>>>> *http://chris

Re: OT Houdini build Array VOP question (and a bit of rant)

I did attach a screenshot in my previous email, are you not seeing
anything? Or are you asking for the H13 for loop?


On 2 March 2016 at 21:20, Olivier Jeannel  wrote:

> Ah THANK YOU !
>
> I'm "aware" of the PCOpen+PcFilter to gather infos based on distance.
> I also use the PrimUV a bit and XYZ+PrimUV for location things.
>
> I'd be curious on the For Loop Vop, if you have any pictures :/ Sorry to
> ask.
>
> It's a shame there's no tutorial or phylosophycal explanations of these
> basic loops ... It's like if everybody was a natural born coder...
>
>
>
> On Wed, Mar 2, 2016 at 3:13 PM, Christopher Crouzet <
> christopher.crou...@gmail.com> wrote:
>
>> It seems like they've extended the support for arrays in H14, which makes
>> it now possible to use them as geometry attributes. In the previous
>> versions I guess that there was no real point (but convenience) in creating
>> arrays in VOP since you couldn't pass them downstream with the geometry
>> data.
>>
>> So if you're on H14+, it seems like you were on the right path? I've
>> attached a working screenshot that stores every point position in a
>> “output” vector array attribute.
>>
>> If like me you're stuck with H13, you probably don't need to store your
>> point positions in an array at all. Instead, you should be able to just
>> loop over each point with a `For Loop VOP` and do your computation directly
>> in there. Now I've never used VOPs since I prefer writing directly in VEX
>> so I might be wrong :)
>>
>> Also don't forget to use point clouds if you're after distance-related
>> queries.
>>
>>
>> On 2 March 2016 at 19:29, Olivier Jeannel  wrote:
>>
>>> Hello serious list :)
>>>
>>> I'm a bit confused with houdini vop array.
>>> While I managed to do it in vex, I would like to make a build array
>>> (like build array from set) of the pointposition (P) in VOP.
>>>
>>> I understand you need to for-loop on each Ptnum and probably append the
>>> P values and this will buid an array of P.
>>> But you know what ? Well I can't manage to make it work.
>>>
>>> I found no example on the net (sideFX, odforce).
>>> The doc is just words, no schemes, no graphics.
>>> The examples hips are bizarre, not so simple, and use the old loop node.
>>>
>>> So I'm wondering if someone from here could provide a screen shot of how
>>> that should be connected ?
>>>
>>> Thank you :)
>>>
>>>
>>> --
>>> 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
>> *http://christophercrouzet.com* <http://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
*http://christophercrouzet.com* <http://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: OT Houdini build Array VOP question (and a bit of rant)

It seems like they've extended the support for arrays in H14, which makes
it now possible to use them as geometry attributes. In the previous
versions I guess that there was no real point (but convenience) in creating
arrays in VOP since you couldn't pass them downstream with the geometry
data.

So if you're on H14+, it seems like you were on the right path? I've
attached a working screenshot that stores every point position in a
“output” vector array attribute.

If like me you're stuck with H13, you probably don't need to store your
point positions in an array at all. Instead, you should be able to just
loop over each point with a `For Loop VOP` and do your computation directly
in there. Now I've never used VOPs since I prefer writing directly in VEX
so I might be wrong :)

Also don't forget to use point clouds if you're after distance-related
queries.

On 2 March 2016 at 19:29, Olivier Jeannel  wrote:

> Hello serious list :)
>
> I'm a bit confused with houdini vop array.
> While I managed to do it in vex, I would like to make a build array (like
> build array from set) of the pointposition (P) in VOP.
>
> I understand you need to for-loop on each Ptnum and probably append the P
> values and this will buid an array of P.
> But you know what ? Well I can't manage to make it work.
>
> I found no example on the net (sideFX, odforce).
> The doc is just words, no schemes, no graphics.
> The examples hips are bizarre, not so simple, and use the old loop node.
>
> So I'm wondering if someone from here could provide a screen shot of how
> that should be connected ?
>
> Thank you :)
>
>
> --
> 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
*http://christophercrouzet.com* <http://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: -Camera. Frames issues

2016-02-26 Thread Christopher McCabe

Are you saying it looks good when you scrub the timeline, and only the
renders have the "skipping" issue? Are you animating the Focal Length of
the camera?



On Fri, Feb 26, 2016 at 4:46 PM, Eugene Flormata 
wrote:

> motion blur?
>
> On Fri, Feb 26, 2016 at 10:46 AM, Adam Sale  wrote:
>
>> Obvious thought, but what do your fcurves look like?
>>
>> On Fri, Feb 26, 2016 at 9:35 AM, Tenshi .  wrote:
>>
>>> Hi,
>>>
>>> hope you guys can help me on this.
>>>
>>> I have a little scene, the camera goes from 0 to 96(left to right) at
>>> 24fps, it's a logo close up, When i see it in the flipbook or in after
>>> effects there are some issues with the camera, i can't explain it, it's
>>> like it's missing frames but it's not that. Like the camera it's skipping
>>> some frames in the middle, i tried to convert the scene to 30fps, the
>>> camera movement looks better(more fluid) but even with that it seems it's
>>> skipping some frames.
>>>
>>> There's a way to fix this? maybe some camera settings? btw I'm using the
>>> default perspective camera. Using sitoa for Render.
>>>
>>>
>>> thanks in adv.
>>>
>> 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: Covert instance with UV and material to polygon mesh - how?

2015-12-07 Thread Christopher McCabe

EM Topolizer 2 is the best.
http://www.mootzoid.com/plugin/emtopolizer2

Or you can try Save Render Mesh
http://www.andynicholas.com/?p=57
You have to use MR with Save Render Mesh to get the geometry out of
Softimage.

On Fri, Dec 4, 2015 at 10:07 PM, Andres Stephens 
wrote:

> I've been using ICE scatter tools and motion tools, and  I've found some
> fun  vertex geometry caching to Direct X 11 gpu renderer from Softimage
> that is fun to use . I would like to render my instanced things, but I
> first need to convert them to polygon meshes, and assign them UVs and
> materials.
>
> I have used Create Polygon Mesh from Instance compound found in the SI
> community forums. I got it working like a charm after some effort. But now
> I have found the new meshes have no UVs. It has material IDs assigned via
> ICE, but no real UVs or material clusters...  Which I need.
>
> Is there a better way to convert instances that have UVs and materials
> into meshes with UVs and materials?
>
> Or is there a way to convert a material ID into a polygon cluster and/or
> something like a material with the instanced object UV transferred over?
>
> Or is there a way to scatter and manipulate geometry using geometry
> latched to particles but no instances, with the geometry (and their UVs and
> material) directly?
>
> Some pointers would be greatly appreciated...
>
> Thanks!
>
> -Draise
>
>
> Sent from my Samsung device
>

Re: Continued use of Softimage question

2015-08-20 Thread Christopher Crouzet

Yes, you can!

http://www.sidefx.com/docs/houdini14.0/nodes/shop/vm_geo_file


On 20 August 2015 at 21:46, Francois Lord  wrote:

> What about disk space?
> Can you, in Mantra, reference alembic deforming geometry directly so it
> doesn't have to be part of the ifd file at each frame?
>
>
> On 2015-08-20 10:40, Sandy Sutherland wrote:
>
> At Sunrise we had 5 IFD generating machines (Engine lics), and I wrote a
> tool to submit renders from Houdini to RR that had the main render job wait
> for the IFD job to finish, before starting - easy to do.  The IFD
> generating was pretty quick, so we did not really have machines waiting to
> render.
>
> On Thu, Aug 20, 2015 at 3:30 PM, Ciaran Moloney 
> wrote:
>
>> Pretty sure that applies also to Mantra renders. But, most places have a
>> smaller pool of engine licenses and export all frames to .ass or .ifd for
>> rendering. Since export times are usually shorter than render times, it
>> works out quite efficiently. But yeah, definitely another expense to
>> consider.
>>
>>
>> On Thu, Aug 20, 2015 at 11:53 AM, Mike Donovan < 
>> m...@smoke-mirrors.com> wrote:
>>
>>>  One thing that is a bummer with HTOA is that you will need to purchase
>>> a Houdini Engine license for every node on your farm unless all the
>>> geometry creation is done before rendering.
>>>
>>>
>>>
>>> This cost be quite steep … essentially a $500 additional cost to each
>>> Arnold license.
>>>
>>>
>>>
>>
>>
>
>


-- 
Christopher Crouzet
*http://christophercrouzet.com* <http://christophercrouzet.com>

Re: OT: Houdini: a few image plane questions

2015-06-16 Thread Christopher Crouzet

Hey Gerbrand,

You can save each extra image plane into their own file by setting the
`Different File` parameter. Note that this parameter is hidden when the
`Output Picture` parameter is set to the default value of `ip`, so just
change it to point to an actual file on disk. If you then want to save the
image planes directly into the RGB channels, then you can set the `Channel
Name` parameter to `C` but this won't always be an answer to your problems
if you decide for example to export the image planes for each component
and/or each light. So you'd better find a solution for After Effects. In
Nuke, the `Shuffle` node doest just that.

For the mattes, you have many ways but one that I dig is to use the `Forced
Matte` parameter, under the `Objects` tab of the Mantra node. This way, if
you'd like to split the render for different sets of objects, then you
could for example create a bundle named `@objects` that would contain all
the objects to render and, in the Mantra node dedicated to render your
specific object `OBJECT_SPHERE`, you could set `@objects ^OBJECT_SPHERE` in
the `Forced Matte` parameter to define every rendered object of your scene
as matte but the current object that you want to render. I find it to be
quite a flexible approach knowing that you can create smart bundles based
on name patterns such as `/obj/OBJECT_%`. In other words, this means that
you possibly have nothing to worry about if you decide later on to add more
objects into your scene—your matte for the sphere object will still work.

On 16 June 2015 at 21:36, Gerbrand Nel  wrote:

> Hey guys.
> I'm getting to the rendering part of this job, and have found image planes
> in mantra.
> They seem really cool, but I've hit a few snags.
>
> First of all, They seem to render into either one big EXR file, or into
> multiple exr files, but each image plane goes into its own exr channel.
> This makes them pretty useless in afterfx.
> Is there a way to get them to render like frame buffers in softimage,
> where each channel goes into its own exr, but not into some obscure channel
> within that exr.
> Alternatively, do you guys know of a fast way to export these channels
> into the rgba channels of a new exr?
>
> Second question.
> In softimage I used frame buffers to render mattes for objects in my scene.
> Can this be done with image planes?
> I tried creating a color parameter in my shader, and then calling that as
> a new image plane, but I just got a black frame and errors.
> Thanks for reading guys
> G
>
>

-- 
Christopher Crouzet
*http://christophercrouzet.com* <http://christophercrouzet.com>

Re: Mr Otter animated series, all episodes on youtube (but only in french...)

2015-06-16 Thread Christopher Crouzet

Damn you Ahmidou, you killed my productivity for the day! :)


On 16 June 2015 at 16:31, christian  wrote:

> amazing style. love the outlines and how some of the textile patterns are
> 2D mapped..
>
> On Tue, Jun 16, 2015 at 11:24 AM,  wrote:
>
>>   the aquarelle look works very well – nice stuff.
>>
>>  *From:* Sebastien Sterling 
>> *Sent:* Tuesday, June 16, 2015 2:55 AM
>> *To:* softimage@listproc.autodesk.com
>> *Subject:* Re: Mr Otter animated series,all episodes on youtube (but
>> only in french...)
>>
>>  C'est beau ;)
>>
>> On 16 June 2015 at 01:17, Jeremie Passerin  wrote:
>>
>>> Yay ! I'll show it to my daughter !
>>>
>>> On 15 June 2015 at 17:06, Ahmidou Lyazidi  wrote:
>>>
>>>>   Hi everyone,
>>>> I just noticed that the series I directed back in 2009 has been
>>>> officially put on-line.
>>>> It's was all Softimage with a pretty small budget and ICE was used a
>>>> lot.
>>>> The channel completely missed the audience by broadcasting it
>>>> when the children were already at school, so I'm quite happy it can
>>>> have a second life.
>>>>
>>>> https://www.youtube.com/channel/UC-jD2oPDTvRrjpOWYNamRkQ/videos
>>>>
>>>> Cheers.
>>>>
>>>>
>>>> ---
>>>> Ahmidou Lyazidi
>>>> Director | TD | CG artist
>>>> http://vimeo.com/ahmidou/videos
>>>> https://vimeo.com/cappuccinofilms <http://www.cappuccino-films.com>
>>>>
>>>
>>>
>>
>>
>
>


-- 
Christopher Crouzet
*http://christophercrouzet.com* <http://christophercrouzet.com>

Re: GATOR - A feature in Softimage since 2008

2015-05-28 Thread Christopher Crouzet

I've just noticed that the exact same thread happened on the Fabric
mailing-list—someone asked for GATOR and I quoted that foot roll thingy in
my reply. I'm so predictable :)


On 28 May 2015 at 20:11, Christopher Crouzet 
wrote:

> Beware also to not implement any foot roll in your rigs.
>
> http://www.google.com/patents/US7545378
>
>
> On 28 May 2015 at 19:50, Paul Doyle  wrote:
>
>> Most likely covered by this one:
>> "Transfer of attributes between geometric surfaces of arbitrary
>> topologies with distortion reduction and discontinuity preservation
>> United States 7760201Issued July 20, 2010
>>
>> This describes how to transfer surface attributes (such as color, UVs,
>> skinning) between two 3D geometries of different topologies and potentially
>> different type (polygon mesh, NURBS, curve...). In particular, it describes
>> methods to preserve surface discontinuitues (such as UV island seams) and
>> reduce attribute distortion on the target surface."
>>
>> On 28 May 2015 at 08:42, Paul Doyle  wrote:
>>
>>> Jerome (now at Fabric - go team!) wrote GATOR. I'd ask him about doing
>>> it in Fabric but I think he'd stab me if I gave him any more work to do. I
>>> don't know if there are patents around the work and that's why other people
>>> haven't replicated it.
>>>
>>> On 28 May 2015 at 08:21, Marc-Andre Carbonneau <
>>> marc-andre.carbonn...@ubisoft.com> wrote:
>>>
>>>> Good morning Lucer,
>>>>
>>>> Do you remember who designed and coded GATOR?
>>>> I'm just curious.
>>>> Thanks!
>>>> MAC
>>>>
>>>>
>>>> -Original Message-
>>>> From: softimage-boun...@listproc.autodesk.com [mailto:
>>>> softimage-boun...@listproc.autodesk.com] On Behalf Of Luc-Eric Rousseau
>>>> Sent: May-27-15 9:11 PM
>>>> To: softimage@listproc.autodesk.com
>>>> Subject: Re: GATOR - A feature in Softimage since 2008
>>>>
>>>> GATOR was developed for/with one of our main game customers, Square I
>>>> think.
>>>> I'm not aware of a Gator "sdk", what is that?
>>>> There are attribute transfers in other apps, but it's generally
>>>> separate tools for textures vs rigging things, reflecting on their
>>>> architecture vs XSI
>>>>
>>>> On 27 May 2015 at 19:27, Matt Lind  wrote:
>>>> > For the record, GATOR was introduced in late 2005 with XSI v5.0, not
>>>> > in 2008.
>>>> >
>>>> > GATOR was largely tailored for those switching applications and doing
>>>> > rigging in a film/video pipeline.  For games development, GATOR has
>>>> > less use out-of-the-box as the very things that made it nice for
>>>> > exchanging data between XSI and Maya, for example, were the very same
>>>> > features that tripped up game artists trying to do simpler things
>>>> quickly in heavy repetition.
>>>> >
>>>> > I wrote a command based version of the tool using the GATOR SDK as
>>>> > artists needed more micro-management of meshes and transfers.  Artists
>>>> > used it to transfer UV's, normals, vertex colors, envelope weights,
>>>> > and many other features.  I also extended, as well as exposed, many
>>>> > features from the SDK GATOR did not expose directly such as
>>>> > transferring attributes in local space, by raycasting, distance
>>>> > limits, transferring only selected subcomponents, correcting
>>>> numerical flaws found in UV transfer, and so on.
>>>> > However, my use of the GATOR SDK was not limited to replicating the
>>>> > tool as a command.  I also used it heavily for other tasks which
>>>> > weren't strictly related to attribute transfer tasks such as animation
>>>> > remapping, pose transfer, mesh fitting, and interactive editing of
>>>> > normals and symmetrical envelope weighting of asymmetrical characters.
>>>> >
>>>> > To hear other applications don't have a GATOR equivalent in this day
>>>> > and age is surprising considering it's so universally useful and isn't
>>>> > rocket science to develop.  If you know anything about tree data
>>>> > structures and linear algebra, you can write your own (even if it's
>>>> > not as efficient as GATOR).  What makes the GATOR SDK nice is the
>>>> > algorithm is very fast, accurate, and relatively easy to use.  Reverse
>>>> > lookups of subcomponents is a pain as GATOR worked on triangles, not
>>>> > polygons, but that's minor compared to all the benefits it provides.
>>>>
>>>>
>>>
>>
>
>
> --
> Christopher Crouzet
> *http://christophercrouzet.com* <http://christophercrouzet.com>
>
>


-- 
Christopher Crouzet
*http://christophercrouzet.com* <http://christophercrouzet.com>

Re: GATOR - A feature in Softimage since 2008

2015-05-28 Thread Christopher Crouzet

Beware also to not implement any foot roll in your rigs.

http://www.google.com/patents/US7545378


On 28 May 2015 at 19:50, Paul Doyle  wrote:

> Most likely covered by this one:
> "Transfer of attributes between geometric surfaces of arbitrary
> topologies with distortion reduction and discontinuity preservation
> United States 7760201Issued July 20, 2010
>
> This describes how to transfer surface attributes (such as color, UVs,
> skinning) between two 3D geometries of different topologies and potentially
> different type (polygon mesh, NURBS, curve...). In particular, it describes
> methods to preserve surface discontinuitues (such as UV island seams) and
> reduce attribute distortion on the target surface."
>
> On 28 May 2015 at 08:42, Paul Doyle  wrote:
>
>> Jerome (now at Fabric - go team!) wrote GATOR. I'd ask him about doing it
>> in Fabric but I think he'd stab me if I gave him any more work to do. I
>> don't know if there are patents around the work and that's why other people
>> haven't replicated it.
>>
>> On 28 May 2015 at 08:21, Marc-Andre Carbonneau <
>> marc-andre.carbonn...@ubisoft.com> wrote:
>>
>>> Good morning Lucer,
>>>
>>> Do you remember who designed and coded GATOR?
>>> I'm just curious.
>>> Thanks!
>>> MAC
>>>
>>>
>>> -Original Message-
>>> From: softimage-boun...@listproc.autodesk.com [mailto:
>>> softimage-boun...@listproc.autodesk.com] On Behalf Of Luc-Eric Rousseau
>>> Sent: May-27-15 9:11 PM
>>> To: softimage@listproc.autodesk.com
>>> Subject: Re: GATOR - A feature in Softimage since 2008
>>>
>>> GATOR was developed for/with one of our main game customers, Square I
>>> think.
>>> I'm not aware of a Gator "sdk", what is that?
>>> There are attribute transfers in other apps, but it's generally separate
>>> tools for textures vs rigging things, reflecting on their architecture vs
>>> XSI
>>>
>>> On 27 May 2015 at 19:27, Matt Lind  wrote:
>>> > For the record, GATOR was introduced in late 2005 with XSI v5.0, not
>>> > in 2008.
>>> >
>>> > GATOR was largely tailored for those switching applications and doing
>>> > rigging in a film/video pipeline.  For games development, GATOR has
>>> > less use out-of-the-box as the very things that made it nice for
>>> > exchanging data between XSI and Maya, for example, were the very same
>>> > features that tripped up game artists trying to do simpler things
>>> quickly in heavy repetition.
>>> >
>>> > I wrote a command based version of the tool using the GATOR SDK as
>>> > artists needed more micro-management of meshes and transfers.  Artists
>>> > used it to transfer UV's, normals, vertex colors, envelope weights,
>>> > and many other features.  I also extended, as well as exposed, many
>>> > features from the SDK GATOR did not expose directly such as
>>> > transferring attributes in local space, by raycasting, distance
>>> > limits, transferring only selected subcomponents, correcting numerical
>>> flaws found in UV transfer, and so on.
>>> > However, my use of the GATOR SDK was not limited to replicating the
>>> > tool as a command.  I also used it heavily for other tasks which
>>> > weren't strictly related to attribute transfer tasks such as animation
>>> > remapping, pose transfer, mesh fitting, and interactive editing of
>>> > normals and symmetrical envelope weighting of asymmetrical characters.
>>> >
>>> > To hear other applications don't have a GATOR equivalent in this day
>>> > and age is surprising considering it's so universally useful and isn't
>>> > rocket science to develop.  If you know anything about tree data
>>> > structures and linear algebra, you can write your own (even if it's
>>> > not as efficient as GATOR).  What makes the GATOR SDK nice is the
>>> > algorithm is very fast, accurate, and relatively easy to use.  Reverse
>>> > lookups of subcomponents is a pain as GATOR worked on triangles, not
>>> > polygons, but that's minor compared to all the benefits it provides.
>>>
>>>
>>
>


-- 
Christopher Crouzet
*http://christophercrouzet.com* <http://christophercrouzet.com>

Re: OT: Geometry approximation in houdini

2015-05-22 Thread Christopher Crouzet

Dunno for the render times but you have the choice of yet another SOP node
for the sharpness: `EdgeCusp`.


On 22 May 2015 at 15:39, Gerbrand Nel  wrote:

> Thanks Andy
> While I have your attention :)
> Are reflections and refractions stoopid slow in mantra, or is there a
> trick?
> The default glass shader renders forever in my scene.
> Thanks
> G
>
> On 22/05/2015 05:48, Andy Nicholas wrote:
>
>> You can use the Normal SOP with it set to Vertex. You can set the angle
>> there.
>>
>> The Facet SOP does something similar, but it will actually disconnect the
>> points instead, rather than setting vertex normal attributes.
>>
>> A
>>
>>
>>  On 21 May 2015, at 20:04, Gerbrand Nel  wrote:
>>>
>>> Hey guys
>>> In soft we have a discontinuity angle slider under geometry
>>> approximation.
>>> Where do I find this in houdini?
>>> I have a low poly object that I need to render like a crystal, so i need
>>> the facets to be super hard, no smoothing over edges
>>> Thanks
>>> G
>>>
>>
>>
>>
>


-- 
Christopher Crouzet
*http://christophercrouzet.com* <http://christophercrouzet.com>

Re: OT: Houdini cluster materials

2015-03-12 Thread Christopher Crouzet

I've got no idea what the `Merge` node internally does memory-wise but I
don't really care as an user because it is not made to be an optimization
method as you think. In proper data-flow graphs like the one exposed in
Houdini, certain nodes can generate new data streams while others can
manipulate the data from the stream they're being connected to. A `Merge`
node simply takes two—or more—data streams and put them into a single one.
This is a core concept when you have to deal with such graphs—it is so
essential that the `Merge` node is probably one of the most used nodes in
Houdini.

Groups in Houdini share roughly the same purpose than clusters from
Softimage. They are a core concept in Houdini as every node understand
them. What you can do with clusters, you can do with groups, and much more
out of the box.

On 10 March 2015 at 22:27, Jason S  wrote:

>  Does it internally reinterpret duplicates (or hold in memory and scene
> description) the entire object as many times as there are local
> "sub-object" attibutes? (like Maya?)
>
> Which defeats the purpose of using merged objects as optimization method
> (despite Maya having a --not that much of an-- easier time dealing with
> large object counts)
>
> Because apart how soft can handle many-many polys at a time, (especially
> so today comparatively)
> you can very easily treat sub-objects (clusters) as just regular objects
> assinging properties like materials, visibility, ... selecting,
> transforming and sorting them in groups,
> therefore quite a bit further amplifying that maximum reach in scene
> complexity while remaining humanly manage-ably workable.
> (benefit also very much applicable for non-insanely-complex scenes)
>
>
>
> On 03/10/15 5:50, Gerbrand Nel wrote:
>
> Thanks man.. it really is that simple!!
>
> On 10/03/2015 06:16, Christopher Crouzet wrote:
>
> There's a `Material` node in the SOP context to apply different materials
> on a same object. You can insert it before you merge your objects or apply
> it to different groups.
>
>
> On 10 March 2015 at 11:09, Gerbrand Nel  wrote:
>
>> Hey guys
>> Quick houdini question.
>> In soft I can make cluster for materials.
>> In houdini I always end up with some merged thing with multiple objects
>> in there.
>> As far as I can tell, we assign materials at the object level, but what
>> do I do if I want different materials for the different things that makes
>> up my object?
>> I know this is a RTFM question, but the FM is thick, and I'm lazy
>> Thanks
>> G
>>
>
>
>
>  --
>  Christopher Crouzet
> *http://christophercrouzet.com* <http://christophercrouzet.com>
>
>
>
>

-- 
Christopher Crouzet
*http://christophercrouzet.com* <http://christophercrouzet.com>

Re: OT: Houdini cluster materials

2015-03-09 Thread Christopher Crouzet

There's a `Material` node in the SOP context to apply different materials
on a same object. You can insert it before you merge your objects or apply
it to different groups.


On 10 March 2015 at 11:09, Gerbrand Nel  wrote:

> Hey guys
> Quick houdini question.
> In soft I can make cluster for materials.
> In houdini I always end up with some merged thing with multiple objects in
> there.
> As far as I can tell, we assign materials at the object level, but what do
> I do if I want different materials for the different things that makes up
> my object?
> I know this is a RTFM question, but the FM is thick, and I'm lazy
> Thanks
> G
>



-- 
Christopher Crouzet
*http://christophercrouzet.com* <http://christophercrouzet.com>

Re: OT houdini questions

2015-02-02 Thread Christopher Crouzet

Disclaimer: I'm a total beginner and there's most likely better/easier ways
to do it.

If you want to constrain your object to a single point, one way would be to
create an expression on each of the translate channels of your object and
use the `point` function, such as: `point("/obj/path_to_geometry",
point_number, "P", index)` where `index` is 0 for the position X, 1 for the
position Y and 2 for the position Z.

If you want your object to snap to an actual group of points, then the idea
that I've got is slightly more involved.
Basically, you'd need to put your points into a group and create an
`AttribWrangle` in which you'd loop over the points in the group and return
an average position.
Here's a working VEX snippet:

vector @clusterPosition = {0, 0, 0};

int count = 0;
int ptnum;
vector P;
int handle = pcopen(@OpInput1, "P", {0, 0, 0}, 1e6, int(1e6));
while (pciterate(handle)) {
pcimport(handle, "P", P);
pcimport(handle, "point.number", ptnum);
if (inpointgroup(@OpInput1, "group_name", ptnum)) {
@clusterPosition += P;
count++;
}
}

if (count > 0) {
@clusterPosition /= count;
}


Note that the `pcopen` function creates a point cloud with a K-D tree, so
it's really overkilled here. I'll be looking forward a better answer to
that one! :)

Also both solution will match only the position. To also match the
orientation, you might want to use the attributes created by `PolyFrame`.


On 2 February 2015 at 22:01, philipp seis  wrote:

> hey guys, i'd be super happy for any advice on an "object to cluster
> Constraint" in H,
> like i would use it for a dorrito
>
> 2015-02-02 15:38 GMT+01:00 Jordi Bares Dominguez :
>
>> And the Rivet SOP too
>>
>> > On 2 Feb 2015, at 12:55, a...@andynicholas.com wrote:
>> >
>> > You might want to check out the Creep SOP in that case.
>> >
>> >
>> > A
>> >
>> >
>> > On 02 February 2015 at 12:27 Gerbrand Nel  wrote:
>> >
>> >
>> >> Thanks guys!!
>> >> What I want out of a surface deformer is the UV control.
>> >> It's different than a cage or lattice because it lets you slide/deform
>> things
>> >> based on uv data, and offset along normals
>> >> I find it very useful to model things where allot of detail has to
>> follow a
>> >> certain shape.
>> >> I modelled some running shoes in the beginning of the year, and all of
>> the
>> >> parts followed this one master nurbs surface.
>> >> I'll look into the ray sop and lattice, but I think a surface deformer
>> >> digital asset might need to be made :)
>> >> One that works like soft.
>> >> This way I can "engine" it into bloody maya if I ever need to go to
>> that dark
>> >> place again.
>> >> G
>> >>
>> >> On 02/02/2015 12:45, philipp seis wrote:
>> >>
>> >>>> Hi Gerbrand,
>> >>>
>> >>> from the top of my head i'd say, there should be a checkbox so
>> that
>> >>> your curve
>> >>> won't get a surface.
>> >>> Then, here is a curve basics tutorial from peter quint:
>> >>> http://vimeo.com/40771484 <http://vimeo.com/40771484>
>> >>>
>> >>> I'd be interested in a deform by surface too. The Ray SOP gives a
>> >>> little bit of that
>> >>> behaviour out of the box, and the attribute transfer SOP as well,
>> if
>> >>> "match Point Position" ( i guess that was the name) Checkbox is on.
>> Those 2
>> >>> work on proximity.
>> >>> And finally you might want to try the Lattice SOP, which in
>> Houdini is
>> >>> also customizable,
>> >>> ending up being very close to the cage deformer from Soft.
>> >>> And then, you could also add a "Normal attribute" to your SOP,
>> with the
>> >>> point SOP, and create a VOPSOP in which you manipulate those. This
>> might be
>> >>> the equivalent to an ICE "closest point to location" node.
>> >>> I'd consider myself a real houdini novice though, just trying to
>> >>> transfer my Softimage workflows, so please correct me if i'm wrong.
>> >>>
>> >>> I would like to add the question: How would you do a simple
>> "Object to
>> >>> Cluster Constraint ?"
>> >>> So far i found only options that are uv based, like the "rivet"...
>> >>>
>> >>> best, Philipp
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> 2015-02-02 10:43 GMT+01:00 Gerbrand Nel > >>> <mailto:nagv...@gmail.com> >:
>> >>>>>> So 3 quick houdini questions if you don't mind:
>> >>>>  Why do I automatically get a surface on a closed curve?
>> >>>>  Can I kill it without killing the curve, or can I set it to
>> "never
>> >>>> create"?
>> >>>>  Is there something like "deform by surface" in soft for houdini?
>> >>>>  That is it for now :)
>> >>>>  Thanks
>> >>>>  G
>> >>>>>>
>> >>>
>> >>>>
>>
>>
>>
>


-- 
Christopher Crouzet
*http://christophercrouzet.com* <http://christophercrouzet.com>

Re: Lets Hope Autodesk Buys the Foundry!

2014-12-19 Thread Christopher Crouzet

The Intel TBB library indeed provides a flow graph since v4.0—that's
interesting, thanks!


On 20 December 2014 at 00:58, Luc-Eric Rousseau  wrote:
>
> I always talk about stuff from my programmer-colored glasses.  I say
> there isn't a lot of value in the fxtree code, or older
> compositing/paint code in general, because today anyone can download
> an image library, openimageio, and write you own fxtree-like
> compositor within a few days.  I think the Intel libraries might have
> you covered with all the threading and graph evaluation.  Want to
> write a paint app. you can look at the gimp source code, use the Cairo
> library for vector graphics, etc.  I tool the image lib from illusion,
> then wrote my own operator evaluation code, if I can do it it's not
> complicated. But I think there are open source libs for that too.
>
> Now doing correct floating point compositing, multi-channel workflows,
> tile based/memory management handling, that's a whole other ballgame.
> Then you go in 3d space, it's yet another ballgame. Nuke is another
> ballgame.
> The basics are always easy, and eventually the bar moves up and those
> basics become commoditized, which is the word I guess I should have
> used rather than "worthless". That's why there are so many text
> editors these days, while it was a programming feat to make a text
> editor in the early days but today it's a well known problem.
>
> On Fri, Dec 19, 2014 at 2:32 AM, Matt Lind  wrote:
> > In your opinion, what would've needed to happen with the FXTree to make
> it a
> > 'real contender'.
> >
> > Matt
> >
> >
>


-- 
Christopher Crouzet
*http://christophercrouzet.com* <http://christophercrouzet.com>

Re: Humanize Maya effort alive? or - Effective customization??

2014-10-16 Thread Christopher Crouzet

And what are you demonstrating, Sebastien? A recalcitrant, chronic, and
annoying, selfishness with a strong flavor of stubbornness and whining.

I'm not defending AD nor Maya here, I highly dislike both of them. There's
a LOT of aspects in Maya that could/should be improved but everything has
been said hundreds of times already. If you think that constantly bashing
in such a way is going to help, I believe you're wrong. If I was a dev at
AD, I'd rather quit my job than having to deal with a community driven by
such behaviors.

Now I see two potential outcomes from wasting your energy and time
constantly bashing as soon as you stumble upon the word “AD”: higher blood
pressure and being blacklisted by potential recruiters on this list for
spending your time complaining instead of getting the shit done. How about
you spend instead your energy learning how to deal with Maya once for all?

And if you guys can't adapt to a different package because you're lacking
something as unimportant as sticky keys, then you should seriously think of
changing carreer. I mean it.

VFX softwares are in a transitional state atm and it's shit to be a user.
This will get better in the future but for now get over it.

On 17 October 2014 12:09, Sebastien Sterling 
wrote:

> And in doing so you demonstrated a recalcitrant resistance to change
> improvement and bettering of the package, for any reason. Further consernes
> where raised about the UI and you dismissed them. The reason Maya users put
> up with this shit, is not an incentive to do nothing. I'm sure a lot of
> Maya artists would welcome a clean up in the UI, think of initiatives like
> CADjunkie ZEN. http://cadjunkie.com/zen if anything it shows you care,
> and that you are comited to exploring and optimising user experience.
>
> Thanks for sharing Jason S hadn't heard of that. I really hope they can
> pull it off.
>
>  "unless bought or bribed." i wouldn't worry too much about that, the
> French are notoriously stubborn i can attest to this :P
>
> On 17 October 2014 03:46, Luc-Eric Rousseau  wrote:
>
>> No, the question of this thread is specially about whether someone
>> would build a softimage-like supra/sticky toolstack for Maya, and I'm
>> the only one that actually answered with any information on the
>> subject.
>>
>>
>> On Thu, Oct 16, 2014 at 10:33 PM, Jason S  wrote:
>> > On 10/16/14 9:59, Luc-Eric Rousseau wrote:
>> >
>> >> So there is no way we're going to break the hotkeys/marking menus for
>> >> everyone else to jam in a softimage-like tool stack.
>> >
>> > Hum.. I hardly think the complaint is that it's not like Soft,  as
>> opposed
>> > to it not (at-all) being as 'streamlined'.
>>
>
>

-- 
Christopher Crouzet
*http://christophercrouzet.com* <http://christophercrouzet.com>

Re: maya uv tool broken?

2014-09-08 Thread Christopher Crouzet

Look, I don't know shit in UV unfolding but I don't need to be an expert to
see that being a bit more respectful towards the devs wouldn't hurt you.
They might not be awesome everyday artists like you, they might not
experience their tool in the same way than you do, and they're not perfect
neither, but they've had the lucidity to implement a crazy complex
algorithm to help out people like you to not spend days unfolding a single
complex mesh and to save your ass from crazy deadlines. If such a “small”
problem blinds you from seeing all the benefits that you're gaining from
using that tool, then it's really a shame.

The Softimage databse isn't the Unfold3D database, so just try contacting
them directly to see how it goes. I'm sure that if you kindly explain them,
they could help.


On 8 September 2014 15:30, Matt Lind  wrote:

> Something that basic should not require me contacting the dev.  It should
> be a standard benchmark in testing the product for release as this feature
> is a staple in games production.  If the devs are not checking this, then
> they clearly have not done their homework in understanding the problem(s)
> that need to be solved with such a tool.  It’s kind of like designing and
> building a space shuttle that takes off, lands, maneuvers well in orbit, is
> serviceable, economical and meets all other bullet points on the spec sheet
> except account for the fact the astronauts need to be able to survive the
> flight.
>
>
>
> And yes, I’ve made the issues known along with many others, but if memory
> serves, somebody had the brilliant idea of deleting all those reports from
> the Softimage database.
>
>
>
>
>
> Matt
>
>
>
>
>
>
>
>
>
> *From:* softimage-boun...@listproc.autodesk.com [mailto:
> softimage-boun...@listproc.autodesk.com] *On Behalf Of *Christopher
> Crouzet
> *Sent:* Monday, September 08, 2014 11:21 AM
> *To:* Softimage Mailing List
>
> *Subject:* Re: maya uv tool broken?
>
>
>
> If you haven't done it yet, you could forward this kind of request
> directly to the dev: supp...@unfold3d.com
>
> He's really friendly and has even been on this list for some times now.
>
>
>
>
>
> On 8 September 2014 15:13, Matt Lind  wrote:
>
> If Maya is using the same Unfold3D as Softimage, then artists will still
> need to go to another software for UV layout because Unfold3D lacks very
> basic functionality required for certain types of work.  For example,
> unfolding a symmetrical object an having the resulting UVs laid out
> symmetrically to reflect the geometry's shape.  Unfold3D is very poor with
> that.
>
>
> Matt
>
>
>
> -Original Message-
> From: softimage-boun...@listproc.autodesk.com [mailto:
> softimage-boun...@listproc.autodesk.com] On Behalf Of Luc-Eric Rousseau
> Sent: Saturday, September 06, 2014 10:59 AM
> To: softimage@listproc.autodesk.com
> Subject: Re: maya uv tool broken?
>
> Hello,
>
> Unfold3d is build directly in Maya 2015 and accessible directly from the
> UV Editor menu.
> Then, there is a Bonus Tools which is a mel script that takes you
> step-by-step into setting up things and then call unfold.  That's not a new
> tool, but it's been updated to use the new Unfold3d.  I figured that if you
> knew how to use Softimage's Unfold3D you may not need the Bonus Tools.
>
> It's worth checking out all the changes in UV Editor and unfolding in the
> two separate sections here:
> http://help.autodesk.com/view/MAYAUL/2015/ENU/?guid=New_in_Modeling
>
> The team has studied UVLayout; going to it shouldn't be necessary for
> anything.
>
> On Sat, Sep 6, 2014 at 11:48 AM, Manuel Huertas Marchena <
> lito...@hotmail.com> wrote:
> > "I don't know The bonus tool predates 2015 and the new workflows ."
>  what
> > do you mean? sorry it might be obvious but usually I use uvlayout for
> > this type of task, so I am trying to find the "best" way to approach
> > uvs inside maya to rely less in uvlayout for simple geo.
> > My approach in xsi was usually do all ("simple geo") uvs in xsi and
> > complex geo unwrap, uvs packing, uv islands ratio inside uvlayout. I
> > am now replacing xsi for maya and will like to keep the same workflow.
> > So if the "uvtool" is supposed to be "the new way" of unwrapping
> > meshes in maya 2015, I was asking why is not included by default? but
> > again being a bit new, I am surely missing something obvious :)
>
>
>
>
>
> --
>
> Christopher Crouzet
> *http://christophercrouzet.com* <http://christophercrouzet.com>
>
>
>



-- 
Christopher Crouzet
*http://christophercrouzet.com* <http://christophercrouzet.com>

Re: maya uv tool broken?

2014-09-08 Thread Christopher Crouzet

If you haven't done it yet, you could forward this kind of request directly
to the dev: supp...@unfold3d.com
He's really friendly and has even been on this list for some times now.


On 8 September 2014 15:13, Matt Lind  wrote:

> If Maya is using the same Unfold3D as Softimage, then artists will still
> need to go to another software for UV layout because Unfold3D lacks very
> basic functionality required for certain types of work.  For example,
> unfolding a symmetrical object an having the resulting UVs laid out
> symmetrically to reflect the geometry's shape.  Unfold3D is very poor with
> that.
>
>
> Matt
>
>
>
> -Original Message-
> From: softimage-boun...@listproc.autodesk.com [mailto:
> softimage-boun...@listproc.autodesk.com] On Behalf Of Luc-Eric Rousseau
> Sent: Saturday, September 06, 2014 10:59 AM
> To: softimage@listproc.autodesk.com
> Subject: Re: maya uv tool broken?
>
> Hello,
>
> Unfold3d is build directly in Maya 2015 and accessible directly from the
> UV Editor menu.
> Then, there is a Bonus Tools which is a mel script that takes you
> step-by-step into setting up things and then call unfold.  That's not a new
> tool, but it's been updated to use the new Unfold3d.  I figured that if you
> knew how to use Softimage's Unfold3D you may not need the Bonus Tools.
>
> It's worth checking out all the changes in UV Editor and unfolding in the
> two separate sections here:
> http://help.autodesk.com/view/MAYAUL/2015/ENU/?guid=New_in_Modeling
>
> The team has studied UVLayout; going to it shouldn't be necessary for
> anything.
>
> On Sat, Sep 6, 2014 at 11:48 AM, Manuel Huertas Marchena <
> lito...@hotmail.com> wrote:
> > "I don't know The bonus tool predates 2015 and the new workflows ."
>  what
> > do you mean? sorry it might be obvious but usually I use uvlayout for
> > this type of task, so I am trying to find the "best" way to approach
> > uvs inside maya to rely less in uvlayout for simple geo.
> > My approach in xsi was usually do all ("simple geo") uvs in xsi and
> > complex geo unwrap, uvs packing, uv islands ratio inside uvlayout. I
> > am now replacing xsi for maya and will like to keep the same workflow.
> > So if the "uvtool" is supposed to be "the new way" of unwrapping
> > meshes in maya 2015, I was asking why is not included by default? but
> > again being a bit new, I am surely missing something obvious :)
>
>


-- 
Christopher Crouzet
*http://christophercrouzet.com* <http://christophercrouzet.com>

Re: Manuka. Weta Digitals new renderer. That hair...

2014-08-07 Thread Christopher Crouzet

For having seen a few early test renders, it was really, really,
impressive. Gollum became more realistic than ever even though the shaders
were the same.



On 7 August 2014 05:13, pedro santos  wrote:

> http://www.fxguide.com/featured/manuka-weta-digitals-new-renderer/
>
> Cheers
>
> --
>
>
>
>
> *-- [image:
> http://i153.photobucket.com/albums/s202/animatics/probiner-sig.gif] Pedro
> Alpiarça dos Santos  Animator  3DModeler  Illustrator >>
> http://probiner.x10.mx/ <http://probiner.x10.mx/> *
>



-- 
Christopher Crouzet
*http://christophercrouzet.com* <http://christophercrouzet.com>

Re: Fabric at Siggraph details

2014-07-30 Thread Christopher Crouzet

Provocation 1 - 0 Paul :)

Awesome news and best luck for the Siggraph!



On 30 July 2014 09:28, Paul Doyle  wrote:

> I might ask Rob Pieke to release his build :) I think we'll get it in for
> 2.0, but it's still going to be limited due to OGL nonsense:
> https://groups.google.com/d/msg/creationplatform/N-jhukVLdxk/hRt66k42H6cJ
>
>
> On 30 July 2014 09:20, Christopher Crouzet 
> wrote:
>
>> Sounds like we'll never have Splice on Mac! :)
>>
>>
>> On 30 July 2014 09:17, Paul Doyle  wrote:
>>
>>> #Windows4Life #NonUniformScalingIsBestScaling etc etc :)
>>>
>>>
>>> On 30 July 2014 09:11, Andy Goehler 
>>> wrote:
>>>
>>>> On Jul 30, 2014, at 14:05, Paul Doyle  wrote:
>>>>
>>>> > …(and people with their damn Macs)…
>>>>
>>>> Instead of criticizing peoples excellent taste for hardware and
>>>> operation system, get to work on those ‘damn’ rounded rectangles :-)
>>>> May the hexagon be with you.
>>>>
>>>> Andy
>>>>
>>>
>>>
>>
>>
>> --
>> Christopher Crouzet
>> *http://christophercrouzet.com* <http://christophercrouzet.com>
>>
>>
>


-- 
Christopher Crouzet
*http://christophercrouzet.com* <http://christophercrouzet.com>

Re: Fabric at Siggraph details

2014-07-30 Thread Christopher Crouzet

Sounds like we'll never have Splice on Mac! :)


On 30 July 2014 09:17, Paul Doyle  wrote:

> #Windows4Life #NonUniformScalingIsBestScaling etc etc :)
>
>
> On 30 July 2014 09:11, Andy Goehler  wrote:
>
>> On Jul 30, 2014, at 14:05, Paul Doyle  wrote:
>>
>> > …(and people with their damn Macs)…
>>
>> Instead of criticizing peoples excellent taste for hardware and operation
>> system, get to work on those ‘damn’ rounded rectangles :-)
>> May the hexagon be with you.
>>
>> Andy
>>
>
>


-- 
Christopher Crouzet
*http://christophercrouzet.com* <http://christophercrouzet.com>

Re: 1/2 OT: Gorilla and a banana for Maya

2014-06-29 Thread Christopher Crouzet

In the lack of answer, I guess we shouldn't count too much on the future of
the API 2.0 :)



On 25 June 2014 11:33, Sebastien Sterling 
wrote:

> A brave initiative Christopher, and thank you for laying it out plain for
> the less techsavvy,
>
>
> "why are you using the maya python API 1.0 instead of 2.0 ?"
>
> Why is Python API 2.0 not finished yet Luc Eric ?
>
>
> On 24 June 2014 17:31, Christopher Crouzet 
> wrote:
>
>> When I initially patched the Maya Python API, it was with Maya 2010 and
>> there was no API 2.0 back then. As of today, I didn't really think about my
>> choice, I simply wanted to share the technique.
>>
>> That said, and remembering the state of the API 2.0, it could indeed have
>> been the subject of the article/library but then I'm not sure if patching a
>> yet unfinished API would be the wisest choice since it will have its gaps
>> officially filled in over the releases, right?
>>
>>
>>
>> On 24 June 2014 12:12, Luc-Eric Rousseau  wrote:
>>
>>> why are you using the maya python API 1.0 instead of 2.0 ?
>>>
>>
>>
>>
>> --
>> Christopher Crouzet
>> *http://christophercrouzet.com* <http://christophercrouzet.com>
>>
>>
>


-- 
Christopher Crouzet
*http://christophercrouzet.com* <http://christophercrouzet.com>

Re: Looking for artists

2014-06-27 Thread Christopher Crouzet

The other thread reminds me of this one... anyone knows if it turned out to
be legit?


On 26 September 2013 05:53, Gustavo Eggert Boehs 
wrote:

> NAN
>
> Em quinta-feira, 26 de setembro de 2013, Dan Yargici escreveu:
>
> +1bazillion
>>
>> On 25 Sep 2013 18:58, "Eric Lampi"  wrote:
>> >
>> > You are illustrating exactly what is a consistent problem with artists
>> in our industry. If people like yourself would pose the obvious questions
>> and treat this as a business, we would all be far better off.
>> >
>> > As we all know far too well, if it hasn't happened to you, you
>> certainly know more than a few people who haven't gotten paid or had to
>> suffer through awful working conditions. 99% of the time it's because they
>> didn't treat the situation as business. This isn't a social relationship we
>> are talking about here, it's a business relationship. The more you go into
>> it without asking the obvious questions the more likely you will have a
>> misunderstanding or even a situation where you are completely being taken
>> advantage of.
>> >
>> > If you ever encounter someone who is personally offended by you asking
>> specific questions about the terms of your future employment, or later on,
>> that you expect them to live up to the terms you both agreed on, you should
>> probably think twice about trusting them.
>> >
>> > I am not saying that there is anything unsavory going on with this
>> studio, just using this to make a few points.
>> >
>> > Eric
>> >
>> >
>> > Freelance 3D and VFX animator
>> >
>> > http://vimeopro.com/user7979713/3d-work
>> >
>>
>
>
> --
> Gustavo E Boehs
> Dpto. de Expressão Gráfica
> Universidade Federal de Santa Catarina
> http://www.gustavoeb.com.br/blog
>
>
> --
> To unsubscribe: mail softimage-requ...@listproc.autodesk.com with subject
> "unsubscribe" and reply to the confirmation email.
>



-- 
Christopher Crouzet
*http://christophercrouzet.com* <http://christophercrouzet.com>

Re: 1/2 OT: Gorilla and a banana for Maya

2014-06-25 Thread Christopher Crouzet

Cheers Sebastien!

Here's a small follow up for the few that it might interest: Why I'm Not
Using the MEL and the Python Commands Layers of Maya
<http://christophercrouzet.com/blog/post/2014/06/25/Why-I-m-Not-Using-the-MEL-and-the-Python-Commands-Layers-of-Maya>



On 25 June 2014 11:33, Sebastien Sterling 
wrote:

> A brave initiative Christopher, and thank you for laying it out plain for
> the less techsavvy,
>
>
> "why are you using the maya python API 1.0 instead of 2.0 ?"
>
> Why is Python API 2.0 not finished yet Luc Eric ?
>
>
> On 24 June 2014 17:31, Christopher Crouzet 
> wrote:
>
>> When I initially patched the Maya Python API, it was with Maya 2010 and
>> there was no API 2.0 back then. As of today, I didn't really think about my
>> choice, I simply wanted to share the technique.
>>
>> That said, and remembering the state of the API 2.0, it could indeed have
>> been the subject of the article/library but then I'm not sure if patching a
>> yet unfinished API would be the wisest choice since it will have its gaps
>> officially filled in over the releases, right?
>>
>>
>>
>> On 24 June 2014 12:12, Luc-Eric Rousseau  wrote:
>>
>>> why are you using the maya python API 1.0 instead of 2.0 ?
>>>
>>
>>
>>
>> --
>> Christopher Crouzet
>> *http://christophercrouzet.com* <http://christophercrouzet.com>
>>
>>
>


-- 
Christopher Crouzet
*http://christophercrouzet.com* <http://christophercrouzet.com>

Re: 1/2 OT: Gorilla and a banana for Maya

2014-06-24 Thread Christopher Crouzet

When I initially patched the Maya Python API, it was with Maya 2010 and
there was no API 2.0 back then. As of today, I didn't really think about my
choice, I simply wanted to share the technique.

That said, and remembering the state of the API 2.0, it could indeed have
been the subject of the article/library but then I'm not sure if patching a
yet unfinished API would be the wisest choice since it will have its gaps
officially filled in over the releases, right?

On 24 June 2014 12:12, Luc-Eric Rousseau  wrote:

> why are you using the maya python API 1.0 instead of 2.0 ?
>

-- 
Christopher Crouzet
*http://christophercrouzet.com* <http://christophercrouzet.com>

1/2 OT: Gorilla and a banana for Maya

2014-06-23 Thread Christopher Crouzet

Hey gang,

as promised in a previous post, I've finished writing an article about how
to monkey patch external libraries in Python while using the Maya Python
API as a guinea pig. It took me a bit longer than planned because I also
decided to build a couple of open source libraries on that matter.

You can find the article and all the information over there: From Monkey
Patching the Maya Python API to Gorilla and Bananas
<http://christophercrouzet.com/blog/post/2014/06/23/From-Monkey-Patching-the-Maya-Python-API-to-Gorilla-and-Bananas>
.

And here's a short(er) version:

Monkey patching allows you to modify an existing 3rd-party library by
inserting some code of yours. Once the process is done, you can call the
extensions you've inserted as if they have always been part of that
3rd-party library.

The article uses Maya as a playground but the technique can definitely be
applied to about anything, which is what the library Gorilla
<https://github.com/christophercrouzet/gorilla> is all about. You write
your functions, classes, methods, properties, whatever, you tell them the
target to patch with the help of a Python decorator, and that's about it.
You can find more details in the documentation
<http://gorilla.readthedocs.org/>.

As a proof of concept for this project, I've developed a couple of
extensions for the Maya Python API. Say hi to Banana for Maya
<https://github.com/christophercrouzet/banana.maya>. This basically shows
that extending the API can be as simple as:

@gorilla.patch(OpenMaya.MFnTransform)
def whoAmI(self):
print("My name is %s" % self.name())

Which allows you to fire the method through a call to `
OpenMaya.MFnTransform.whoAmI()`.

As for the extensions already in there, there's a shiny documentation
<http://bananamaya.readthedocs.org/> for this one too.

Once again the `banana.maya` package is only a proof of concept, which is
why it's a bit empty. I've started to implement some methods that could
hopefully be useful to everyone (mainly retrieving/iterating through the
nodes in the scene) but I'm currently not using Maya anymore and don't have
any direct interest in developing those extensions much further. The
exception being if there's a need for it and if discussions can be
organized to implement the right features.

Note that I'm not saying that monkey patching the Maya Python API v1.0 is
the way to go and I acknowledge that there's better alternatives out there
for most cases.

That's about it. The code is yours, do what you want with it.

Cheers,
Christopher.

PS: Raff, I hope you'll appreciate the lack of vast sidereal space
in-between each statement that you've known me for :)

--
Christopher Crouzet
*http://christophercrouzet.com* <http://christophercrouzet.com>

Re: OT: What was your biggest challenge/nightmare with Softimage and how did you overcome it?

I should have a better topic within a couple of weeks, you'll let me know
what you think.


On 11 June 2014 22:23, Eric Thivierge  wrote:

>
> On Wed, Jun 11, 2014 at 10:18 PM, Christopher Crouzet <
> christopher.crou...@gmail.com> wrote:
>
>> That's indeed better! :) But not so constructive either for such a
>> mailing list IMO. Anyways...
>
>
> God a better topic? Shoot one off, let's get to it...
>
> ----
> Eric Thivierge
> http://www.ethivierge.com
>



-- 
Christopher Crouzet
*http://christophercrouzet.com* <http://christophercrouzet.com>

Re: OT: What was your biggest challenge/nightmare with Softimage and how did you overcome it?

That's indeed better! :) But not so constructive either for such a mailing
list IMO. Anyways...



On 11 June 2014 11:10, Eric Thivierge  wrote:

> I much prefer these types of threads to the doom and gloom regurgitated
> topics.
>
> Though I'm not interested in the thread topic, I don't see anything wrong
> with it.
>
> Eric T.
>
>
> On 6/11/2014 10:52 AM, Christopher Crouzet wrote:
>
>> You like trying to create sensational threads, don't you? Is your goal to
>> get as much replies as possible?
>> My own goal is to be a party pooper, sorry :)
>>
>
>


-- 
Christopher Crouzet
*http://christophercrouzet.com* <http://christophercrouzet.com>

Re: OT: What was your biggest challenge/nightmare with Softimage and how did you overcome it?

PS: funningly my Gmail marked your email as spam.



On 11 June 2014 10:52, Christopher Crouzet 
wrote:

> You like trying to create sensational threads, don't you? Is your goal to
> get as much replies as possible?
> My own goal is to be a party pooper, sorry :)
>
>
> On 11 June 2014 00:18, David Rivera 
> wrote:
>
>> Mine was rigging 3 fully shaped based and IK/FK - eyes, mouth blends,
>> etc.. anthropomorphic characters rigged in only one month.
>> 2 solid weeks coding expressions and then re-adapting to new characters,
>> sculpting mouth (vocal) shapes for a whole
>> week (synoptics included), and finally breaking rigs by 4th week. Ready
>> and delivered.
>>
>> Things got worst when director wanted to add hair on top of all this for
>> 2 of the 3 charactersat final stage...
>>
>> Had to delete hairs on first render test showed to directors. Render time
>> went up for 3 whole days (Quad-core machines with 16 gbs of RAM)
>> for just 250 frames. Animators took them for a ride by the end of the
>> month and everyone happy at former studio.
>>
>>
>> So what was your challenge/nightmare and how did you do to get it out and
>> deliver on time?
>>
>>
>> *David Rivera*
>> *3D Compositor/Animator*
>> LinkedIN <http://ec.linkedin.com/in/3dcinetv>
>> Behance <https://www.behance.net/3dcinetv>
>> VFX Reel <https://vimeo.com/70551635>
>>
>
>
>
> --
> Christopher Crouzet
> *http://christophercrouzet.com* <http://christophercrouzet.com>
>
>


-- 
Christopher Crouzet
*http://christophercrouzet.com* <http://christophercrouzet.com>

Re: OT: What was your biggest challenge/nightmare with Softimage and how did you overcome it?

You like trying to create sensational threads, don't you? Is your goal to
get as much replies as possible?
My own goal is to be a party pooper, sorry :)


On 11 June 2014 00:18, David Rivera  wrote:

> Mine was rigging 3 fully shaped based and IK/FK - eyes, mouth blends,
> etc.. anthropomorphic characters rigged in only one month.
> 2 solid weeks coding expressions and then re-adapting to new characters,
> sculpting mouth (vocal) shapes for a whole
> week (synoptics included), and finally breaking rigs by 4th week. Ready
> and delivered.
>
> Things got worst when director wanted to add hair on top of all this for 2
> of the 3 charactersat final stage...
>
> Had to delete hairs on first render test showed to directors. Render time
> went up for 3 whole days (Quad-core machines with 16 gbs of RAM)
> for just 250 frames. Animators took them for a ride by the end of the
> month and everyone happy at former studio.
>
>
> So what was your challenge/nightmare and how did you do to get it out and
> deliver on time?
>
>
> *David Rivera*
> *3D Compositor/Animator*
> LinkedIN <http://ec.linkedin.com/in/3dcinetv>
> Behance <https://www.behance.net/3dcinetv>
> VFX Reel <https://vimeo.com/70551635>
>



-- 
Christopher Crouzet
*http://christophercrouzet.com* <http://christophercrouzet.com>

Re: First Softimage -> Maya transition videos posted

2014-05-13 Thread Christopher Crouzet

I've been wondering the same for some time... you can't imagine all the
complaints that my work colleagues had to endure when I started to use Maya
:)



On 13 May 2014 14:30, Jordi Bares  wrote:

> I don't know if I want to cry or laugh…
>
> Probably both… on a loop.
>
> jb
>
>
> On 13 May 2014, at 17:52, Christopher Crouzet <
> christopher.crou...@gmail.com> wrote:
>
> The code flushing out after execution is indeed a bit annoying but you get
> used to it. The combo Ctrl+A then Ctrl+Enter quickly becomes an automatism.
>
> The two biggest annoyances for me were to code within the Script Editor (I
> guess I'm too used to Sublime Text), and more importantly the persistence
> of the variables. In my case this seemed to cause more bugs than the other
> way around. Example: when refactoring a code and deleting some variables,
> you expect the execution of the script to raise some errors if you forgot
> to remove some occurences of those variables that you've deleted. With this
> persistence thing, this will won't warn you of anything. If you're unlucky,
> this will even preserve the expected behavior of the script. Then, when you
> copy/paste the code in a library or when you reload Maya, bam.
>
> I guess the Script Editor is not made to code your super complex functions
> anyways, but to workaround those issues, I came to use a quick/hacky
> solution.
> The idea is to create a .py script file somewhere in which you define a
> main function that contains your script and that you call at the end of the
> file.
>
> def main():
> maya = 'workaround land'
> print maya
>
> main()
>
>
> Then, just create a button in the shell that calls `execfile` with the
> path of the .py file. The variables defined within the main function won't
> pollute the environment—they won't persist.
>
> There's probably ways to wrap this up more nicely but I couldn't be arsed.
>
>
>
> On 13 May 2014 12:27, Jordi Bares  wrote:
>
>> Exactly right.
>>
>>  Jordi Bares
>> jordiba...@gmail.com
>>
>> On 13 May 2014, at 17:13, Peter Agg  wrote:
>>
>> Basically I want my scripts to stay there - whether I run them or close
>> the program. I'll delete them when I'm good and ready, damnit!
>>
>>
>> On 13 May 2014 15:42, Eric Thivierge  wrote:
>>
>>> What do you mean? Close and reopen it and your scripts are still there.
>>> If you're talking about when you close Softimage, that is expected. That
>>> kind of functionality is weird to me in Maya. It's like reloading your last
>>> scene you had open before you closed the last time.
>>
>>
>>
>
>
> --
> Christopher Crouzet
> *http://christophercrouzet.com* <http://christophercrouzet.com/>
>
>
>


-- 
Christopher Crouzet
*http://christophercrouzet.com* <http://christophercrouzet.com>

Re: First Softimage -> Maya transition videos posted

2014-05-13 Thread Christopher Crouzet

The code flushing out after execution is indeed a bit annoying but you get
used to it. The combo Ctrl+A then Ctrl+Enter quickly becomes an automatism.

The two biggest annoyances for me were to code within the Script Editor (I
guess I'm too used to Sublime Text), and more importantly the persistence
of the variables. In my case this seemed to cause more bugs than the other
way around. Example: when refactoring a code and deleting some variables,
you expect the execution of the script to raise some errors if you forgot
to remove some occurences of those variables that you've deleted. With this
persistence thing, this will won't warn you of anything. If you're unlucky,
this will even preserve the expected behavior of the script. Then, when you
copy/paste the code in a library or when you reload Maya, bam.

I guess the Script Editor is not made to code your super complex functions
anyways, but to workaround those issues, I came to use a quick/hacky
solution.
The idea is to create a .py script file somewhere in which you define a
main function that contains your script and that you call at the end of the
file.

def main():
maya = 'workaround land'
print maya

main()

Then, just create a button in the shell that calls `execfile` with the path
of the .py file. The variables defined within the main function won't
pollute the environment—they won't persist.

There's probably ways to wrap this up more nicely but I couldn't be arsed.

On 13 May 2014 12:27, Jordi Bares  wrote:

> Exactly right.
>
> Jordi Bares
> jordiba...@gmail.com
>
> On 13 May 2014, at 17:13, Peter Agg  wrote:
>
> Basically I want my scripts to stay there - whether I run them or close
> the program. I'll delete them when I'm good and ready, damnit!
>
>
> On 13 May 2014 15:42, Eric Thivierge  wrote:
>
>> What do you mean? Close and reopen it and your scripts are still there.
>> If you're talking about when you close Softimage, that is expected. That
>> kind of functionality is weird to me in Maya. It's like reloading your last
>> scene you had open before you closed the last time.
>
>
>

-- 
Christopher Crouzet
*http://christophercrouzet.com* <http://christophercrouzet.com>

Re: XSI GUI for Maya

2014-05-09 Thread Christopher Crouzet

As soon as one understands that Raff likes coming up with—sometimes
incorrect—arguments only for the fun of proving someone wrong and that he
will always have the last word, we're good :)

Sorry, I'm out of this discussion already.



On 9 May 2014 07:28, Luc-Eric Rousseau  wrote:

> I'm on your side on this Christopher, but please don't tell raff
> Shortcuts and UI are two different things—forcing an UI from a package
> with a different philosophy is just meaningless IMO. It's like playing a
> PS4 game with a Super Nintendo controller, it might have some shared
> controls but it's not the same interface and won't work but if you agree on
> not being able to jump, run, aim, and whatsoever.
>
> My custom shortcuts—which really are only slightly different from the
> original ones and that I definitely kept at Weta— are simply beyond
> understanding because I'm too awesome for the common of the mortals. Get
> used to that too! And I liked the idea to keep you away from my keyboard
> anyways :)
>
>
>
> On 8 May 2014 21:33, Raffaele Fragapane wrote:
>
>> That's why all animators had tablets.
>>
>>
>> On Fri, May 9, 2014 at 10:35 AM, Eric Thivierge wrote:
>>
>>>
>>> On Thu, May 8, 2014 at 8:28 PM, Raffaele Fragapane <
>>> raffsxsil...@googlemail.com> wrote:
>>>
>>>> Maybe he's had it physically beaten out of him at Weta and now wants to
>>>> inflict the same on others ;)
>>>> And yeah, whenever I was at Toph's desk the first thing was changing
>>>> the bindings. Well, second thing, the first usually was berating him and
>>>> tossing the mouse at the monitor.
>>>>
>>>
>>> Raf sure knows how to throw a mouse at a monitor... he could be an MLB
>>> pitcher if he put his mind to it.
>>>
>>> 
>>> Eric Thivierge
>>> http://www.ethivierge.com
>>>
>>
>>
>>
>> --
>> Our users will know fear and cower before our software! Ship it! Ship it
>> and let them flee like the dogs they are!
>>
>
>
>
> --
> Christopher Crouzet
> *http://christophercrouzet.com* <http://christophercrouzet.com>
>
>


-- 
Christopher Crouzet
*http://christophercrouzet.com* <http://christophercrouzet.com>

Re: XSI GUI for Maya

2014-05-08 Thread Christopher Crouzet

Shortcuts and UI are two different things—forcing an UI from a package with
a different philosophy is just meaningless IMO. It's like playing a PS4
game with a Super Nintendo controller, it might have some shared controls
but it's not the same interface and won't work but if you agree on not
being able to jump, run, aim, and whatsoever.

My custom shortcuts—which really are only slightly different from the
original ones and that I definitely kept at Weta— are simply beyond
understanding because I'm too awesome for the common of the mortals. Get
used to that too! And I liked the idea to keep you away from my keyboard
anyways :)

On 8 May 2014 21:33, Raffaele Fragapane  wrote:

> That's why all animators had tablets.
>
>
> On Fri, May 9, 2014 at 10:35 AM, Eric Thivierge wrote:
>
>>
>> On Thu, May 8, 2014 at 8:28 PM, Raffaele Fragapane <
>> raffsxsil...@googlemail.com> wrote:
>>
>>> Maybe he's had it physically beaten out of him at Weta and now wants to
>>> inflict the same on others ;)
>>> And yeah, whenever I was at Toph's desk the first thing was changing the
>>> bindings. Well, second thing, the first usually was berating him and
>>> tossing the mouse at the monitor.
>>>
>>
>> Raf sure knows how to throw a mouse at a monitor... he could be an MLB
>> pitcher if he put his mind to it.
>>
>> 
>> Eric Thivierge
>> http://www.ethivierge.com
>>
>
>
>
> --
> Our users will know fear and cower before our software! Ship it! Ship it
> and let them flee like the dogs they are!
>

-- 
Christopher Crouzet
*http://christophercrouzet.com* <http://christophercrouzet.com>

Re: XSI GUI for Maya

2014-05-08 Thread Christopher Crouzet

Do you guys realize that it's the worst way possible to learn a new
software and the best way possible to make difficult any assistance between
you and your coworkers?
Maya interface stinks but modifying it will only break it even more.

Get used to it.



On 8 May 2014 11:01, Manuel Huertas Marchena  wrote:

> whaat?!! didn't know something like that existed. Is there a link to the
> actual ui code/plugin?
> does someone know if its compatible with maya 2014+? ...sorry I just saw
> this, maybe this has been answered,
> I am very curious to try it..
>
> thanks
>
>
> -Manuel
>
>
>
> IMDB <http://www.imdb.com/name/nm4755969/> | Portfolio
> <http://envmanu.com> <http://envmanu.carbonmade.com/>| 
> Vimeo<http://vimeo.com/manuelhuertasmarchena>|
> Linkedin <http://www.linkedin.com/in/manuelhuertas>
>
>
> --
> From: danyarg...@gmail.com
> Date: Thu, 8 May 2014 15:54:05 +0100
> Subject: Re: XSI GUI for Maya
> To: softimage@listproc.autodesk.com
>
> https://groups.google.com/d/msg/xsi_list/KkzGNexn1ME/Wn-m3RDVPOEJ
>
> DAN
>
>
> On Thu, May 8, 2014 at 3:22 PM, gareth bell wrote:
>
> Just out of idle curiosity.
>
> A while back someone posted a picture of an XSI UI/Skin that someone made
> for maya. Anyone know where that is?
>
> cheers
>
>
>


-- 
Christopher Crouzet
*http://christophercrouzet.com* <http://christophercrouzet.com>

Re: Softimage Python versus Maya Python

2014-05-06 Thread Christopher Crouzet

ed in XSI will have crawling over walls and spewing
> like the child from the Exorcist movie.
> There are good days when I don't have to roam in the dark areas, and
> writing/porting some nodes is an enjoyable experience. Other days I have to
> call IT for a new monitor.
>
>
>
>
> On Wed, May 7, 2014 at 12:35 AM, Leendert A. Hartog wrote:
>
>> See what you did there? You confused me needlessly. ;)
>> >From all of this I gather there is an original Python implementation,
>> PyMEL and Maya Python 2.0.
>> And some comments seem to imply none of them are any good...
>> So where to actually start, if this is more of less true?
>> What comes closest to our "beloved" Softimage Python scripting experience?
>>
>>
>> Greetz
>> Leendert
>>
>> --
>>
>> Leendert A. Hartog AKA Hirazi Blue
>> Administrator NOT the owner of si-community.com
>>
>>
>
>
> --
> Our users will know fear and cower before our software! Ship it! Ship it
> and let them flee like the dogs they are!
>



-- 
Christopher Crouzet
*http://christophercrouzet.com* <http://christophercrouzet.com>

Re: SDK: Envelope weight locking

2014-04-25 Thread Christopher Crouzet

Guillaume had a creative—but not so robust, no offence—solution for that
one.
It's in a thread from this list named "Retrieving the lock flag of envelope
weights" and dating from 27/05/2009. Good times :)



On 25 April 2014 19:27, Jeremie Passerin  wrote:

> Yep, I've asked the same thing a while ago... not possible.
> This is one great feature by the way. Does Maya have that ?
>
>
> On 25 April 2014 17:10, Eric Thivierge  wrote:
>
>> If I recall correctly, there is not. One of the other riggers found this
>> limitation a year or so back.
>>
>> 
>> Eric Thivierge
>> http://www.ethivierge.com
>>
>>
>> On Fri, Apr 25, 2014 at 7:46 PM, Matt Lind wrote:
>>
>>> There are commands to set and clear locks on weight values for a given
>>> point/deformer pair in an envelope (LockEnvelopeWeights(),
>>> ClearEnvelopeWeightLocks()), but I don’t see anything to read whether a
>>> point/deformer weight is locked or not.
>>>
>>>
>>>
>>> Anybody know if this is possible?
>>>
>>>
>>>
>>> Matt
>>>
>>
>>
>


-- 
Christopher Crouzet
*http://christophercrouzet.com* <http://christophercrouzet.com>

Re: Zoogloo Rigging Tools

2014-03-16 Thread Christopher Crouzet

Hey Greg, please correct me if I'm wrong but from your description and
after very quickly overlooking at your code, does it mean that you had to
write the code to build each rig component (block) twice? Once for each
software?



On 15 March 2014 06:57, Greg Maguire  wrote:

> Hi guys,
>
> I'm enjoying the discussion regarding Fabric and the cross-DCC rigging
> project. I didn't want to hi-jack the thread so started this one. Apologies
> if it's redundant.
>
> I've been involved in building several rigging systems. So, much so that I
> co-founded Zoogloo with Andy Buecker in 2006 to rig for studios. We worked
> on 25 different projects over a three year period including, Spiderman3,
> Where The Wild Things Are, Happy Feet, Thundercats and more. Because we
> worked on animated features, episodic television, games and visual effects
> features and in Maya and in Softimage, we developed an in-house rigging
> system that took a different approach to any rigging system at the time and
> any that I have seen since.
>
> Having worked at ILM and witnessed the size of the team that had to be
> hired to translate between maya and ILM's proprietary tools, we decided to
> go further up the chain and develop a higher level rigging tool. We would
> not translate between softwares, we would instead issue each package
> instructions that would be built natively.
>
> i.e. a node based editor to build connections between blocks of body
> parts. A block would have characteristics built in, a 3-bone spine, or a
> 9-boneIKFK spine or a Disney-foot or an ILM-head. Each block then passed
> their data to a python script built for maya or softimage natively. i.e. we
> had to write Disney-foot in python for Maya and python for Softimage.
>
> btw. You can tell from my poor explanation above which one of us did the
> majority of the coding! (thanks Andy, you rock!)
>
> It addressed the following issues:
>
> 1. Developing rigs for Maya, Softimage and any other software (Fabric?)
> 2. Developing rigs for games, animated features, episodic television and
> vfx.
> 2. Naming convention mapping between all objects, controls for different
> studios.
> 3. SQLite for storing, geom, transforms, weights.
>
> Anyway, to cut what could be an incredibly long story short we Opened
> Sourced the tools some time ago but didn't tell anyone. I thought some
> of our work might be of use to you guys:
>
> Two years amount of work here, it might speed things up.
> https://github.com/abuecker/Zoogloo-Tools
>
> Warmest regards.
>
> --
>
> *Greg Maguire* | Inlifesize
> Mobile: +44 7512 361462 | Phone: +44 2890 204739
> g...@inlifesize.com | www.inlifesize.com
>



-- 
Christopher Crouzet
*http://christophercrouzet.com* <http://christophercrouzet.com>

Re: YOUR TOP 5

2014-03-13 Thread Christopher Crouzet

It would be more fair to regroup the list of top5 into distinct categories:
modelling, rigging, animation, rendering, FX ... and a general one for the
workflow, UI, and such.

Here's a quickie from my experience of using Maya in rigging/dev:

*Rigging*
- friendly weights painting and spreadsheet that works just the way they
are supposed to
- GATOR. And please don't compare this wonder to the Transfer Attributes of
Maya.
- being able to do *live* corrective shapes on a deformed mesh

*General*
- ICE
- the API... seriously, having a logical and consistent API that is easy to
use and don't need additional efforts to do simple dev tasks won't go in
the way of flexibility. I don't know of any dev who didn't complain
about Maya's API.
- proper and complete port of the API to Python


On 13 March 2014 04:54, Alastair Hearsum  wrote:

>  Hello
>
> It seems as if I may have some contact with Autodesk shortly! I want to be
> armed with some points. What I'd like is your top 5 features that make
> Softimage great that we'd miss if we migrated to something else.
>
> Please don't give me more than 5 and please don't go on too long
> describing them (It takes a while to read all the posts).
>
> Thanks
>
> Alastair
>
> --
>  Alastair Hearsum
>  Head of 3d
> [image: GLASSWORKS]
>  33/34 Great Pulteney Street
> London
> W1F 9NP
> +44 (0)20 7434 1182
> glassworks.co.uk <http://www.glassworks.co.uk/>
>  Glassworks Terms and Conditions of Sale can be found at glassworks.co.uk
>  (Company registered in England with number 04759979. Registered office 25
> Harley Street, London, W1G 9BR. VAT registration number: 86729)
>  Please consider the environment before you print this email.
>  DISCLAIMER: This e-mail and attachments are strictly privileged, private
> and confidential and are intended solely for the stated recipient(s). Any
> views or opinions presented are solely those of the author and do not
> necessarily represent those of the Company. If you are not the intended
> recipient, be advised that you have received this e-mail in error and that
> any use, dissemination, forwarding, printing, or copying of this e-mail is
> strictly prohibited. If this transmission is received in error please
> kindly return it to the sender and delete this message from your system.
>



-- 
Christopher Crouzet
*http://christophercrouzet.com* <http://christophercrouzet.com>

Re: Softimage Has Been Killed, the Future of CG Softwares Is Now in TD's Hands

2014-03-13 Thread Christopher Crouzet

Haha yeah I know it, thanks. I'm more into less touristic places though,
such as Cajamarca and Chachapoyas :)



On 13 March 2014 02:07, Cristobal Infante  wrote:

> Hi Chris,
>
> There is a beach called Mancora just up north of where you are that I can
> recommend. It's a surfer spot and I remember some good vibes and waves ;)
>
>
> On Thursday, 13 March 2014, Christopher Crouzet <
> christopher.crou...@gmail.com> wrote:
>
>> Nah, I'm in Pimentel atm, next to Chiclayo, in the North.
>> I will soon be heading South to Lima, Abancay and Arequipa before hitting
>> Cuzco. Huacachina sounds fun, maybe I'll do a detour, thanks for sharing!
>>
>> Ok, let's try to not get any more OT... bring on Voodoo!!
>>
>>
>>
>> On 12 March 2014 14:34, Ahmidou Lyazidi  wrote:
>>
>>> Are you in Huacacina? I loved my trip to Peru, it's one of my prefered
>>> place in the world !
>>>
>>
>>
>>
>> --
>> Christopher Crouzet
>> *http://christophercrouzet.com* <http://christophercrouzet.com>
>>
>>


-- 
Christopher Crouzet
*http://christophercrouzet.com* <http://christophercrouzet.com>

Re: Softimage Has Been Killed, the Future of CG Softwares Is Now in TD's Hands

Nah, I'm in Pimentel atm, next to Chiclayo, in the North.
I will soon be heading South to Lima, Abancay and Arequipa before hitting
Cuzco. Huacachina sounds fun, maybe I'll do a detour, thanks for sharing!

Ok, let's try to not get any more OT... bring on Voodoo!!

On 12 March 2014 14:34, Ahmidou Lyazidi  wrote:

> Are you in Huacacina? I loved my trip to Peru, it's one of my prefered
> place in the world !
>

-- 
Christopher Crouzet
*http://christophercrouzet.com* <http://christophercrouzet.com>

Re: Softimage Has Been Killed, the Future of CG Softwares Is Now in TD's Hands

Well, I've literally been in the middle of nowhere for 6 weeks now. I'm
surrounded with desert, and there's nothing to do over here. But that's
cool, it gives me time to do my stuff and raise my voice when not fighting
with the internet connection! :)

Can't wait to see what you'll come up with with Fabric!



On 12 March 2014 13:01, Jeremie Passerin  wrote:

> Christopher : I have never seen you more active on the web than those
> days... don't you have to visit the country or something ? I thought you
> were on vacation ;-)
>
>
> On 12 March 2014 10:59, Jeremie Passerin  wrote:
>
>> Yep I can really imagine that you must have been thru a lot of convincing
>> to finally get your foot in a place. Took you what ? 2 years ? I expect the
>> same for Vodoo.. if they indeed succeed... it won't be before a couple of
>> years.
>>
>> I'm learning seriously Fabric now because I can't imagine myself just
>> switching to Maya... even if it's probably going to be the case, I want at
>> least to spice it up with something good. And with the SceneGraph 2.0, it
>> sounds that it could be a first step before moving to 100% Fabric.
>>
>>
>> On 12 March 2014 10:51, Paul Doyle  wrote:
>>
>>> Now we have a global site license with MPC  it is a lot easier to cover
>>> that kind of concern. It is certainly hard at first and you have to do a
>>> lot of convincing - we'll be eternally grateful to the guys at Hybride for
>>> jumping in and being the people that really went for it first. My view
>>> though is that if everyone just waits then you can guarantee that there'll
>>> be no change - we structure our deals in a way that gives people confidence
>>> over the long-term.
>>>
>>> I'm going to talk about some stuff soon that relates to this same idea
>>> of studios and individuals asserting more control over the destiny of their
>>> tools.
>>>
>>>
>>> On 12 March 2014 13:46, Jeremie Passerin  wrote:
>>>
>>>> My problem with R&H software (Vodoo) is, can we trust them to do
>>>> support ?
>>>> R&H is not in a good shape and they want to sell their software..
>>>> good.. but what if it fails and they decide to stop support after a year or
>>>> two. They don't really have a foot in that buisness yet so it sounds risky.
>>>> A lot of people thought or maybe still think the same of Fabric. It
>>>> sounds risky to be the first user of a new software, you got no idea if it
>>>> will actually be popular or not.
>>>> Otherwise no doubt that it is an awesome software but quality isn't the
>>>> only thing that drive the decision to adopt a package.
>>>>
>>>> Christopher if you haven't seen the demo video , it's right there :
>>>> http://rhythm.com/labs/
>>>>
>>>>
>>>> On 12 March 2014 10:26, Christopher Crouzet <
>>>> christopher.crou...@gmail.com> wrote:
>>>>
>>>>> Hopefully they'll announce something soon enough if they want to grab
>>>>> the attention of Softimage users before they jump onto another ship.
>>>>>
>>>>>
>>>>>
>>>>> On 12 March 2014 12:20, Christopher Crouzet <
>>>>> christopher.crou...@gmail.com> wrote:
>>>>>
>>>>>> That would indeed be a great news! A software fine-tuned for years by
>>>>>> its own users on intense productions can only be welcomed.
>>>>>> I'm just wondering how they're planning to grab some market from Maya
>>>>>> though. Would their credibility be enough for some to make a transition
>>>>>> from Autodesk?
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 12 March 2014 12:02, Paul Doyle  wrote:
>>>>>>
>>>>>>> Yes it was Brad, but he doesn't know anything more than what he said
>>>>>>> in his post. From what I read on the Voodoo webpage it seems like 
>>>>>>> they're
>>>>>>> trying to make it work for Prana first.
>>>>>>>
>>>>>>> I'm guessing here, but I suppose if that goes well then much of the
>>>>>>> work to make Voodoo more generic would be done and it would be closer 
>>>>>>> to a
>>>>>>> commercial product. It could be quite awesome to have a new DCC on the
&

Re: Softimage Has Been Killed, the Future of CG Softwares Is Now in TD's Hands

*only saw


On 12 March 2014 12:58, Christopher Crouzet
wrote:

> I only some some bits of it but my Peruvian internet connection capting
> the Wi-Fi from 2 buildings away doesn't allow me to check videos :'(
>
>
>  On 12 March 2014 12:46, Jeremie Passerin  wrote:
>
>> My problem with R&H software (Vodoo) is, can we trust them to do support
>> ?
>> R&H is not in a good shape and they want to sell their software.. good..
>> but what if it fails and they decide to stop support after a year or two.
>> They don't really have a foot in that buisness yet so it sounds risky.
>> A lot of people thought or maybe still think the same of Fabric. It
>> sounds risky to be the first user of a new software, you got no idea if it
>> will actually be popular or not.
>> Otherwise no doubt that it is an awesome software but quality isn't the
>> only thing that drive the decision to adopt a package.
>>
>> Christopher if you haven't seen the demo video , it's right there :
>> http://rhythm.com/labs/
>>
>>
>> On 12 March 2014 10:26, Christopher Crouzet <
>> christopher.crou...@gmail.com> wrote:
>>
>>> Hopefully they'll announce something soon enough if they want to grab
>>> the attention of Softimage users before they jump onto another ship.
>>>
>>>
>>>
>>> On 12 March 2014 12:20, Christopher Crouzet <
>>> christopher.crou...@gmail.com> wrote:
>>>
>>>> That would indeed be a great news! A software fine-tuned for years by
>>>> its own users on intense productions can only be welcomed.
>>>> I'm just wondering how they're planning to grab some market from Maya
>>>> though. Would their credibility be enough for some to make a transition
>>>> from Autodesk?
>>>>
>>>>
>>>>
>>>> On 12 March 2014 12:02, Paul Doyle  wrote:
>>>>
>>>>> Yes it was Brad, but he doesn't know anything more than what he said
>>>>> in his post. From what I read on the Voodoo webpage it seems like they're
>>>>> trying to make it work for Prana first.
>>>>>
>>>>> I'm guessing here, but I suppose if that goes well then much of the
>>>>> work to make Voodoo more generic would be done and it would be closer to a
>>>>> commercial product. It could be quite awesome to have a new DCC on the
>>>>> scene - Voodoo looks amazing.
>>>>>
>>>>>
>>>>> On 12 March 2014 12:40, Christopher Crouzet <
>>>>> christopher.crou...@gmail.com> wrote:
>>>>>
>>>>>> Sweet, thanks Paul!
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 12 March 2014 11:36, Paul Doyle  wrote:
>>>>>>
>>>>>>> I just pinged Brad to ask him - I'll let you know if he gets back to
>>>>>>> me (or he may contact you directly)
>>>>>>>
>>>>>>>
>>>>>>> On 12 March 2014 12:33, Christopher Crouzet <
>>>>>>> christopher.crou...@gmail.com> wrote:
>>>>>>>
>>>>>>>> I didn't manage to contact the author yet to check if it was a HOAX
>>>>>>>> or not but check out the comment #2 by Brad Hielbert:
>>>>>>>> "[...] Since their bankruptcy, the new owners are going to be
>>>>>>>> taking R&Hs in house software and making it availbe to the public. IT 
>>>>>>>> is
>>>>>>>> brilliant software that FAR out paces the capabilities of Maya or Max.
>>>>>>>> [...]"
>>>>>>>>
>>>>>>>> Maybe there's hope? Someone here knows the guy to check if he's the
>>>>>>>> actual author of that comment?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 7 March 2014 17:30, Christopher Crouzet <
>>>>>>>> christopher.crou...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Hey Stefan!
>>>>>>>>>
>>>>>>>>> A quickie before I bail on week-end.
>>>>>>>>>
>>>>>>>>> I think that there has been a misunderstanding. I didn't mean to
>>>>>>>>> say that, I was referring to Autodesk not w

Re: Softimage Has Been Killed, the Future of CG Softwares Is Now in TD's Hands

I only some some bits of it but my Peruvian internet connection capting the
Wi-Fi from 2 buildings away doesn't allow me to check videos :'(


On 12 March 2014 12:46, Jeremie Passerin  wrote:

> My problem with R&H software (Vodoo) is, can we trust them to do support ?
> R&H is not in a good shape and they want to sell their software.. good..
> but what if it fails and they decide to stop support after a year or two.
> They don't really have a foot in that buisness yet so it sounds risky.
> A lot of people thought or maybe still think the same of Fabric. It sounds
> risky to be the first user of a new software, you got no idea if it will
> actually be popular or not.
> Otherwise no doubt that it is an awesome software but quality isn't the
> only thing that drive the decision to adopt a package.
>
> Christopher if you haven't seen the demo video , it's right there :
> http://rhythm.com/labs/
>
>
> On 12 March 2014 10:26, Christopher Crouzet  > wrote:
>
>> Hopefully they'll announce something soon enough if they want to grab the
>> attention of Softimage users before they jump onto another ship.
>>
>>
>>
>> On 12 March 2014 12:20, Christopher Crouzet <
>> christopher.crou...@gmail.com> wrote:
>>
>>> That would indeed be a great news! A software fine-tuned for years by
>>> its own users on intense productions can only be welcomed.
>>> I'm just wondering how they're planning to grab some market from Maya
>>> though. Would their credibility be enough for some to make a transition
>>> from Autodesk?
>>>
>>>
>>>
>>> On 12 March 2014 12:02, Paul Doyle  wrote:
>>>
>>>> Yes it was Brad, but he doesn't know anything more than what he said in
>>>> his post. From what I read on the Voodoo webpage it seems like they're
>>>> trying to make it work for Prana first.
>>>>
>>>> I'm guessing here, but I suppose if that goes well then much of the
>>>> work to make Voodoo more generic would be done and it would be closer to a
>>>> commercial product. It could be quite awesome to have a new DCC on the
>>>> scene - Voodoo looks amazing.
>>>>
>>>>
>>>> On 12 March 2014 12:40, Christopher Crouzet <
>>>> christopher.crou...@gmail.com> wrote:
>>>>
>>>>> Sweet, thanks Paul!
>>>>>
>>>>>
>>>>>
>>>>> On 12 March 2014 11:36, Paul Doyle  wrote:
>>>>>
>>>>>> I just pinged Brad to ask him - I'll let you know if he gets back to
>>>>>> me (or he may contact you directly)
>>>>>>
>>>>>>
>>>>>> On 12 March 2014 12:33, Christopher Crouzet <
>>>>>> christopher.crou...@gmail.com> wrote:
>>>>>>
>>>>>>> I didn't manage to contact the author yet to check if it was a HOAX
>>>>>>> or not but check out the comment #2 by Brad Hielbert:
>>>>>>> "[...] Since their bankruptcy, the new owners are going to be taking
>>>>>>> R&Hs in house software and making it availbe to the public. IT is 
>>>>>>> brilliant
>>>>>>> software that FAR out paces the capabilities of Maya or Max. [...]"
>>>>>>>
>>>>>>> Maybe there's hope? Someone here knows the guy to check if he's the
>>>>>>> actual author of that comment?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 7 March 2014 17:30, Christopher Crouzet <
>>>>>>> christopher.crou...@gmail.com> wrote:
>>>>>>>
>>>>>>>> Hey Stefan!
>>>>>>>>
>>>>>>>> A quickie before I bail on week-end.
>>>>>>>>
>>>>>>>> I think that there has been a misunderstanding. I didn't mean to
>>>>>>>> say that, I was referring to Autodesk not wanting to maintain Softimage
>>>>>>>> because it's being costly and they'd rather focus on Maya to the 
>>>>>>>> detriment
>>>>>>>> of each Softimage user. I've updated the line to reflect this, let me 
>>>>>>>> know
>>>>>>>> if it's beter.
>>>>>>>>
>>>>>>>> I totally agree with you when you say that all-rounded

Re: Softimage Has Been Killed, the Future of CG Softwares Is Now in TD's Hands

Hopefully they'll announce something soon enough if they want to grab the
attention of Softimage users before they jump onto another ship.



On 12 March 2014 12:20, Christopher Crouzet
wrote:

> That would indeed be a great news! A software fine-tuned for years by its
> own users on intense productions can only be welcomed.
> I'm just wondering how they're planning to grab some market from Maya
> though. Would their credibility be enough for some to make a transition
> from Autodesk?
>
>
>
> On 12 March 2014 12:02, Paul Doyle  wrote:
>
>> Yes it was Brad, but he doesn't know anything more than what he said in
>> his post. From what I read on the Voodoo webpage it seems like they're
>> trying to make it work for Prana first.
>>
>> I'm guessing here, but I suppose if that goes well then much of the work
>> to make Voodoo more generic would be done and it would be closer to a
>> commercial product. It could be quite awesome to have a new DCC on the
>> scene - Voodoo looks amazing.
>>
>>
>> On 12 March 2014 12:40, Christopher Crouzet <
>> christopher.crou...@gmail.com> wrote:
>>
>>> Sweet, thanks Paul!
>>>
>>>
>>>
>>> On 12 March 2014 11:36, Paul Doyle  wrote:
>>>
>>>> I just pinged Brad to ask him - I'll let you know if he gets back to me
>>>> (or he may contact you directly)
>>>>
>>>>
>>>> On 12 March 2014 12:33, Christopher Crouzet <
>>>> christopher.crou...@gmail.com> wrote:
>>>>
>>>>> I didn't manage to contact the author yet to check if it was a HOAX or
>>>>> not but check out the comment #2 by Brad Hielbert:
>>>>> "[...] Since their bankruptcy, the new owners are going to be taking
>>>>> R&Hs in house software and making it availbe to the public. IT is 
>>>>> brilliant
>>>>> software that FAR out paces the capabilities of Maya or Max. [...]"
>>>>>
>>>>> Maybe there's hope? Someone here knows the guy to check if he's the
>>>>> actual author of that comment?
>>>>>
>>>>>
>>>>>
>>>>> On 7 March 2014 17:30, Christopher Crouzet <
>>>>> christopher.crou...@gmail.com> wrote:
>>>>>
>>>>>> Hey Stefan!
>>>>>>
>>>>>> A quickie before I bail on week-end.
>>>>>>
>>>>>> I think that there has been a misunderstanding. I didn't mean to say
>>>>>> that, I was referring to Autodesk not wanting to maintain Softimage 
>>>>>> because
>>>>>> it's being costly and they'd rather focus on Maya to the detriment of 
>>>>>> each
>>>>>> Softimage user. I've updated the line to reflect this, let me know if 
>>>>>> it's
>>>>>> beter.
>>>>>>
>>>>>> I totally agree with you when you say that all-rounded packages are
>>>>>> not necessarily a bad thing for the smaller shops and the individuals.
>>>>>>
>>>>>> Got to go now, cheers and thank for the comments!
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 7 March 2014 17:09, Stefan Kubicek  wrote:
>>>>>>
>>>>>>>  Hi Christopher,
>>>>>>>
>>>>>>> cice blog post. I can't entirely agree on the allround
>>>>>>> software inevitably being shut down sooner or later because it's hard to
>>>>>>> maintain part though.
>>>>>>> I too feel like it's worth investing into proprietary software to
>>>>>>> minimize the risk  of exposure to third party technology, but there are 
>>>>>>> so
>>>>>>> many people
>>>>>>> that do not write code, hence their own tools, either because they
>>>>>>> can't for time or monetary reasons, or simply because they don't know 
>>>>>>> how
>>>>>>> to.
>>>>>>> These are mainly the single user shows and small shops. They deserve
>>>>>>> a cost-effective solution to their production problems too, and that is
>>>>>>> usually catered for by big, all-in-one CG applications like Max, Maya,
>>>>>>> Softimage, C4D. Yes, there are special-purpose applications like 
>

Re: Softimage Has Been Killed, the Future of CG Softwares Is Now in TD's Hands

That would indeed be a great news! A software fine-tuned for years by its
own users on intense productions can only be welcomed.
I'm just wondering how they're planning to grab some market from Maya
though. Would their credibility be enough for some to make a transition
from Autodesk?


On 12 March 2014 12:02, Paul Doyle  wrote:

> Yes it was Brad, but he doesn't know anything more than what he said in
> his post. From what I read on the Voodoo webpage it seems like they're
> trying to make it work for Prana first.
>
> I'm guessing here, but I suppose if that goes well then much of the work
> to make Voodoo more generic would be done and it would be closer to a
> commercial product. It could be quite awesome to have a new DCC on the
> scene - Voodoo looks amazing.
>
>
> On 12 March 2014 12:40, Christopher Crouzet  > wrote:
>
>> Sweet, thanks Paul!
>>
>>
>>
>> On 12 March 2014 11:36, Paul Doyle  wrote:
>>
>>> I just pinged Brad to ask him - I'll let you know if he gets back to me
>>> (or he may contact you directly)
>>>
>>>
>>> On 12 March 2014 12:33, Christopher Crouzet <
>>> christopher.crou...@gmail.com> wrote:
>>>
>>>> I didn't manage to contact the author yet to check if it was a HOAX or
>>>> not but check out the comment #2 by Brad Hielbert:
>>>> "[...] Since their bankruptcy, the new owners are going to be taking
>>>> R&Hs in house software and making it availbe to the public. IT is brilliant
>>>> software that FAR out paces the capabilities of Maya or Max. [...]"
>>>>
>>>> Maybe there's hope? Someone here knows the guy to check if he's the
>>>> actual author of that comment?
>>>>
>>>>
>>>>
>>>> On 7 March 2014 17:30, Christopher Crouzet <
>>>> christopher.crou...@gmail.com> wrote:
>>>>
>>>>> Hey Stefan!
>>>>>
>>>>> A quickie before I bail on week-end.
>>>>>
>>>>> I think that there has been a misunderstanding. I didn't mean to say
>>>>> that, I was referring to Autodesk not wanting to maintain Softimage 
>>>>> because
>>>>> it's being costly and they'd rather focus on Maya to the detriment of each
>>>>> Softimage user. I've updated the line to reflect this, let me know if it's
>>>>> beter.
>>>>>
>>>>> I totally agree with you when you say that all-rounded packages are
>>>>> not necessarily a bad thing for the smaller shops and the individuals.
>>>>>
>>>>> Got to go now, cheers and thank for the comments!
>>>>>
>>>>>
>>>>>
>>>>> On 7 March 2014 17:09, Stefan Kubicek  wrote:
>>>>>
>>>>>>  Hi Christopher,
>>>>>>
>>>>>> cice blog post. I can't entirely agree on the allround
>>>>>> software inevitably being shut down sooner or later because it's hard to
>>>>>> maintain part though.
>>>>>> I too feel like it's worth investing into proprietary software to
>>>>>> minimize the risk  of exposure to third party technology, but there are 
>>>>>> so
>>>>>> many people
>>>>>> that do not write code, hence their own tools, either because they
>>>>>> can't for time or monetary reasons, or simply because they don't know how
>>>>>> to.
>>>>>> These are mainly the single user shows and small shops. They deserve
>>>>>> a cost-effective solution to their production problems too, and that is
>>>>>> usually catered for by big, all-in-one CG applications like Max, Maya,
>>>>>> Softimage, C4D. Yes, there are special-purpose applications like 
>>>>>> Marvelous
>>>>>> Designer, RealFlow, SpeedTree,etc, but they cover rarely-encountered 
>>>>>> niche
>>>>>> cases, compared to the vast amount of other stuff that is produced
>>>>>> everywhere every day. Imagine you'd have to use one app for modeling,
>>>>>> another for animation, another for simulation, one for hair & fur, 
>>>>>> etc..on
>>>>>> a daily basis and concurrently. And each one had a different interface 
>>>>>> and
>>>>>> required a different way of thinking.
>>>>>&g

Re: Softimage Has Been Killed, the Future of CG Softwares Is Now in TD's Hands

Sweet, thanks Paul!



On 12 March 2014 11:36, Paul Doyle  wrote:

> I just pinged Brad to ask him - I'll let you know if he gets back to me
> (or he may contact you directly)
>
>
> On 12 March 2014 12:33, Christopher Crouzet  > wrote:
>
>> I didn't manage to contact the author yet to check if it was a HOAX or
>> not but check out the comment #2 by Brad Hielbert:
>> "[...] Since their bankruptcy, the new owners are going to be taking R&Hs
>> in house software and making it availbe to the public. IT is brilliant
>> software that FAR out paces the capabilities of Maya or Max. [...]"
>>
>> Maybe there's hope? Someone here knows the guy to check if he's the
>> actual author of that comment?
>>
>>
>>
>> On 7 March 2014 17:30, Christopher Crouzet > > wrote:
>>
>>> Hey Stefan!
>>>
>>> A quickie before I bail on week-end.
>>>
>>> I think that there has been a misunderstanding. I didn't mean to say
>>> that, I was referring to Autodesk not wanting to maintain Softimage because
>>> it's being costly and they'd rather focus on Maya to the detriment of each
>>> Softimage user. I've updated the line to reflect this, let me know if it's
>>> beter.
>>>
>>> I totally agree with you when you say that all-rounded packages are not
>>> necessarily a bad thing for the smaller shops and the individuals.
>>>
>>> Got to go now, cheers and thank for the comments!
>>>
>>>
>>>
>>> On 7 March 2014 17:09, Stefan Kubicek  wrote:
>>>
>>>>  Hi Christopher,
>>>>
>>>> cice blog post. I can't entirely agree on the allround
>>>> software inevitably being shut down sooner or later because it's hard to
>>>> maintain part though.
>>>> I too feel like it's worth investing into proprietary software to
>>>> minimize the risk  of exposure to third party technology, but there are so
>>>> many people
>>>> that do not write code, hence their own tools, either because they
>>>> can't for time or monetary reasons, or simply because they don't know how
>>>> to.
>>>> These are mainly the single user shows and small shops. They deserve a
>>>> cost-effective solution to their production problems too, and that is
>>>> usually catered for by big, all-in-one CG applications like Max, Maya,
>>>> Softimage, C4D. Yes, there are special-purpose applications like Marvelous
>>>> Designer, RealFlow, SpeedTree,etc, but they cover rarely-encountered niche
>>>> cases, compared to the vast amount of other stuff that is produced
>>>> everywhere every day. Imagine you'd have to use one app for modeling,
>>>> another for animation, another for simulation, one for hair & fur, etc..on
>>>> a daily basis and concurrently. And each one had a different interface and
>>>> required a different way of thinking.
>>>> If you were working in a department and working with one of those, that
>>>> would be a different thing, but constantly jumping between those apps, and
>>>> having to transfer data between them, would soon drive you crazy. It's for
>>>> this reason everybody I have ever met in this industry was searching for
>>>> the one tool to rule them all. Even Lightwave, that consists of only two
>>>> parts (modeler and layout), can drive you nuts.
>>>> Modern software is modular, I think it's well possible to maintain and
>>>> improve it, even change the paradigms it's built on, it just needs a bit of
>>>> forward thinking and the will to do it. I remember stories about whole
>>>> parts of Soft having been rewritten when the old one turned out to be
>>>> insufficiently designed (the animation mixer in particular), I'm not sure
>>>> in how far this is really true, or if it was only marketing blurb.
>>>>
>>>> What I can imagine is a Fabric-based host application which others can
>>>> interface with to form a consistent application as demand arises,
>>>> the hard part will be to draw the line between Fabric Engine, this base
>>>> application (done by somebody else?), and the actual modules, yet done by
>>>> others, and agreeing on a standard that those developers are willing to
>>>> agree on and don't feel hindered by, as it's frequently the case with
>>>> complex APIs that are lacking the one but cruc

Re: Softimage Has Been Killed, the Future of CG Softwares Is Now in TD's Hands

I didn't manage to contact the author yet to check if it was a HOAX or not
but check out the comment #2 by Brad Hielbert:
"[...] Since their bankruptcy, the new owners are going to be taking R&Hs
in house software and making it availbe to the public. IT is brilliant
software that FAR out paces the capabilities of Maya or Max. [...]"

Maybe there's hope? Someone here knows the guy to check if he's the actual
author of that comment?



On 7 March 2014 17:30, Christopher Crouzet wrote:

> Hey Stefan!
>
> A quickie before I bail on week-end.
>
> I think that there has been a misunderstanding. I didn't mean to say that,
> I was referring to Autodesk not wanting to maintain Softimage because it's
> being costly and they'd rather focus on Maya to the detriment of each
> Softimage user. I've updated the line to reflect this, let me know if it's
> beter.
>
> I totally agree with you when you say that all-rounded packages are not
> necessarily a bad thing for the smaller shops and the individuals.
>
> Got to go now, cheers and thank for the comments!
>
>
>
> On 7 March 2014 17:09, Stefan Kubicek  wrote:
>
>>  Hi Christopher,
>>
>> cice blog post. I can't entirely agree on the allround
>> software inevitably being shut down sooner or later because it's hard to
>> maintain part though.
>> I too feel like it's worth investing into proprietary software to
>> minimize the risk  of exposure to third party technology, but there are so
>> many people
>> that do not write code, hence their own tools, either because they can't
>> for time or monetary reasons, or simply because they don't know how to.
>> These are mainly the single user shows and small shops. They deserve a
>> cost-effective solution to their production problems too, and that is
>> usually catered for by big, all-in-one CG applications like Max, Maya,
>> Softimage, C4D. Yes, there are special-purpose applications like Marvelous
>> Designer, RealFlow, SpeedTree,etc, but they cover rarely-encountered niche
>> cases, compared to the vast amount of other stuff that is produced
>> everywhere every day. Imagine you'd have to use one app for modeling,
>> another for animation, another for simulation, one for hair & fur, etc..on
>> a daily basis and concurrently. And each one had a different interface and
>> required a different way of thinking.
>> If you were working in a department and working with one of those, that
>> would be a different thing, but constantly jumping between those apps, and
>> having to transfer data between them, would soon drive you crazy. It's for
>> this reason everybody I have ever met in this industry was searching for
>> the one tool to rule them all. Even Lightwave, that consists of only two
>> parts (modeler and layout), can drive you nuts.
>> Modern software is modular, I think it's well possible to maintain and
>> improve it, even change the paradigms it's built on, it just needs a bit of
>> forward thinking and the will to do it. I remember stories about whole
>> parts of Soft having been rewritten when the old one turned out to be
>> insufficiently designed (the animation mixer in particular), I'm not sure
>> in how far this is really true, or if it was only marketing blurb.
>>
>> What I can imagine is a Fabric-based host application which others can
>> interface with to form a consistent application as demand arises,
>> the hard part will be to draw the line between Fabric Engine, this base
>> application (done by somebody else?), and the actual modules, yet done by
>> others, and agreeing on a standard that those developers are willing to
>> agree on and don't feel hindered by, as it's frequently the case with
>> complex APIs that are lacking the one but crucial feature X for which you
>> have to wait a full year until the next release to have it implemented
>> after kindly asking the developers several times. I'm not saying it's not
>> doable, just not entirely easy. I'm not saying small standalone apps are
>> not desirable either, I just think they make more sense for special
>> purposes rather than for standard stuff, unless the standard stuff they do
>> is done in a true, outstandingly nice new way.
>>
>>
>>
>> Your 2 cents will worth a few bitcoins quickly Christopher. I'm in.
>>
>>
>> On Fri, Mar 7, 2014 at 9:34 PM, Christopher Crouzet <
>> christopher.crou...@gmail.com> wrote:
>>
>>> My 2 cents on this:
>>> http://christophercrouzet.com/blog/post/2014/03/07/Softimage-Has-Bee

Re: Softimage Has Been Killed, the Future of CG Softwares Is Now in TD's Hands

Hey Stefan!

A quickie before I bail on week-end.

I think that there has been a misunderstanding. I didn't mean to say that,
I was referring to Autodesk not wanting to maintain Softimage because it's
being costly and they'd rather focus on Maya to the detriment of each
Softimage user. I've updated the line to reflect this, let me know if it's
beter.

I totally agree with you when you say that all-rounded packages are not
necessarily a bad thing for the smaller shops and the individuals.

Got to go now, cheers and thank for the comments!



On 7 March 2014 17:09, Stefan Kubicek  wrote:

>  Hi Christopher,
>
> cice blog post. I can't entirely agree on the allround software inevitably
> being shut down sooner or later because it's hard to maintain part though.
> I too feel like it's worth investing into proprietary software to minimize
> the risk  of exposure to third party technology, but there are so many
> people
> that do not write code, hence their own tools, either because they can't
> for time or monetary reasons, or simply because they don't know how to.
> These are mainly the single user shows and small shops. They deserve a
> cost-effective solution to their production problems too, and that is
> usually catered for by big, all-in-one CG applications like Max, Maya,
> Softimage, C4D. Yes, there are special-purpose applications like Marvelous
> Designer, RealFlow, SpeedTree,etc, but they cover rarely-encountered niche
> cases, compared to the vast amount of other stuff that is produced
> everywhere every day. Imagine you'd have to use one app for modeling,
> another for animation, another for simulation, one for hair & fur, etc..on
> a daily basis and concurrently. And each one had a different interface and
> required a different way of thinking.
> If you were working in a department and working with one of those, that
> would be a different thing, but constantly jumping between those apps, and
> having to transfer data between them, would soon drive you crazy. It's for
> this reason everybody I have ever met in this industry was searching for
> the one tool to rule them all. Even Lightwave, that consists of only two
> parts (modeler and layout), can drive you nuts.
> Modern software is modular, I think it's well possible to maintain and
> improve it, even change the paradigms it's built on, it just needs a bit of
> forward thinking and the will to do it. I remember stories about whole
> parts of Soft having been rewritten when the old one turned out to be
> insufficiently designed (the animation mixer in particular), I'm not sure
> in how far this is really true, or if it was only marketing blurb.
>
> What I can imagine is a Fabric-based host application which others can
> interface with to form a consistent application as demand arises,
> the hard part will be to draw the line between Fabric Engine, this base
> application (done by somebody else?), and the actual modules, yet done by
> others, and agreeing on a standard that those developers are willing to
> agree on and don't feel hindered by, as it's frequently the case with
> complex APIs that are lacking the one but crucial feature X for which you
> have to wait a full year until the next release to have it implemented
> after kindly asking the developers several times. I'm not saying it's not
> doable, just not entirely easy. I'm not saying small standalone apps are
> not desirable either, I just think they make more sense for special
> purposes rather than for standard stuff, unless the standard stuff they do
> is done in a true, outstandingly nice new way.
>
>
>
> Your 2 cents will worth a few bitcoins quickly Christopher. I'm in.
>
>
> On Fri, Mar 7, 2014 at 9:34 PM, Christopher Crouzet <
> christopher.crou...@gmail.com> wrote:
>
>> My 2 cents on this:
>> http://christophercrouzet.com/blog/post/2014/03/07/Softimage-Has-Been-Killed%2C-the-Future-of-CG-Softwares-Is-Now-in-TD-s-Hands
>>
>> I'm looking forward to the future, how about you?
>>
>>
>> --
>> Christopher Crouzet
>> *http://christophercrouzet.com* <http://christophercrouzet.com>
>>
>>
>
>
>
> --
> ---
> Stefan Kubicek
> ---
> keyvis digital imagery
> Alfred Feierfeilstraße 3
> A-2380 Perchtoldsdorf bei Wien
> Phone: +43/699/12614231
> www.keyvis.at ste...@keyvis.at
> -- This email and its attachments are --
> --confidential and for the recipient only--
>



-- 
Christopher Crouzet
*http://christophercrouzet.com* <http://christophercrouzet.com>

Softimage Has Been Killed, the Future of CG Softwares Is Now in TD's Hands

My 2 cents on this:
http://christophercrouzet.com/blog/post/2014/03/07/Softimage-Has-Been-Killed%2C-the-Future-of-CG-Softwares-Is-Now-in-TD-s-Hands

I'm looking forward to the future, how about you?


-- 
Christopher Crouzet
*http://christophercrouzet.com* <http://christophercrouzet.com>

Re: Maya feature request from Softimage users

And I believe you're breaking the NDA here?



On 7 March 2014 12:47, Nic Sievers  wrote:

> I believe Maya 2015 adds a new unfold3D tool...
>
>
> On Fri, Mar 7, 2014 at 9:37 AM, Manuel Huertas Marchena <
> lito...@hotmail.com> wrote:
>
>> uv unfold please!!
>>
>> ...really dont like maya uv's tools!
>>
>>
>>
>> IMDB <http://www.imdb.com/name/nm4755969/> | Portfolio
>> <http://envmanu.com> <http://envmanu.carbonmade.com/>| 
>> Vimeo<http://vimeo.com/manuelhuertasmarchena>|
>> Linkedin <http://www.linkedin.com/in/manuelhuertas>
>>
>>
>> --
>> Date: Fri, 7 Mar 2014 17:30:22 +
>> Subject: Re: Maya feature request from Softimage users
>> From: sebastien.sterl...@gmail.com
>> To: softimage@listproc.autodesk.com
>>
>>
>> the ability to show/hide components, like in every other DCC ever made.
>>
>> the ability to relax selections of polygons edges and vertexes.
>>
>> neither of these should prove to be too difficult... baby steps
>>
>>
>> On 7 March 2014 17:23, Oscar Juarez  wrote:
>>
>> You nailed right there Jeremie, basically being flexible when rigging,
>> every day I go splitting geometry, regatoring meshes, and merging again,
>> transfering everything seamlessly.
>>
>> Multi attribute editor, it's really stupid that when you select multiple
>> things you only see one at a time in the attribute editor, there is the
>> spreadsheet editor but that sucks in comparison.
>>
>>
>> On Fri, Mar 7, 2014 at 6:11 PM, Jason S  wrote:
>>
>>  Maya 2039 (rewritten)
>>
>> On 03/07/14 12:06, Mirko Jankovic wrote:
>>
>> stable non destructive workflow
>>
>>
>>
>>
>>
>


-- 
Christopher Crouzet
*http://christophercrouzet.com* <http://christophercrouzet.com>

Re: Maya feature request from Softimage users

When I had to move over to Maya, Gator, ICE, the weights painting tool and
the Weights Editor were definitely the most missed.
So missed that I would prototype deformers in ICE and convert them in code
for Maya. I also wrote a small workflow to allow me to paint the weights
and to model corrective shapes in Softimage, to then import them back in
Maya.

But for the operator stack, I don't think you'll be able to get a such
thing. There's actually one UI that shows an operator stack in Maya with
the possibility to reorder deformers but it is more a failed attempt than a
proper working tool. And I'm not even sure if it would work out with the
nodal structure that Maya relies on.

As for changing the model in a rig, it is just a node to update. So
theorically it's simple but of course it breaks all the deformers applied
to it. Hence the need like in every software that I know of to have a clean
workflow to easily export/import/convert mesh attributes. Or maybe have I
already forgot how Softimage works? :)

On 7 March 2014 11:59, Jeremie Passerin  wrote:

> Hey guys...
>
> What do you want to see added to Maya ?
> Autodesk is saying they will add Softimage features to the other
> packages... What is that ?
>
> As a Rigger, here is what I will miss the most
>
> - Gator
> - ICE : Especially to create custom deformers
> - Proper weights painting tools
> - Weights Editor !
> - The Operator Stack, reorder, delete operator...
> - Being able to change modeling whith Envelope, Shapes already applied to
> the mesh
> - Blend shape workflow
>
> I would really like to hear Autodesk plan to incorporate some of those
> features in Maya.
> I'm guessing there not all super easy to merge, but some of them would be
> considered as amazing new feature by the Maya users.
>
> J/
>

-- 
Christopher Crouzet
*http://christophercrouzet.com* <http://christophercrouzet.com>

Re: Softimage 2015 Last Release Announcement

That video is gold!
He actually seems disturbed... like if he knew that he was lying. Could
totally be used as an animation reference!



On 4 March 2014 16:08, Steven Caron  wrote:

> he looked nervous...
>
>
> On Tue, Mar 4, 2014 at 1:01 PM, Dan Yargici  wrote:
>
>> While you try and find it, remind yourself of this little gem from not
>> even a year ago!
>>
>> http://area.autodesk.com/2014unfold/products/softimage.html#future
>>
>>
>>


-- 
Christopher Crouzet
*http://christophercrouzet.com* <http://christophercrouzet.com>

Re: I'm sure this is one of many...

Indeed! :)

Thanks for removing the signature!



On 4 March 2014 11:12, Emilio Hernandez  wrote:

> Good thing is that we all are different.  Don't you think?
>
>
> 2014-03-04 10:10 GMT-06:00 Emilio Hernandez :
>
> I respect your point of view.
>>
>>
>>
>>
>> 2014-03-04 10:07 GMT-06:00 Christopher Crouzet <
>> christopher.crou...@gmail.com>:
>>
>>> While we're there, can you please remove your massive signature too?
>>> It's both poorly designed (big images, text difficult to read) and annoying.
>>> If you were trying to give a professional look to your email with those,
>>> it's a miss, sorry.
>>>
>>>
>>>
>>> On 4 March 2014 10:54, Dan Yargici  wrote:
>>>
>>>> E, can you stop doing this now Emilio, it's really annoying...
>>>>
>>>>
>>>> On Tue, Mar 4, 2014 at 5:48 PM, Emilio Hernandez wrote:
>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 2014-03-04 9:30 GMT-06:00 Arvid Björn :
>>>>>
>>>>> That was truly depressing. I was nodding in agreement, but I didn't
>>>>>> smile. =/
>>>>>>
>>>>>> The 2 pieces of software that I've truly enjoyed working with, Shake
>>>>>> and Soft, both buried by suits trying to cover their asses.
>>>>>>
>>>>>> How can you own something, yet be unable to appreciate its value?
>>>>>> Surely there must be a more lucrative use for this technology they stole 
>>>>>> so
>>>>>> cheaply only a few years back.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Mar 4, 2014 at 3:28 PM, Ed Manning wrote:
>>>>>>
>>>>>>> ttps://www.youtube.com/watch?v=1r77WyKNsIk<https://www.youtube.com/watch?v=1r77WyKNsIk>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Christopher Crouzet
>>> *http://christophercrouzet.com* <http://christophercrouzet.com>
>>>
>>>
>>
>


-- 
Christopher Crouzet
*http://christophercrouzet.com* <http://christophercrouzet.com>

Re: I'm sure this is one of many...

Wow, I wouldn't like to be you. Life sounds hard when all of it seems to
gravitate around a software.
Good luck!



On 4 March 2014 11:04, Emilio Hernandez  wrote:

> What is really annoying is that we complain, and complain and do nothing
> about it really.
>
> Some of us have the chance to stick with Softimage forever until something
> really better comes out.
>
> Some of us in the need of no finding jobs will have to switch to Maya for
> a "serious film work" studio for hire.
>
> Some of us will have to start evaluating the options of other softwares
> and grab not only one, but two or three to work the way we do.
>
> ADSK is not only retiring Softimage. It is attempting against our way of
> life, the way we work, the way we think, the way we create things, and the
> way we do business.
>
> That is really annoying.
>
>
>
>
>
>
>
>
> 2014-03-04 9:54 GMT-06:00 Dan Yargici :
>
> E, can you stop doing this now Emilio, it's really annoying...
>>
>>
>> On Tue, Mar 4, 2014 at 5:48 PM, Emilio Hernandez wrote:
>>
>>>
>>>
>>>
>>>
>>>
>>> 2014-03-04 9:30 GMT-06:00 Arvid Björn :
>>>
>>> That was truly depressing. I was nodding in agreement, but I didn't
>>>> smile. =/
>>>>
>>>> The 2 pieces of software that I've truly enjoyed working with, Shake
>>>> and Soft, both buried by suits trying to cover their asses.
>>>>
>>>> How can you own something, yet be unable to appreciate its value?
>>>> Surely there must be a more lucrative use for this technology they stole so
>>>> cheaply only a few years back.
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Mar 4, 2014 at 3:28 PM, Ed Manning  wrote:
>>>>
>>>>> ttps://www.youtube.com/watch?v=1r77WyKNsIk<https://www.youtube.com/watch?v=1r77WyKNsIk>
>>>>>
>>>>
>>>>
>>>
>>
>


-- 
Christopher Crouzet
*http://christophercrouzet.com* <http://christophercrouzet.com>

Re: I'm sure this is one of many...

While we're there, can you please remove your massive signature too? It's
both poorly designed (big images, text difficult to read) and annoying.
If you were trying to give a professional look to your email with those,
it's a miss, sorry.



On 4 March 2014 10:54, Dan Yargici  wrote:

> E, can you stop doing this now Emilio, it's really annoying...
>
>
> On Tue, Mar 4, 2014 at 5:48 PM, Emilio Hernandez wrote:
>
>>
>>
>>
>>
>>
>> 2014-03-04 9:30 GMT-06:00 Arvid Björn :
>>
>> That was truly depressing. I was nodding in agreement, but I didn't
>>> smile. =/
>>>
>>> The 2 pieces of software that I've truly enjoyed working with, Shake and
>>> Soft, both buried by suits trying to cover their asses.
>>>
>>> How can you own something, yet be unable to appreciate its value? Surely
>>> there must be a more lucrative use for this technology they stole so
>>> cheaply only a few years back.
>>>
>>>
>>>
>>>
>>> On Tue, Mar 4, 2014 at 3:28 PM, Ed Manning  wrote:
>>>
>>>> ttps://www.youtube.com/watch?v=1r77WyKNsIk<https://www.youtube.com/watch?v=1r77WyKNsIk>
>>>>
>>>
>>>
>>
>


-- 
Christopher Crouzet
*http://christophercrouzet.com* <http://christophercrouzet.com>

Re: Non-spherical eye while keeping iris circular

2013-11-18 Thread Christopher Crouzet

Hey Enrique! :)

An idea could be to fit a NURBS sphere to the shape of your outer eye, then
use it to constrain the deformers onto its surface, and finally slide those
deformrs using UV coordinates.

I did something like that a whle ago: http://vimeo.com/2466613
In this video the eyes are spherical but they definitely could be anything
else.



On 18 November 2013 11:56, Enrique Caballero wrote:

> hey oliver,
>   Thanks for the reply, that would work if the pupil was a separate piece
> of geometry and is exactly how i do it on other characters.
>
> Sorry I should have been more specific.
>
> Basically I'm trying to make the Pixar eyes.  Where the iris is cut into
> the eyewhite, and actually goes inside of it.  This one i have not been
> able to figure out for a while.
>
>
>
> On Mon, Nov 18, 2013 at 6:51 PM, olivier jeannel 
> wrote:
>
>> I'm not a specialist in toon, but I would keep the Lattice on the Eye
>> (the white deformed sphere) and make a separate Iris object that would be
>> "shrinkwarped" on it. So that the Roundness of the Iris wouldn't be
>> affected by the stretch of the global eye.
>> Maybe a ClosestLocation in Ice would give even more control and speed...
>>
>>
>> Le 18/11/2013 10:58, Enrique Caballero a écrit :
>>
>>  Hey everyone,
>>>   Does anyone have any tips on how to rig a non spherical eye while
>>> maintaining a perfectly circular iris?
>>>
>>> I have done it in the past with starting with a spherical eye, using a
>>> lattice to deform it and then using blendshapes to counter the squashing
>>> effect on the iris. But this method is clunky and you can see discrepancies
>>> in the interpolation.
>>>
>>> Any tips would be welcome, this question has bothered me for some time.
>>>
>>> -E
>>>
>>
>>
>

Re: what

2013-10-31 Thread Christopher Crouzet

It's true that the content is not selling it and probably won't attract new
customers not already knowing the value of the product, but for some
reasons I would have think that already existing customers would bypass
that kind of terrible showcase and would trust in the quality of each new
implemented tool since the devs seems to be a serious bunch after all. But
I'm not part of the Houdini's community, so you know better.

That said, I can't remember where I've heard/read that from, and maybe it's
simply my imagination playing me tricks, but aren't those videos being made
by a small team of students hired to come up with a final project that
would showcase the new features? If so, that would explain the quality,
which is fine as soon as everyone knows the reason behind it, and I believe
it would be a great initiative because it would give them the chance to try
out the tools in a production environment, even though it won't be an usage
nearly as intensive as it would be with the big studios. But hey, it would
still be better than simply expecting the pros to beta test the features at
their work place and ask them to send feedbacks when they simply don't have
the time to play around because of their crazy deadlines, no?



On 31 October 2013 00:41, Meng-Yang Lu  wrote:

> You can play around with the content and context of the material.  I don't
> care it's Halloween themed and I think that's totally fine.  It boils down
> to how you execute the concept.  However, you are trying to show me new
> technology cause that's why I wanna upgrade right?  Stuff exploding in the
> sim when Houdini can clearly handle that problem is bad.  Showing the
> Houdini Engine where the sim exploded in the demo video is also bad.  This
> is not clever or ballsy (maybe ballsy is applicable here).  I can't really
> see how the examples I've given could be a good thing.
>
> Houdini is my workhorse on a daily basis.  The quality and robustness of
> any new technology is never proven until it is used in production.  Not
> knocking any of the hard work done by the folks at SESI, but this is
> something the community has felt could be addressed if they simply cared a
> little bit.
>
> -Lu
>
>
> On Wed, Oct 30, 2013 at 3:56 PM, Christopher Crouzet <
> christopher.crou...@gmail.com> wrote:
>
>> I love Houdini and I love the sneak peeks they've been doing for the v13.
>> The quality and the robustness of the software is not to be proved
>> anymore, and seeing them taking the piss of their own features by using
>> self-derision shows that they are also a cool bunch and can have fun,
>> unlike the very formal, serious and boring prejudices that everyone has
>> about them.
>>
>> I think that's a clever approach and it shows that they've got balls to
>> do things unlike almost every other boring sneak peeks out there.
>> And having heard about the quality and friendliness of their dev team, I
>> can only respect this choice even more.
>>
>>
>>
>> On 30 October 2013 23:52, Meng-Yang Lu  wrote:
>>
>>> Both SI and Houdini are amazing kits.  However, one decides not to
>>> market it's strengths or at all while the other fails to do a single bit of
>>> quality check on outgoing material.
>>>
>>> Honestly, I feel bad for the talented RnD staff behind the scenes who
>>> probably worked really hard to get the technology in there only to have it
>>> shat on by people further down the line.  Please, have a little respect and
>>> do them justice for their hard work.
>>>
>>> peace,
>>>
>>> -Lu
>>>
>>>
>>> On Wed, Oct 30, 2013 at 3:36 PM, Eric Lampi  wrote:
>>>
>>>> Oh this is Houdini? I thought it was a demo of a Fallout 3 expansion
>>>> pack ;)
>>>>
>>>> Eric
>>>>
>>>> Freelance 3D and VFX animator
>>>>
>>>> http://vimeopro.com/user7979713/3d-work
>>>>
>>>>
>>>> On Wed, Oct 30, 2013 at 6:25 PM, Meng-Yang Lu wrote:
>>>>
>>>>> Houdini Sneak Peeks are as bad as Autodesk's Marketing from
>>>>> Softimage...
>>>>>
>>>>> Boom.
>>>>>
>>>>> -Lu
>>>>>
>>>>>
>>>>> On Wed, Oct 30, 2013 at 2:58 PM, Ben Rogall <
>>>>> xsi_l...@shaders.moederogall.com> wrote:
>>>>>
>>>>>>  Those mandibles don't seem to be bouncing quite the way real
>>>>>> mandibles bounce.
>>>>>>
>>>>>>
&g

Re: what

2013-10-30 Thread Christopher Crouzet

To unsubscribe: mail softimage-requ...@listproc.autodesk.com with subject
"unsubscribe" and reply to the confirmation email.



On 30 October 2013 23:56, Mc Nistor  wrote:

> If by now you didn't figure that I'm new on this platform, well... I'm new
> to this platform so can someone please tell me how do I disable these email
> notifications I get whenever someone replies?
> I didn't find anything in my account settings. Am I missing something?
>
>
> On Thu, Oct 31, 2013 at 12:52 AM, Meng-Yang Lu  wrote:
>
>> Both SI and Houdini are amazing kits.  However, one decides not to market
>> it's strengths or at all while the other fails to do a single bit of
>> quality check on outgoing material.
>>
>> Honestly, I feel bad for the talented RnD staff behind the scenes who
>> probably worked really hard to get the technology in there only to have it
>> shat on by people further down the line.  Please, have a little respect and
>> do them justice for their hard work.
>>
>> peace,
>>
>> -Lu
>>
>>
>> On Wed, Oct 30, 2013 at 3:36 PM, Eric Lampi  wrote:
>>
>>> Oh this is Houdini? I thought it was a demo of a Fallout 3 expansion
>>> pack ;)
>>>
>>> Eric
>>>
>>> Freelance 3D and VFX animator
>>>
>>> http://vimeopro.com/user7979713/3d-work
>>>
>>>
>>> On Wed, Oct 30, 2013 at 6:25 PM, Meng-Yang Lu wrote:
>>>
 Houdini Sneak Peeks are as bad as Autodesk's Marketing from Softimage...

 Boom.

 -Lu


 On Wed, Oct 30, 2013 at 2:58 PM, Ben Rogall <
 xsi_l...@shaders.moederogall.com> wrote:

>  Those mandibles don't seem to be bouncing quite the way real
> mandibles bounce.
>
>
> On 10/30/2013 4:45 PM, Mc Nistor wrote:
>
> "by the way", sneak peak #3 fro SideFX is up
> https://vimeo.com/78203795
> :)
>
>
> On Wed, Oct 30, 2013 at 11:39 PM, Mc Nistor  wrote:
>
>> That's great, I have all that is needed then, no need for
>> computer/internet. ;)
>>
>>
>> On Wed, Oct 30, 2013 at 11:37 PM, Eric Lampi wrote:
>>
>>>  You need a la bit of string, a bottle of molasses, some pocket
>>> lint from a priest, a handful of roofing nails, 2 slinkys, a wombat and
>>> build a bonfire built at a crossroads by the light of the full moon.
>>>
>>>  Or a computer with an internet connection.
>>>
>>> Freelance 3D and VFX animator
>>>
>>> http://vimeopro.com/user7979713/3d-work
>>>
>>>
>>>  On Wed, Oct 30, 2013 at 5:30 PM, Mc Nistor wrote:
>>>
  OOOK
  I think I got it. How do I unsubscribe from this list?


  On Wed, Oct 30, 2013 at 11:22 PM, David Barosin <
 dbaro...@gmail.com> wrote:

>  we can hear you ;)
>
>
>  On Wed, Oct 30, 2013 at 5:20 PM, Mc Nistor wrote:
>
>>  I don't understand how this works... where am I posting?!
>>  google is getting more and more retarded
>>
>
>

>>>
>>
>
>

>>>
>>
>

Re: what

2013-10-30 Thread Christopher Crouzet

I love Houdini and I love the sneak peeks they've been doing for the v13.
The quality and the robustness of the software is not to be proved anymore,
and seeing them taking the piss of their own features by using
self-derision shows that they are also a cool bunch and can have fun,
unlike the very formal, serious and boring prejudices that everyone has
about them.

I think that's a clever approach and it shows that they've got balls to do
things unlike almost every other boring sneak peeks out there.
And having heard about the quality and friendliness of their dev team, I
can only respect this choice even more.



On 30 October 2013 23:52, Meng-Yang Lu  wrote:

> Both SI and Houdini are amazing kits.  However, one decides not to market
> it's strengths or at all while the other fails to do a single bit of
> quality check on outgoing material.
>
> Honestly, I feel bad for the talented RnD staff behind the scenes who
> probably worked really hard to get the technology in there only to have it
> shat on by people further down the line.  Please, have a little respect and
> do them justice for their hard work.
>
> peace,
>
> -Lu
>
>
> On Wed, Oct 30, 2013 at 3:36 PM, Eric Lampi  wrote:
>
>> Oh this is Houdini? I thought it was a demo of a Fallout 3 expansion pack
>> ;)
>>
>> Eric
>>
>> Freelance 3D and VFX animator
>>
>> http://vimeopro.com/user7979713/3d-work
>>
>>
>> On Wed, Oct 30, 2013 at 6:25 PM, Meng-Yang Lu  wrote:
>>
>>> Houdini Sneak Peeks are as bad as Autodesk's Marketing from Softimage...
>>>
>>> Boom.
>>>
>>> -Lu
>>>
>>>
>>> On Wed, Oct 30, 2013 at 2:58 PM, Ben Rogall <
>>> xsi_l...@shaders.moederogall.com> wrote:
>>>
  Those mandibles don't seem to be bouncing quite the way real
 mandibles bounce.


 On 10/30/2013 4:45 PM, Mc Nistor wrote:

 "by the way", sneak peak #3 fro SideFX is up
 https://vimeo.com/78203795
 :)


 On Wed, Oct 30, 2013 at 11:39 PM, Mc Nistor  wrote:

> That's great, I have all that is needed then, no need for
> computer/internet. ;)
>
>
> On Wed, Oct 30, 2013 at 11:37 PM, Eric Lampi wrote:
>
>>  You need a la bit of string, a bottle of molasses, some pocket lint
>> from a priest, a handful of roofing nails, 2 slinkys, a wombat and build 
>> a
>> bonfire built at a crossroads by the light of the full moon.
>>
>>  Or a computer with an internet connection.
>>
>> Freelance 3D and VFX animator
>>
>> http://vimeopro.com/user7979713/3d-work
>>
>>
>>  On Wed, Oct 30, 2013 at 5:30 PM, Mc Nistor wrote:
>>
>>>  OOOK
>>>  I think I got it. How do I unsubscribe from this list?
>>>
>>>
>>>  On Wed, Oct 30, 2013 at 11:22 PM, David Barosin >> > wrote:
>>>
  we can hear you ;)


  On Wed, Oct 30, 2013 at 5:20 PM, Mc Nistor wrote:

>  I don't understand how this works... where am I posting?!
>  google is getting more and more retarded
>


>>>
>>
>


>>>
>>
>

Re: File size limit?

2013-10-11 Thread Christopher Crouzet

I would totally go on strike if I had to deal with a 2GB environment within
a single scene!


On 10 October 2013 23:21, Raffaele Fragapane wrote:

> Plenty cases, such as environment bakes with multiple passes and complex
> geo, where the 2GB limit is crippling and referencing is a workaround and
> not just a smarter way to go about it.
> It's kinda silly that this type of limitation is still around, and
> generally so common.
>
>
> On Fri, Oct 11, 2013 at 2:23 AM, Christopher Crouzet <
> christopher.crou...@gmail.com> wrote:
>
>> At first glance, saving 2GB of data into a single scene doesn't sound
>> like a good practice anyways... can't you offload some logical pieces using
>> referenced models?
>>
>>
>>
>> On 10 October 2013 16:50, Sergio Mucino wrote:
>>
>>>  Thanks a lot guys! Tough luck... we're on 2012...
>>>
>>>
>>> *Sergio Mucino*
>>> Lead Rigger
>>> Modus FX
>>>
>>> On 10/10/2013 10:46 AM, Srecko Micic wrote:
>>>
>>> There was limitation like that but on 2014 version is now 4gb I think
>>> (on Linux it is still  2GB limit).
>>>
>>>
>>> On Thu, Oct 10, 2013 at 4:35 PM, Sergio Mucino <
>>> sergio.muc...@modusfx.com> wrote:
>>>
>>>>  Hello everyone. I just wanted to know if it's true that SI files have
>>>> a size limit. I'm working on a file I cannot save. Every time I try to,
>>>> Softimage tells me that certain elements were not saved, and that I should
>>>> contact Softimage. If I try to open said fail, SI crashes almost
>>>> immediately. People here at work are telling me that apparently, SI cannot
>>>> save/load files over 2 GB. I just wanted to confirm this is true so I can
>>>> take appropriate actions. Thanks!
>>>>
>>>> --
>>>> *Sergio Mucino*
>>>> Lead Rigger
>>>> Modus FX
>>>>
>>>
>>>
>>>
>>>  --
>>> Micic Srecko
>>> ---
>>> Mail:
>>> srecko.mi...@gmail.com
>>> Skype:srecko.micic
>>> ---
>>> 3D/Graphic Portfolio:
>>> http://www.coroflot.com/SreckoM
>>>
>>>
>>
>
>
> --
> Our users will know fear and cower before our software! Ship it! Ship it
> and let them flee like the dogs they are!
>

Re: Unofficial Softimage user voice

While looking for "security" breaches, I might have abused a little bit by
giving 4 votes to the PyQt topic without being logged in... but I won't do
it again, I swear!
That said, I did really wish for that feature a while ago! :)



On 10 October 2013 19:49, Gregory Ducatel  wrote:

> Hi,
>
> First of all, I just double check if there was any voting abuse during
> the first hours when the site was setup to an unlimited voting
> measure. And no, people were not abusive...
>
> Now it is 20 votes/users, I am trying to see how AD can provide
> feedback regarding the status of a suggestion in order to give back
> voting points to the site users and provide a active environment.
>
> Also, if AD is willing to provide me with a list of suggestions and
> requests already in there system, I will be more that happy to add
> those suggestion inside this users voice system so it will be
> accessible for everyone.
>
> Cheers,
>
> Greg
>

Re: File size limit?

What's stopping you from using referenced models within each of your rig? I
can't remember if it's buggy or not to have nested referenced models but
just check how it goes. You could for example put your geo in a model and
reference it within your rig.

On top of that, and if it's not already the case, you'll have a nice
rigging structure where the data (geo) is splitted from the logic (rig).
Exactly like how every respectable piece of code is designed, which makes
it easy to reuse or swap things around.



On 10 October 2013 18:14, Sergio Mucino  wrote:

>  Not really. These are rig files, and have multiple resolutions stored
> inside which are then split by the publishing system. They are not scene
> files (in the traditional sense of the word).
>
>
> *Sergio Mucino*
> Lead Rigger
> Modus FX
>
> On 10/10/2013 11:23 AM, Christopher Crouzet wrote:
>
> At first glance, saving 2GB of data into a single scene doesn't sound like
> a good practice anyways... can't you offload some logical pieces using
> referenced models?
>
>
>
> On 10 October 2013 16:50, Sergio Mucino  wrote:
>
>>  Thanks a lot guys! Tough luck... we're on 2012...
>>
>>
>> *Sergio Mucino*
>> Lead Rigger
>> Modus FX
>>
>>   On 10/10/2013 10:46 AM, Srecko Micic wrote:
>>
>> There was limitation like that but on 2014 version is now 4gb I think (on
>> Linux it is still  2GB limit).
>>
>>
>> On Thu, Oct 10, 2013 at 4:35 PM, Sergio Mucino > > wrote:
>>
>>>  Hello everyone. I just wanted to know if it's true that SI files have a
>>> size limit. I'm working on a file I cannot save. Every time I try to,
>>> Softimage tells me that certain elements were not saved, and that I should
>>> contact Softimage. If I try to open said fail, SI crashes almost
>>> immediately. People here at work are telling me that apparently, SI cannot
>>> save/load files over 2 GB. I just wanted to confirm this is true so I can
>>> take appropriate actions. Thanks!
>>>
>>> --
>>> *Sergio Mucino*
>>> Lead Rigger
>>> Modus FX
>>>
>>
>>
>>
>>  --
>> Micic Srecko
>> ---
>> Mail:
>> srecko.mi...@gmail.com
>> Skype:srecko.micic
>> ---
>> 3D/Graphic Portfolio:
>> http://www.coroflot.com/SreckoM
>>
>>
>

Re: Unofficial Softimage user voice

And also, shouldn't the votes require a proper authentication to make sure
each vote is legit?
Sounds like I can vote as much as I want as anonymous and after clearing
the cache of my browser.

On 10 October 2013 17:23, Luc-Eric Rousseau  wrote:

> on the first day, weren't votes unlimited? What happened to these
> votes after you set the limits?  It is possible that some early
> suggestions have a disproportionate number of votes?
>

Re: File size limit?