Re: Random Thoughts about H.

[Jason S]

  
  
"specially when self employed"
  
  ...  or small ... or big shops delivering sequences of images :)
  
  
  On 03/21/17 22:05, Jason S wrote:


  
  Hi Jordi!

First I wanted to personally thank you for those docs, as they
really did go straight to the crux.

Yet for the points mentioned, I would have an easier time
agreeing with you if indeed I found "some things to be easier,
and others not", whereas beyond what could be associated to "XSI
muscle memory",  the sheer quantity or proportions of things
that are not not just easier, but considerably much (much!)
easier, makes it hard to just overlook and just "go with it",
especially when knowing how things can be.


Especially when what I'm looking for already exists.

I know it takes great effort designing things that are both user
friendly AND very flexible 
(both must be at equal priority upon design phases, otherwise
there is great tendency for becoming mostly an either/or thing,
akin to making things both fast AND high quality) 

I'm not either dismissing it altogether, just that after
witnessing how things are, I would focus on things that are more
accessible, and *perhaps* (if so very progressively) adopt other
aspects.

Because I also think that given the circumstances, it is good to
vary disciplines and tools that we use, yet also remain
convinced that "moving-on",  should be as a progressive process,
mostly if not -exclusively- relative to whatever we consider can
work best for a given task.

I wouldn't currently favor XSI for say dynamic beach waves, but
for a great number of things, until there would naturally be a
time when it would simply not be worth it, either because some
things would advance considerably or some things would make it
more difficult to run, 
(either of which can be seen quite ahead of time when testing
new equipment /software)
switching should not be something that is forced, or be from
giving into more or less heavy enticements, or peer pressure, 
(specially when self employed, delivering image sequences) but
that just a personal view.

Anyhoo, 
ciaociao!
-J

On 03/21/17 19:27, Jordi Bares wrote:
  
  

Indeed I never managed to get fully where I wanted... as you can
see VOPs was missing, VEX, DOPs and so many other things but
such were my limitations in terms of knowledge and time.


Nevertheless I will suggest you take Andy’s
  comments and review them, he certainly took the time to put
  some stuff in there that is worth keeping.


My take is, from what I saw is that you were using
  Houdini like me, as if it was Softimage and sooner or later
  you will see (like I did) that it is better to embrace it and
  just move on, 



I hope you enjoy the ride. :-)
jb



  

  
On 21 Mar 2017, at 23:08, Jason S 

  wrote:


  
  
Or alot of equivalence
  mapping was in there (which was great help BTW),
  yet could of course not map the parts that aren't
  mappable 
  (or not easily mappable without getting very
  technical such as for any ice related stuff)
  
  Must have overlooked the Object merge bit thanks.
  
  On 03/21/17 18:41, Nono wrote:


  don't miss the FULL pdf
from Jordy Bares that's all in there
  
On 21 March 2017 at
  23:31, Jason S 
  wrote:
  

  Hi,


Indeed Object Merge can reference
outputs from other nodes
Thanks a bunch! (scraped the internet
for that :) )
-J

  


On 03/21/17 18:22, Nono wrote:
 

Re: Random Thoughts about H.

[Jason S]

  
  
Hi Jordi!
  
  First I wanted to personally thank you for those docs, as they
  really did go straight to the crux.
  
  Yet for the points mentioned, I would have an easier time agreeing
  with you if indeed I found "some things to be easier, and others
  not", whereas beyond what could be associated to "XSI muscle
  memory",  the sheer quantity or proportions of things that are not
  not just easier, but considerably much (much!) easier, makes it
  hard to just overlook and just "go with it", especially when
  knowing how things can be.
  
  
  Especially when what I'm looking for already exists.
  
  I know it takes great effort designing things that are both user
  friendly AND very flexible 
  (both must be at equal priority upon design phases, otherwise
  there is great tendency for becoming mostly an either/or thing,
  akin to making things both fast AND high quality) 
  
  I'm not either dismissing it altogether, just that after
  witnessing how things are, I would focus on things that are more
  accessible, and *perhaps* (if so very progressively) adopt other
  aspects.
  
  Because I also think that given the circumstances, it is good to
  vary disciplines and tools that we use, yet also remain convinced
  that "moving-on",  should be as a progressive process, mostly if
  not -exclusively- relative to whatever we consider can work best
  for a given task.
  
  I wouldn't currently favor XSI for say dynamic beach waves, but
  for a great number of things, until there would naturally be a
  time when it would simply not be worth it, either because some
  things would advance considerably or some things would make it
  more difficult to run, 
  (either of which can be seen quite ahead of time when testing new
  equipment /software)
  switching should not be something that is forced, or be from
  giving into more or less heavy enticements, or peer pressure, 
  (specially when self employed, delivering image sequences) but
  that just a personal view.
  
  Anyhoo, 
  ciaociao!
  -J
  
  On 03/21/17 19:27, Jordi Bares wrote:


  
  Indeed I never managed to get fully where I wanted... as you can
  see VOPs was missing, VEX, DOPs and so many other things but such
  were my limitations in terms of knowledge and time.
  
  
  Nevertheless I will suggest you take Andy’s comments
and review them, he certainly took the time to put some stuff in
there that is worth keeping.
  
  
  My take is, from what I saw is that you were using
Houdini like me, as if it was Softimage and sooner or later you
will see (like I did) that it is better to embrace it and just
move on, 
  
  
  
  I hope you enjoy the ride. :-)
  jb
  
  
  

  

  On 21 Mar 2017, at 23:08, Jason S 
wrote:
  
  


  Or alot of equivalence
mapping was in there (which was great help BTW),
yet could of course not map the parts that aren't
mappable 
(or not easily mappable without getting very
technical such as for any ice related stuff)

Must have overlooked the Object merge bit thanks.

On 03/21/17 18:41, Nono wrote:
  
  
don't miss the FULL pdf from
  Jordy Bares that's all in there

  On 21 March 2017 at
23:31, Jason S 
wrote:

  
Hi,
  
  Indeed Object Merge can reference outputs
  from other nodes
  Thanks a bunch! (scraped the internet for
  that :) )
  -J
  

  
  
  On 03/21/17 18:22, Nono wrote:

  


  

  

  On 21
March 2017 at 19:36, Jason S 

Re: Random Thoughts about H.

[Andy Nicholas]

> many things are easier, others are not.


Haha! Those are very true words indeed! :)

Have to say though that the recent updates to the modelling workflow have 
really made a huge difference. I'm almost starting to feel as comfortable in 
Houdini as I did in Soft. The Polyfill SOP is probably my favourite at the 
moment :)


> On 21 Mar 2017, at 23:27, Jordi Bares  wrote:
> 
> Indeed I never managed to get fully where I wanted... as you can see VOPs was 
> missing, VEX, DOPs and so many other things but such were my limitations in 
> terms of knowledge and time.
> 
> Nevertheless I will suggest you take Andy’s comments and review them, he 
> certainly took the time to put some stuff in there that is worth keeping.
> 
> My take is, from what I saw is that you were using Houdini like me, as if it 
> was Softimage and sooner or later you will see (like I did) that it is better 
> to embrace it and just move on, many things are easier, others are not.
> 
> I hope you enjoy the ride. :-)
> jb
> 
> 
>> On 21 Mar 2017, at 23:08, Jason S  wrote:
>> 
>> Or alot of equivalence mapping was in there (which was great help BTW),
>> yet could of course not map the parts that aren't mappable 
>> (or not easily mappable without getting very technical such as for any ice 
>> related stuff)
>> 
>> Must have overlooked the Object merge bit thanks.
>> 
>>> On 03/21/17 18:41, Nono wrote:
>>> don't miss the FULL pdf from Jordy Bares that's all in there
>>> 
>>> On 21 March 2017 at 23:31, Jason S  wrote:
 Hi, 
 Indeed Object Merge can reference outputs from other nodes
 Thanks a bunch! (scraped the internet for that :) )
 -J
 
 
 
 On 03/21/17 18:22, Nono wrote:
> 
> On 21 March 2017 at 19:36, Jason S  wrote:
>> I know about merge sop, but is it possible to refer to outputs or 
>> elements located in other object level networks?
>> (or having object level items used as inputs for multiple other object 
>> level networks?)
> 
> Hi,
> You don't read it correctly, Andy spokes about "Object Merge" not 
> "Merge".
> On Houdini "Object merge" is in most case the most important node. You 
> can for example mimic softimage overrides with it ;-)
> 
> Cheers 
> 
> 
> --
> 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.

Re: Random Thoughts about H.

[Jordi Bares]

Indeed I never managed to get fully where I wanted... as you can see VOPs was 
missing, VEX, DOPs and so many other things but such were my limitations in 
terms of knowledge and time.

Nevertheless I will suggest you take Andy’s comments and review them, he 
certainly took the time to put some stuff in there that is worth keeping.

My take is, from what I saw is that you were using Houdini like me, as if it 
was Softimage and sooner or later you will see (like I did) that it is better 
to embrace it and just move on, many things are easier, others are not.

I hope you enjoy the ride. :-)
jb


> On 21 Mar 2017, at 23:08, Jason S  wrote:
> 
> Or alot of equivalence mapping was in there (which was great help BTW),
> yet could of course not map the parts that aren't mappable 
> (or not easily mappable without getting very technical such as for any ice 
> related stuff)
> 
> Must have overlooked the Object merge bit thanks.
> 
> On 03/21/17 18:41, Nono wrote:
>> don't miss the FULL pdf from Jordy Bares that's all in there
>> 
>> On 21 March 2017 at 23:31, Jason S > > wrote:
>> Hi, 
>> Indeed Object Merge can reference outputs from other nodes
>> Thanks a bunch! (scraped the internet for that :) )
>> -J
>> 
>> 
>> 
>> On 03/21/17 18:22, Nono wrote:
>>> 
>>> On 21 March 2017 at 19:36, Jason S >> > wrote:
>>> I know about merge sop, but is it possible to refer to outputs or elements 
>>> located in other object level networks?
>>> (or having object level items used as inputs for multiple other object 
>>> level networks?)
>>> 
>>> Hi,
>>> You don't read it correctly, Andy spokes about "Object Merge" not "Merge".
>>> On Houdini "Object merge" is in most case the most important node. You can 
>>> for example mimic softimage overrides with it ;-)
>>> 
>>> Cheers 
>>> 
>>> 
>>> --
>>> 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: Random Thoughts about H.

[Jason S]

  
  
Or alot of equivalence mapping was in
  there (which was great help BTW),
  yet could of course not map the parts that aren't mappable 
  (or not easily mappable without getting very technical such as for
  any ice related stuff)
  
  Must have overlooked the Object merge bit thanks.
  
  On 03/21/17 18:41, Nono wrote:


  don't miss the FULL pdf from Jordy Bares that's all
in there
  
On 21 March 2017 at 23:31, Jason S 
  wrote:
  

  Hi, 
Indeed Object Merge can reference outputs from other
nodes
Thanks a bunch! (scraped the internet for that :) )
-J

  


On 03/21/17 18:22, Nono wrote:
  

  
  

  

  
On 21 March 2017 at
  19:36, Jason S 
  wrote:
  I know about merge sop,
  but is it possible to refer to outputs or
  elements located in other object level
  networks?
  (or having object level items used as
  inputs for multiple other object level
  networks?)


Hi,
  You don't read it
correctly, Andy spokes about "Object Merge" not
"Merge".
  On Houdini "Object merge"
is in most case the most important node. You can
for example mimic softimage overrides with it
;-)
  
  
  Cheers 




  

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


--
Softimage Mailing List.
To unsubscribe, send a mail to softimage-request@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: Random Thoughts about H.

[Andy Nicholas]

Yep! Still reading :) Here’s the link to the cheat sheet as it didn’t come 
through in your email: http://www.andynicholas.com/?p=1344

> I think it would be brilliant if he updated his Cheat Sheet for these post 
> HScript days.


They're expressions, not HScript, or am I misunderstanding what you’re getting 
at?

Anyway, if you have suggestions about what you’d find useful from an updated 
cheat sheet, then by all means let me know. 

I did start looking at making an update, and made a couple of mind maps 
breaking down the most popular SOPs and expressions into categories. I'll can 
post that when I next get a chance.

A



> On 21 Mar 2017, at 19:07, Jonathan Moore  wrote:
> 
> I think Andy covered off most stuff. The only thing I can reiterate is the 
> importance of VEX. I shared a link the other day to the VEX masterclass with 
> Jeff Wagner and had positive feedback from other XSI alumni on this list. If 
> you haven’t watched it yet, you should. It makes sense of many of SideFX’s 
> design decisions.
>  
> Ultimately Houdini is an operating system for 3d and becoming comfortable 
> with VEX and Python within Houdini are mandatory things. SideFX might like to 
> market Core as a replacement for XSI but VEX in particular and Python (if you 
> want create portable assets) are essential ingredients in getting the most 
> out of Houdini.
>  
> I came to Houdini with a hackers knowledge of Python scripting and  competent 
> Processing (which I suppose is Java) skills. Never learnt C++ and I certainly 
> wouldn’t classify myself as a programmer; and I find I’m comfortable with 
> VEX. Sure I have the help browser opened permanently on my second browser the 
> check my function arguments, but I muddle along without pain most of the time.
>  
> If Andy’s still reading, I think it would be brilliant if he updated his 
> Cheat Sheet for these post HScript days. When I was first learning Houdini it 
> was a huge help. And funnily enough even though HScript has mostly been 
> discarded, the list of ‘essential’ SOP operators Andy listed back in 2011 are 
> just as relevant in 2017.   <>
>  
>  
> From: softimage-boun...@listproc.autodesk.com 
>  
> [mailto:softimage-boun...@listproc.autodesk.com 
> ] On Behalf Of Jason S
> Sent: 21 March 2017 18:36
> To: Official Softimage Users Mailing List. 
> https://groups.google.com/forum/#!forum/xsi_list 
>   >
> Subject: Re: Random Thoughts about H.
>  
> 
> Hi Andy,
> 
> Thanks for the feedback!
> 
>>> - Can handle lots of objects or elements and a few things became very much 
>>> faster in recent versions (multi-threaded or openCL)
>>>(SI  is still is king for sheer high-poly-count on fewer objects, which 
>>> includes *tons* of island transforms)
>> 
>> Have a look at packed primitives. You can chunk your geometry into sections 
>> and get excellent performance there along with deferred rendering.
>> 
>> For island management, then there are workflows that use the "name" string 
>> primitive attribute to differentiate between pieces. Some SOPs support this 
>> (see clustering and fracturing for example).
>> 
> 
> Indeed I'm aware of packed prims, and I already agreed with you there (was in 
> the "Good!" section :P )
> 
> 
>>> Elements seem to be either inside OR outside, or object level elements 
>>> (where regular parenting happens) are almost like separate scenes
>> 
>> Not sure I completely understand your point. I've not had an issue with 
>> referencing data or geometry. You can use the Object Merge SOP to pull 
>> geometry from anywhere though, and you can use expressions and VEX to pull 
>> info from other objects too (although I'd generally recommend object merging 
>> them for clarity). The convention (as you've probably seen) is to use a Null 
>> SOP called something like "OUT_Geometry" for example, or to use an Output 
>> node, and then reference those from another object. That has the advantage 
>> of being able to insert more nodes before the referenced node, so you don't 
>> have to update all your references.
>> 
> 
> I know about merge sop, but is it possible to refer to outputs or elements 
> located in other object level networks?
> (or having object level items used as inputs for multiple other object level 
> networks?)
> 
> 
>>> - ICE equivalence  (personally my biggest gripe)
>>> Wished for one thing, that Vop nets allowed for subnetworks with custom 
>>> port names, 
>> 
>> This is possible, but you need to create a digital asset to do it. Kinda 
>> painful as a workflow, but it is there.
>> 
>> 
>>> If that's  at-all realistic, as it would probably involve very systemic 
>>> changes, like how/when compilation happens (?)
>>> (to allow time dependancy  inside vops, but I don't know)
>> 
>> You 

Re: Random Thoughts about H.

[Nono]

don't miss the FULL pdf from Jordy Bares that's all in there

On 21 March 2017 at 23:31, Jason S  wrote:

> Hi,
> Indeed Object Merge can reference outputs from other nodes
> Thanks a bunch! (scraped the internet for that :) )
> -J
>
>
>
> On 03/21/17 18:22, Nono wrote:
>
>
> On 21 March 2017 at 19:36, Jason S  wrote:
>
>> I know about merge sop, but is it possible to refer to outputs or
>> elements located in other object level networks?
>> (or having object level items used as inputs for multiple other object
>> level networks?)
>
>
> Hi,
> You don't read it correctly, Andy spokes about "Object Merge" not "Merge".
> On Houdini "Object merge" is in most case the most important node. You can
> for example mimic softimage overrides with it ;-)
>
> Cheers
>
>
> --
> 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: Random Thoughts about H.

[Jason S]

  
  
Hi, 
  Indeed Object Merge can reference outputs from other nodes
  Thanks a bunch! (scraped the internet for that :) )
  -J
  
  
  On 03/21/17 18:22, Nono wrote:


  

  On 21 March 2017 at 19:36, Jason S 
wrote:
I know about merge sop, but is it
possible to refer to outputs or elements located in
other object level networks?
(or having object level items used as inputs for
multiple other object level networks?)
  
  
  Hi,
You don't read it correctly, Andy
  spokes about "Object Merge" not "Merge".
On Houdini "Object merge" is in most
  case the most important node. You can for example mimic
  softimage overrides with it ;-)


Cheers 
  
  
  
  
  --
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: Random Thoughts about H.

[Nono]

On 21 March 2017 at 19:36, Jason S  wrote:

> I know about merge sop, but is it possible to refer to outputs or elements
> located in other object level networks?
> (or having object level items used as inputs for multiple other object
> level networks?)


Hi,
You don't read it correctly, Andy spokes about "Object Merge" not "Merge".
On Houdini "Object merge" is in most case the most important node. You can
for example mimic softimage overrides with it ;-)

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

Re: Question about the latest release of MentalRay for Maya

[Pierre Schiller]

Thanks Matt for your reply.
"asking naively", as I wrote. :D
No probs.

On Mon, Mar 20, 2017 at 11:24 AM, Matt Lind  wrote:

> Generally speaking, mental ray is fairly finicky about versioning and
> compatibility.  Usually shaders need to be re-compiled for each version of
> mental ray, and only on rare occasion does an older compiled shader work on
> a newer version of the renderer because of all the subtle changes to the
> code.
>
> Taking a .dll from a newer version of mental ray (Maya) and trying to use
> it
> in an older version (Softimage) is not likely to work.  Just after
> Softimage
> was EOL'd, mental ray went through some significant core changes to greatly
> improve performance.  I doubt what you're asking will work.
>
> Matt
>
>
>
>
>
> Date: Sun, 19 Mar 2017 15:55:24 -0500
> From: Pierre Schiller 
> Subject: Question about the latest release of MentalRay for Maya
> To: "Official Softimage Users Mailing List.
>
> Hello, I?ve got a naive question about MR for Maya:
> Can Softimage read those .dll and work with them? Like, point softimage to
> a specific
> folder in preferences and will it pick up the Mental Ray code to use as
> renderer?
> Thanks.
>
> --
> Portfolio 2013 
> Cinema & TV production
> Video Reel 
>
>
> --
> Softimage Mailing List.
> To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com
> with "unsubscribe" in the subject, and reply to confirm.
>



-- 
Portfolio 2013 
Cinema & TV production
Video Reel 
--
Softimage Mailing List.
To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with 
"unsubscribe" in the subject, and reply to confirm.

Re: Random Thoughts about H.

[Eugene Flormata]

 tried watching the VEX masterclass
it was way over my head, haha
back to the drawing board


On Tue, Mar 21, 2017 at 12:07 PM, Jonathan Moore 
wrote:

> I think Andy covered off most stuff. The only thing I can reiterate is the
> importance of VEX. I shared a link the other day to the VEX masterclass
> with Jeff Wagner and had positive feedback from other XSI alumni on this
> list. If you haven’t watched it yet, you should. It makes sense of many of
> SideFX’s design decisions.
>
>
>
> Ultimately Houdini is an operating system for 3d and becoming comfortable
> with VEX and Python within Houdini are mandatory things. SideFX might like
> to market Core as a replacement for XSI but VEX in particular and Python
> (if you want create portable assets) are essential ingredients in getting
> the most out of Houdini.
>
>
>
> I came to Houdini with a hackers knowledge of Python scripting and
>  competent Processing (which I suppose is Java) skills. Never learnt C++
> and I certainly wouldn’t classify myself as a programmer; and I find I’m
> comfortable with VEX. Sure I have the help browser opened permanently on my
> second browser the check my function arguments, but I muddle along without
> pain most of the time.
>
>
>
> If Andy’s still reading, I think it would be brilliant if he updated his
> Cheat Sheet for these post HScript days. When I was first learning Houdini
> it was a huge help. And funnily enough even though HScript has mostly been
> discarded, the list of ‘essential’ SOP operators Andy listed back in 2011
> are just as relevant in 2017.  
>
--
Softimage Mailing List.
To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with 
"unsubscribe" in the subject, and reply to confirm.

RE: Random Thoughts about H.

[Jonathan Moore]

I think Andy covered off most stuff. The only thing I can reiterate is the 
importance of VEX. I shared a link the other day to the VEX masterclass with 
Jeff Wagner and had positive feedback from other XSI alumni on this list. If 
you haven’t watched it yet, you should. It makes sense of many of SideFX’s 
design decisions.

 

Ultimately Houdini is an operating system for 3d and becoming comfortable with 
VEX and Python within Houdini are mandatory things. SideFX might like to market 
Core as a replacement for XSI but VEX in particular and Python (if you want 
create portable assets) are essential ingredients in getting the most out of 
Houdini.

 

I came to Houdini with a hackers knowledge of Python scripting and  competent 
Processing (which I suppose is Java) skills. Never learnt C++ and I certainly 
wouldn’t classify myself as a programmer; and I find I’m comfortable with VEX. 
Sure I have the help browser opened permanently on my second browser the check 
my function arguments, but I muddle along without pain most of the time.

 

If Andy’s still reading, I think it would be brilliant if he updated his Cheat 
Sheet for these post HScript days. When I was first learning Houdini it was a 
huge help. And funnily enough even though HScript has mostly been discarded, 
the list of ‘essential’ SOP operators Andy listed back in 2011 are just as 
relevant in 2017.  

 

 

From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Jason S
Sent: 21 March 2017 18:36
To: Official Softimage Users Mailing List. 
https://groups.google.com/forum/#!forum/xsi_list 

Subject: Re: Random Thoughts about H.

 


Hi Andy,

Thanks for the feedback!

- Can handle lots of objects or elements and a few things became very much 
faster in recent versions (multi-threaded or openCL)
   (SI  is still is king for sheer high-poly-count on fewer objects, which 
includes *tons* of island transforms)


Have a look at packed primitives. You can chunk your geometry into sections and 
get excellent performance there along with deferred rendering.

For island management, then there are workflows that use the "name" string 
primitive attribute to differentiate between pieces. Some SOPs support this 
(see clustering and fracturing for example).


Indeed I'm aware of packed prims, and I already agreed with you there (was in 
the "Good!" section :P )




Elements seem to be either inside OR outside, or object level elements (where 
regular parenting happens) are almost like separate scenes


Not sure I completely understand your point. I've not had an issue with 
referencing data or geometry. You can use the Object Merge SOP to pull geometry 
from anywhere though, and you can use expressions and VEX to pull info from 
other objects too (although I'd generally recommend object merging them for 
clarity). The convention (as you've probably seen) is to use a Null SOP called 
something like "OUT_Geometry" for example, or to use an Output node, and then 
reference those from another object. That has the advantage of being able to 
insert more nodes before the referenced node, so you don't have to update all 
your references.


I know about merge sop, but is it possible to refer to outputs or elements 
located in other object level networks?
(or having object level items used as inputs for multiple other object level 
networks?)




- ICE equivalence  (personally my biggest gripe)
Wished for one thing, that Vop nets allowed for subnetworks with custom port 
names, 


This is possible, but you need to create a digital asset to do it. Kinda 
painful as a workflow, but it is there.




If that's  at-all realistic, as it would probably involve very systemic 
changes, like how/when compilation happens (?)
(to allow time dependancy  inside vops, but I don't know)


You can have time dependancy inside VOPs, you just need to use the Time input 
from global variables, rather than use $FF inside expressions.

Thanks, also I think promoting parameters allows for time dependency? 
But I was referring to time dependency as what could prevent entire processes 
to be self contained inside a  single VOP net.
(or one of the things)




everything  (such as different settings  or where to adjust different things) 
is all over the place

Yes, it can be, which is why it's crucial to try to be as organised as possible 
and work in a consistent way. If there's an occasion you can't be consistent, 
then put down a post-it note in your network to document it for when you or 
someone else comes back to the scene.




  --- expressions ::
 even if often very simple, driving values with more elaborate 
procedures, 
 requires equally more elaborate expressions with often somewhat 
cryptic and sensitive syntax 
 with single or two letter functions that can be easy to remember for 
the more common ones like 'F' or 'P',
 but otherwise involves having the doc 

Re: Random Thoughts about H.

[Jason S]

  
  

  Hi Andy,

Thanks for the feedback!
  


  
  
- Can handle lots of objects or
  elements and a few things became very much faster in recent
  versions (multi-threaded or openCL)
     (SI  is still is king for sheer high-poly-count on fewer
  objects, which includes *tons* of island transforms)

  
  
  Have a look at packed primitives. You can chunk your geometry into
  sections and get excellent performance there along with deferred
  rendering.
  
  For island management, then there are workflows that use the
  "name" string primitive attribute to differentiate between pieces.
  Some SOPs support this (see clustering and fracturing for
  example).
  


  Indeed I'm aware of packed prims, and I already agreed with you
  there (was in the "Good!" section :P )


  
 Elements seem to be either
inside OR outside, or object level elements (where regular
parenting happens) are almost like separate scenes

  
  
  Not sure I completely understand your point. I've not had an issue
  with referencing data or geometry. You can use the Object Merge
  SOP to pull geometry from anywhere though, and you can use
  expressions and VEX to pull info from other objects too (although
  I'd generally recommend object merging them for clarity). The
  convention (as you've probably seen) is to use a Null SOP called
  something like "OUT_Geometry" for example, or to use an Output
  node, and then reference those from another object. That has the
  advantage of being able to insert more nodes before the referenced
  node, so you don't have to update all your references.
  


  I know about merge sop, but is it possible to refer to outputs or
  elements located in other object level networks?
  (or having object level items used as inputs for multiple other
  object level networks?)


  
 - ICE equivalence 
  (personally my biggest gripe)
  Wished for one thing, that Vop nets allowed for subnetworks
  with custom port names, 

  
  
  This is possible, but you need to create a digital asset to do it.
  Kinda painful as a workflow, but it is there.
  
  
If that's  at-all realistic, as it
  would probably involve very systemic changes, like how/when
  compilation happens (?)
  (to allow time dependancy  inside vops, but I don't know)
  
  
  You can have time dependancy inside VOPs, you just need to use the
  Time input from global variables, rather than use $FF inside
  expressions.
  

Thanks, also I think promoting parameters
  allows for time dependency? 
  But I was referring to time dependency as what could prevent
  entire processes to be self contained inside a  single VOP net.
  (or one of the things)


  
everything  (such as different
  settings  or where to adjust different things) is all over the
  place

  
  Yes, it can be, which is why it's crucial to try to be as
  organised as possible and work in a consistent way. If there's an
  occasion you can't be consistent, then put down a post-it note in
  your network to document it for when you or someone else comes
  back to the scene.
  
  
   --- expressions ::
   even if often very simple, driving values with more
  elaborate procedures, 
   requires equally more elaborate expressions with
  often somewhat cryptic and sensitive syntax 
   with single or two letter functions that can be easy
  to remember for the more common ones like 'F' or 'P',
       but otherwise involves having the doc open at all
  times.

  
  
  You get used to it quickly, but you'll probably find you move more
  towards Vex, which will make most expressions redundant.


Perhaps I could get used to it, like I could
  also get use to C++, but the point was that it's not what I would
  want to deal with under tight deadlines (or where I would like to
  spend most of my time)
  
  I've done my fair share of scripting, even some quite elaborate
  ones, but always commenting the heck out everything and having
  extra descriptive variable names to not have to decipher myself
  even the next day, but I couldn't say I could decipher half the
  scripts I come across, and such things remain quite difficult for
  me  (as for many artists).


  
      To simply -- say
  randomizing something with range that changes in time, is
  comparatively quite something,
      

Re: Random Thoughts about H.

[Andy Nicholas]

Hi Jason,
That's a good list. My thoughts and suggestions on your issues below:

**- Can handle lots of objects or elements and a few things became 
very much faster in recent versions (multi-threaded or openCL)
   (SI  is still is king for sheer high-poly-count on fewer objects, 
which includes *tons* of island transforms)


Have a look at packed primitives. You can chunk your geometry into 
sections and get excellent performance there along with deferred rendering.


For island management, then there are workflows that use the "name" 
string primitive attribute to differentiate between pieces. Some SOPs 
support this (see clustering and fracturing for example).



*Passes*
- there's probably 3 or more ways to set-up 'passes', and all of them 
are comparatively excruciating.


Yep. That's a fair comment. Most people have their own preferred method. 
It's generally recommend staying away from Takes as a technique to 
create passes though, apart from when absolutely necessary.



*- Help!*
- Can be Really bad for browsing reference sections
- Alphabetically sorted  flat list of all nodes, all 
expression functions or all Vex functions ...
  For example ::   the   'Inflate', 'Instance', 'IsoOffset'  
nodes, all concern very different things.


Yes, the docs really need a lot of work still IMHO and have done for a 
while. The documentation for DOPs in particular frequently make me want 
to scream at the lack of clarity to what they do and how they're 
supposed to be used. It is majorly lacking in context and clear examples.


   - Perhaps there is something up with my setup, but help views 
seemed very buggy
 and (sometimes not always) very slow especially when always 
having it open.


Yes, definitely slow. Would highly recommend opening it in an external 
browser, and making a bookmark for the local documentation. You'll need 
to launch Houdini's help first before the external browser so that it 
starts the http service. The port number will vary for each Houdini 
version, but the local URL will be something like 
http://127.0.0.1:48626/_index


The help does crash regularly (SideFX know about this, and are working 
on a fix), so worth bookmarking the online documentation too. 
http://www.sidefx.com/docs/houdini/




- *Scene item Tree list *(outliner/Explorer) seems somewhat basic,
Network view is great, but tree lists can be much more optimal for 
overviewing hierarchies
and unless I missed a preference(?) H tree view is a flat list of 
all object level items without parenting hierarchy representation.


There are various tree views that can appear for selecting objects, etc. 
but the main tree view shows all the hierarchy of operators at every 
level. It doesn't show object parenting hierarchies (unless you nest 
them in subnet works that is). There's no view to show object 
hierarchies (unless I've missed something).



*- Inconsistent highlighting and/or viewport element display*


Yep, it can get quite confusing, and I think Houdini gets quite confused 
too about the UI state sometimes. Couple of things to remember: 1) if in 
doubt hit Escape a few times to get back to a known state. 2) Pressing 
and holding space will get you into Viewport mode (a bit like holding S 
down in Softimage). So, for example: pressing and holding Space then 
pressing "5" will always move you to UV view, regardless of what active 
tool you have. Same goes for pressing Space + "f", "g", or "h".



*Elements seem to be either inside OR outside, or object level 
elements (where regular parenting happens) are almost like separate 
scenes*


Not sure I completely understand your point. I've not had an issue with 
referencing data or geometry. You can use the Object Merge SOP to pull 
geometry from anywhere though, and you can use expressions and VEX to 
pull info from other objects too (although I'd generally recommend 
object merging them for clarity). The convention (as you've probably 
seen) is to use a Null SOP called something like "OUT_Geometry" for 
example, or to use an Output node, and then reference those from another 
object. That has the advantage of being able to insert more nodes before 
the referenced node, so you don't have to update all your references.




*Performance*


Yep, cloth is frustratingly slow compared to Syflex, I'm no expert, but 
I'd say that it's more flexible in terms of what you can do with it in 
Houdini.



*- ICE**equivalence* (personally my biggest gripe)
Wished for one thing, that Vop nets allowed for subnetworks with 
custom port names,


This is possible, but you need to create a digital asset to do it. Kinda 
painful as a workflow, but it is there.


If that's  at-all realistic, as it would probably involve very 
systemic changes, like how/when compilation happens (?)

(to allow time dependancy  inside vops, but I don't know)


You can have time dependancy inside VOPs, you just need to use the Time 
input from global variables, rather than use $FF inside 

Random Thoughts about H.

[Jason S]

  
  

  Hi,
  
  In light of recent H ramblings, just wanted to share a few pros
  and cons I personally found with H.
  
  ___
  Good!

  
  
  - Can easily 'Get' effects, like fire, pool of water etc... then
  define inputs, and tweak settings.
  
      Can be artist friendly for high level nodes  
      ( weather for factory nodes, or various digital assets around
  ) 
  
      Factory high-level 'Assets' with workflows that are very
  streamlined, with everything very refined
      (all the way up to rendering)   to make truly great FX very
  fast.
  
  - Modeling  now seems just fine!  
  (or at least for direct component manipulation which is now good
  enough, because it was much more finicky)
  
  Without being the same as SI, or the same as   [insert the app
you are most use-to here]  
  I don't think anyone expects it to be the same as what they are
  use to, but similarly as workable, so that's neat!
  
  Seemingly in no small part thanks to McNistor's  (and possibly
  others) initiative, patience  and  dedication 
  ( and dev's openness which is very commendable and rare )
  ironing out annoyances, and narrowing down issues.
  
  Because of that, at least for modeling, 
  Houdini networks now feels (or feels much more) like a 'next'
  version of SI's construction stack, or like 'model compositing'.
  
  
  Performance 

  - Can handle lots of objects or elements and a few things
  became very much faster in recent versions (multi-threaded or
  openCL)
     (SI  is still is king for sheer high-poly-count on fewer
  objects, which includes *tons* of island transforms)
  
  
  ___
  Things that I'm not sure yet
  
  -Animation
  As far as I could tell, like setting keys and curve editing seems
  just fine.
  
  Although I'm sure artists that animate or rig characters all day
  would have (and probably have) things to say about workflows,
  I was pleased to see that at first glance, alot seemed to already
  be there.
  
  -Shading
  Haven't checked new shading workflows yet.
  
  
  
  ___
  Things I find to be 'Meh'
 

Passes
  - there's probably 3 or more ways to set-up 'passes', and all of
  them are comparatively excruciating.
  
  - Help!
      - Good for explicit searches, or clicking the '?' icon in
  operator headers.
  
      - Can be Really bad for browsing reference sections
          - Alphabetically sorted  flat list of all nodes, all
  _expression_ functions or all Vex functions ...
        For example ::   the   'Inflate', 'Instance',
  'IsoOffset'  nodes, all concern very different things.
  
     - Perhaps there is something up with my setup, but help views
  seemed very buggy 
       and (sometimes not always) very slow especially when always
  having it open.
  
  - Scene item Tree list (outliner/Explorer) seems somewhat
  basic,
  Network view is great, but tree lists can be much more optimal for
  overviewing hierarchies
  and unless I missed a preference(?) H tree view is a flat list of
  all object level items without parenting hierarchy representation.
  
  
  - Inconsistent highlighting and/or viewport element display
  
  This may very well be things I haven't yet understood, but even
  after a while, I haven't wrapped my head around it, ...
  but highlighting of selection or when viewing particular nodes
  seems quite inconsistent 
  (when inside, or at obj level when switching tabs)
  sometimes shading type changes, sometimes with textures, sometimes
  not, sometimes transparent, sometimes not,
  or displays other outputs as well? (sometimes not). 
  (when viewing back and forth between the very same nodes )
  
  
  Elements seem to be either inside OR outside, or object level
elements (where regular parenting happens) are almost like separate
scenes
  (with little or no communication between them?)
  I may very well have missed something, or I hope I'm wrong, 
  but it doesn't seem to be possible have multiple references of
  outputs or elements that are at object level or in other sops(?) 
  (for instancing, or having common sources (easy and very common in
  ICE), or for allowing for arbitrary inputs)
  
  Performance
  Quite a few things remain very slow,
  the grass flattening example is runs at 5 fps for very few, very
  short guide fur strands.
  Teckano's ICE Grass flattening tutorial scene runs at 60 fps with
  tons of long 

Re: Latest Houdini Wrangle Masterclass

[Fabricio Chamon]

thanks for the link Jonathan. It is so informative! And it clearly points a
beginner to the right direction performance-wise, as there are many ways to
do the same thing in vex.

2017-03-21 0:42 GMT+01:00 Eugene Flormata :

> so this hasn't changed much since in the 16 update? I just started some
> tutorials on game tutors
> and bought https://vimeo.com/195580569, it got into vex pretty quickly.
> coding in general is pretty outside my skillset, so I'm looking for basics
> in houdini to pick up.
> https://www.pluralsight.com/courses/houdini-practical-math-tips I even
> bought a month of pluralsight to learn this, which I think Jordi posted in
> a thread a while back?
>
>
> I'm trying to find more things to learn houdini and upgrade my skillset
> thanks for the post!
>
> On Mon, Mar 20, 2017 at 4:02 AM, Jonathan Moore  > wrote:
>
>> Something for those of you that are trying to get to grips with VEX
>> Wrangles in Houdini
>>
>>
>>
>> https://vimeo.com/173658697
>>
>>
>>
>> It’s a Jeff Wagner 2hr session so it has plenty of (valuable)
>> digressions, and on that basis it’s one that you’ll want to watch a few
>> times. Be sure to download the deck and example files too (I’d download the
>> Vimeo video as well so you can setup bookmarks in VLC). Jeff has been with
>> SideFX since the very beginning so his webinars are always full of great
>> insights into Houdini’s mysterious ways. 
>>
>>
>>
>> This was released soon after 15.5 was introduced so it’s the most up to
>> date VEX Wrangles material available from SideFX.
>>
>> --
>> 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.