Re: Houdini Weaknesses

[Nick Angus]

A very wise person advised me quite a while ago when I was at a crossroads and 
Soft was still very much alive.  I sent an email to Andy Nicholas asking his 
opinion as I knew The Mill were using Soft and Houdini.  Andy described Houdini 
to me as not so much a 3d application as an operating system for a 3d 
environment.  After spending some serious time with Houdini recently I couldn't 
think of a more apt description.

As far as I am concerned the animation/rigging war is over and Maya won, not on 
merit of course…. But that doesn't make much difference when you are looking 
for a freelance rigger or animator to hit the ground running.

So we find ourselves using Soft as an asset assembly tool for 
lighting/shading/fur/rendering, with effects and lots more  from ICE. It has 
worked brilliantly thanks to Alembic and a few tools we have built on the fly.  
But more and more I am finding the need for things that Soft cannot do such as 
fluids, Smoke and destruction or a nasty combination of all of that!

When I say Alembic I mean pointcache only, the asset is shaded/fur-groomed/look 
developed entirely in Soft.  We import the assets into a shot and then import 
animation onto them that is published from Maya.  It is a pretty sweet way to 
work, and lets us turn around commercial jobs in amazing time.  It allows us to 
(once basic rigging has started) parallelise your production and no one sits 
around waiting for handover.

I agree particles are at the moment probably better in ICE, but more from a 
motion graphics perspective than anything else.  So it has effects covered, 
shading is pretty good too, especially with the addition of the new workflow in 
HtoA.  The way it handles Alembic out of the box is brilliant also.

Mantra would probably be my next choice behind Arnold as a renderer also.  The 
tests for me will be instancing compared to the ICE workflow, particularly with 
Milan Vaseks awesome scatter tools that I depend on so much!   And fur, fur 
looks pretty hard and slow to me right now, when even Softs old fur tools are 
still pretty amazing.

The other biggie for me is Houdini Digital Assets, a really nice way to publish 
out tools or assets with lots of control. It really is the only App other than 
Soft that I would trust with referencing in complex assets.

I have lots to learn, but I think I am going to put Houdini up as the backbone 
of the company over the next 18 months or so.  Soft will still be there and 
many jobs will probably still go through that pipe depending what they are.  
But I am sure I will end up crossing over completely at some point down the 
track.

Cheers, Nick

Re: Houdini Weaknesses

[Sajjad Amjad]

>
> How much custom plugin development do you have to do with Houdini compared
> to Softimage, Maya, etc...?  Let's define a plugin as something you'd write
> as a script or C++ lib that gets included in the software as a reusable
> tool, perhaps providing it's own GUI front end (if applicable) and is
> responsible enough to do proper error checking (as opposed to a couple line
> hack script like many artists do).
>

if you're talking about the lines of code to get the same stuff done in
Softimage or Maya, I would say it really depends on how you approach the
problem. As with all things Houdini, there are multiple ways of making
plug-ins/nodes with custom GUIs. You can create the whole layout
dynamically (similar to using parameters and PPGLayout in Softimage), or
you can manually create the layout and connect it through scripts. I tend
to do everything programmatically to keep everything in one place. I've
written plenty of plug-ins which provide exactly the same functionality in
various DCCs including Houdini. The code for Houdini was similar in length
to the others.

If you're talking about general custom plug-in development, I guess the
answer would be the same for any DCC that needs to be integrated in to the
production pipeline. I'm assuming, for a game studio, you have very strict
rules to govern where things go in the file system. Based on your previous
posts on the topic (of moving away from Softimage), I think it's safe to
assume you'll need to do a fair bit of custom development.

>
> Is there much of an SDK for writing GUI's as front ends for tool


In short, yes. My personal experience with the Houdini SDK has been
fantastic. I don't recall hitting a brick wall. Going off on a slight
tangent, the only thing which irritated me was lack of Python support for
viewport capture. However, that can be easily done through Hscript. The
good news is that it will come for Python (it's in the roadmap). For GUIs,
Houdini allows using native widgets or going down the PyQt path.
Thankfully, there's none of that event loop issues that Softimage has when
using PyQt. My personal preference is to use native widgets as they allow
for a consistent UI experience. As mentioned earlier, you can create GUIs
manually (drag and drop) and link them through scripting, or you can create
them programmatically. Both approaches have their merits. The Houdini
Python Shell is best of breed. Imagine getting a reference to an ICE node
in Softimage by dragging said ICE node in to the Script Editor, this works
in Houdini. Also, hurray for auto-complete virtually wherever you can write
scripts.

>From a pipeline integration point of view, I think the biggest mistake
people make during transition is to try and find one-to-one correlation
between workflows and concepts. The best you can hope for is similarity of
some concepts. There are no workgroups or custom parameter sets, however,
there are equivalents which work perfectly well. Some find it strange that
Houdini has no default project structure, I rather like it (now). The lack
of a project structure is a testament to the fact that Houdini can be
integrated in to whatever structure you're using currently.

Sajjad

Re: Houdini Weaknesses

[Meng-Yang Lu]

This is actually where Houdini shines.  Taking something that exists and
manipulating the DATA to create something new.

Say you've got characters that have like belts of ammo as an accessory.
 You can create a dependency saying something like... if you choose type
bullet, it also drives the number of bullets on the belt.  So if you choose
type grenade which are larger in size, that type can drive the lesser
number of grenades on the belt.  Between nodes like copy/stamp and
switches, you can build these into your system.  You could, if all the
assets are there, build a character creation system seen in a lot of games
if you wish.  Even up to clever things like stating which type of weapon
the character is holding.  Like if a weapon is two-handed by type, you
could never have a single-offhand accessory, thus never having things that
could conflict if both existed.

The best way to think of Houdini is not just an FX tool.  It's an operating
system that manages 3D data and does it extremely well.  This is why it
takes a long time to build the setup, but the payoff is that over time, you
gain a huge advantage of creating various version of one thing as long as
you've built it into your setup.

Modeling and texturing really should be done somewhere else.  But once
those assets are create and you want to manipulate it, Houdini become a
really powerful ally in this case.

-Lu




On Wed, May 21, 2014 at 3:52 PM, Matt Lind  wrote:

> That makes sense for an FX workflow as every project is essentially
> unique, but in a production where you churn out a lot of carbon copies or
> variations of the same content, how well does Houdini’s framework/workflows
> cater to that?  For example, are there mechanisms or abilities to enforce
> certain ways of working?  That’s probably our biggest concern as our
> content has to be functional, not just look good.  To be functional
> requires certain elements be consistently defined on the assets and the
> asset structured in particular ways.
>
>
>
> One weakness I see so far is the lack of API for hardware shader
> development. GLSL is there, but it’s slow compared to straight OpenGL.  I
> haven’t looked very deeply, but at a quick glance I don’t see any Direct X
> support.
>
>
>
> One thing that would be really useful for the transition guides is more
> focus on modeling and texturing.   Houdini seems to have  the basic
> building blocks, but the rest has to be developed/configured by the user.
>
>
>
> Matt
>
>
>
>
>
>
>
>
>
> *From:* softimage-boun...@listproc.autodesk.com [mailto:
> softimage-boun...@listproc.autodesk.com] *On Behalf Of *Meng-Yang Lu
> *Sent:* Wednesday, May 21, 2014 3:37 PM
> *To:* softimage@listproc.autodesk.com
> *Subject:* Re: Houdini Weaknesses
>
>
>
> Yes.  It's nodes and expression heavy.  And for that same reason it
> drastically reduces plugin development cause you're essentially programming
> every time you're in the package.  And just like you'd copy and paste
> snippet of code, you'd do the same but with nodes of a tree.
>
>
>
> Whenever I feel like I need to do dev work in Maya which is often, I just
> go to Houdini now.
>
>
>
> The UI creation is also pretty nifty.  You basically have access to all
> the params, sliders, and widgets you'd normally see in Houdini's default
> tools.  Just a matter of dragging, dropping, and organizing to your heart's
> content.  You can promote params from a lower level to a higher level at
> anytime, exposing only what you want the artist to see.
>
>
>
> You can do error checking either through the nodes or through vops/vex.
>
>
>
> It's got one foot in as a 3D application and 2 feet in as a plug-in
> development platform.  Yes, 3 legged analogies are weird, just like
> Houdini.  But I like it now.
>
>
>
> -Lu
>
>
>
>
>
>
>
>
>
> On Wed, May 21, 2014 at 3:17 PM, Matt Lind 
> wrote:
>
> Seems like Houdini is heavy on nodes and expressions to create your work.
>
> How much custom plugin development do you have to do with Houdini compared
> to Softimage, Maya, etc...?  Let's define a plugin as something you'd write
> as a script or C++ lib that gets included in the software as a reusable
> tool, perhaps providing it's own GUI front end (if applicable) and is
> responsible enough to do proper error checking (as opposed to a couple line
> hack script like many artists do).
>
> Is there much of an SDK for writing GUI's as front ends for tools?
>
>
> Matt
>
>
>
>

RE: Houdini Weaknesses

[Matt Lind]

That makes sense for an FX workflow as every project is essentially unique, but 
in a production where you churn out a lot of carbon copies or variations of the 
same content, how well does Houdini’s framework/workflows cater to that?  For 
example, are there mechanisms or abilities to enforce certain ways of working?  
That’s probably our biggest concern as our content has to be functional, not 
just look good.  To be functional requires certain elements be consistently 
defined on the assets and the asset structured in particular ways.

One weakness I see so far is the lack of API for hardware shader development. 
GLSL is there, but it’s slow compared to straight OpenGL.  I haven’t looked 
very deeply, but at a quick glance I don’t see any Direct X support.

One thing that would be really useful for the transition guides is more focus 
on modeling and texturing.   Houdini seems to have  the basic building blocks, 
but the rest has to be developed/configured by the user.

Matt




From: softimage-boun...@listproc.autodesk.com 
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Meng-Yang Lu
Sent: Wednesday, May 21, 2014 3:37 PM
To: softimage@listproc.autodesk.com
Subject: Re: Houdini Weaknesses

Yes.  It's nodes and expression heavy.  And for that same reason it drastically 
reduces plugin development cause you're essentially programming every time 
you're in the package.  And just like you'd copy and paste snippet of code, 
you'd do the same but with nodes of a tree.

Whenever I feel like I need to do dev work in Maya which is often, I just go to 
Houdini now.

The UI creation is also pretty nifty.  You basically have access to all the 
params, sliders, and widgets you'd normally see in Houdini's default tools.  
Just a matter of dragging, dropping, and organizing to your heart's content.  
You can promote params from a lower level to a higher level at anytime, 
exposing only what you want the artist to see.

You can do error checking either through the nodes or through vops/vex.

It's got one foot in as a 3D application and 2 feet in as a plug-in development 
platform.  Yes, 3 legged analogies are weird, just like Houdini.  But I like it 
now.

-Lu




On Wed, May 21, 2014 at 3:17 PM, Matt Lind 
mailto:ml...@carbinestudios.com>> wrote:
Seems like Houdini is heavy on nodes and expressions to create your work.

How much custom plugin development do you have to do with Houdini compared to 
Softimage, Maya, etc...?  Let's define a plugin as something you'd write as a 
script or C++ lib that gets included in the software as a reusable tool, 
perhaps providing it's own GUI front end (if applicable) and is responsible 
enough to do proper error checking (as opposed to a couple line hack script 
like many artists do).

Is there much of an SDK for writing GUI's as front ends for tools?


Matt

Re: Houdini Weaknesses

[Meng-Yang Lu]

Yes.  It's nodes and expression heavy.  And for that same reason it
drastically reduces plugin development cause you're essentially programming
every time you're in the package.  And just like you'd copy and paste
snippet of code, you'd do the same but with nodes of a tree.

Whenever I feel like I need to do dev work in Maya which is often, I just
go to Houdini now.

The UI creation is also pretty nifty.  You basically have access to all the
params, sliders, and widgets you'd normally see in Houdini's default tools.
 Just a matter of dragging, dropping, and organizing to your heart's
content.  You can promote params from a lower level to a higher level at
anytime, exposing only what you want the artist to see.

You can do error checking either through the nodes or through vops/vex.

It's got one foot in as a 3D application and 2 feet in as a plug-in
development platform.  Yes, 3 legged analogies are weird, just like
Houdini.  But I like it now.

-Lu





On Wed, May 21, 2014 at 3:17 PM, Matt Lind  wrote:

> Seems like Houdini is heavy on nodes and expressions to create your work.
>
> How much custom plugin development do you have to do with Houdini compared
> to Softimage, Maya, etc...?  Let's define a plugin as something you'd write
> as a script or C++ lib that gets included in the software as a reusable
> tool, perhaps providing it's own GUI front end (if applicable) and is
> responsible enough to do proper error checking (as opposed to a couple line
> hack script like many artists do).
>
> Is there much of an SDK for writing GUI's as front ends for tools?
>
>
> Matt
>
>
>
>

RE: Houdini Weaknesses

[Matt Lind]

Seems like Houdini is heavy on nodes and expressions to create your work.

How much custom plugin development do you have to do with Houdini compared to 
Softimage, Maya, etc...?  Let's define a plugin as something you'd write as a 
script or C++ lib that gets included in the software as a reusable tool, 
perhaps providing it's own GUI front end (if applicable) and is responsible 
enough to do proper error checking (as opposed to a couple line hack script 
like many artists do).

Is there much of an SDK for writing GUI's as front ends for tools?


Matt

Re: Houdini Weaknesses

[Francois Lord]

Yeah, the only reason I have not yet dived into Houdini yet is because 
of lack of time. As soon as I can, I will be reading those pdfs.
But I do have to choose my next move not too late, for me and for the 
company I work for. Over here, we are 18 cg artists working in 
Softimage. No one is excited to learn Maya, but Im not sure we can skip 
it entirely. Houdini seems a good first step for look dev since Arnold 
is coming. We can keep rigging and Animation in Softimage for a while. 
Modeling can be done in any package, it doesn't matter.


F


On 21-May-14 17:59, Andy Nicholas wrote:

  BTW, it's worth saying that despite all the faults I've mentioned, I still 
love
using Houdini. Especially now that it's my main route of escape from the
wonderful world of Maya ;) And for those who are looking for a tool to support
complex effects, I'd totally recommend getting into it.

If you haven't checked out Jordi's PDFs on SideFX's website yet BTW, that should
be your first port of call as they're a great transitionary guide.


A




On 21 May 2014 at 22:16 Jordi Bares  wrote:


It is the same with any package the only thing is that Houdini artists tend to
be more of a peculiar type… you just have to make sure they stick to the
conventions like all Softimage users do (for example on how we setup passes)

Jordi Bares
jordiba...@gmail.com

On 21 May 2014, at 22:12, Andy Nicholas  wrote:


Sure. There's certainly a lot of potential there. It's just that the
openness
means that the workflow is very open to interpretation. Houdini's a bit like
coding, everyone has their own style so you can get in a mess. It's very
easy to
add in quick little "fixes" which other people might look on as hacks
instead.

A


On 21 May 2014 at 21:25 Francois Lord  wrote:


And how would it fare as a lighting/shading/rendering hub?
I'm very hesitant to move to Maya just for it's lack of a true a pass
system. But then, there's only Houdini and Katana. We could add to the
list Modo and Clarisse (which I'm surprised nobody talked about here
yet) but we need Arnold.

On 21-May-14 15:55, Andy Nicholas wrote:

  From my experience, it's still relatively slow. A lot of stuff is still
single
threaded although they've done a lot of work to improve that recently. Be
ready
to eat up a lot of disk space too, as you'll be caching stuff out all the
time
to make up for the lack of speed.


Despite what many say about Houdini being great for particles, compared to
ICE,
the particles workflow is bloody awful. The nodes are super basic which
means
you have to roll your own out of VOPs, which are then super slow. ICE and
Arnold
are a dream for instancing, but Houdini drives me insane with slow and
flaky
workflows (although I probably need to update my knowledge since some of
the
new
features have come out - e.g. packed primitives).


Generally in production, expect not to see any significant results out of
Houdini artists for the first 70-80% of the job. That can be a real pain
for
working with needy clients. Once you get past that point though, they'll
be
able
to turn new versions out very quickly. Unfortunately, if it doesn't look
good at
that point you've got a crap load of work to redo, and it can really bite
you in
the ass if you don't have a good backup plan.


When it comes to commercials, not a lot beats ICE and it's rigid body
implementation for speed and ease of use, and I really miss not having
that
in
Houdini. Doing simple stuff in Houdini's DOPs can require an hour of
research
trying to find out what data you need to modify, and how to actually
implement
it.

I could go on a lot longer, but all I'll say is that you have to be super
careful when you decide to throw a job at Houdini. Make sure you have R&D
time
built in if you haven't done a particular effect before.

A




On 21 May 2014 at 19:42 Francois Lord  wrote:


So...
What are houdini weaknesses? What is missing in Houdini compared to
Softimage? Would you run a company only using Houdini as 3D app? Why not?

Re: Houdini Weaknesses

[Andy Nicholas]

 Hehe! There you go, another variation ;) I've not tried that one, but that
sounds like a better way of going about it than my previous attempts with
instancing into subnets.






On 21 May 2014 at 22:57 Jordi Bares  wrote:

> I do miss XSI passes a bit… The thing as you know is that there is no the
> concept of passes, you can mimic it although not 100% so people just find
> their approach and become very proud of it not knowing XSI has the very finest
> system since day 1.
>
> I never use takes for passes but for overrides and use ROPs together with
> bundles instead of explicit references of "object merge" style approaches.
>
> The thing I am not sure i want to give up now is the approach of ROP networks
> dependencies so I can trigger very complex setups and simply go home.
>
> ;-)
>
> Jordi Bares
> jordiba...@gmail.com
>
> On 21 May 2014, at 22:51, Andy Nicholas  wrote:
>
> > Sure, conventions are always necessary, but more so with Houdini. Some
> > people
> > use Takes as passes, others use ROPs with object masks into subnets as
> > passes.
> > Or you could use a mix of the two approaches.
> >
> >
> > At least in Soft, passes are passes!
> >
> >
> > A
> >
> >
> >
> >
> > On 21 May 2014 at 22:16 Jordi Bares  wrote:
> >
> >> It is the same with any package the only thing is that Houdini artists tend
> >> to
> >> be more of a peculiar type… you just have to make sure they stick to the
> >> conventions like all Softimage users do (for example on how we setup
> >> passes)
> >>
> >> Jordi Bares
> >> jordiba...@gmail.com
> >>
> >> On 21 May 2014, at 22:12, Andy Nicholas  wrote:
> >>
> >>> Sure. There's certainly a lot of potential there. It's just that the
> >>> openness
> >>> means that the workflow is very open to interpretation. Houdini's a bit
> >>> like
> >>> coding, everyone has their own style so you can get in a mess. It's very
> >>> easy to
> >>> add in quick little "fixes" which other people might look on as hacks
> >>> instead.
> >>>
> >>> A
> >>>
> >>>
> >>> On 21 May 2014 at 21:25 Francois Lord  wrote:
> >>>
>  And how would it fare as a lighting/shading/rendering hub?
>  I'm very hesitant to move to Maya just for it's lack of a true a pass
>  system. But then, there's only Houdini and Katana. We could add to the
>  list Modo and Clarisse (which I'm surprised nobody talked about here
>  yet) but we need Arnold.
> 
>  On 21-May-14 15:55, Andy Nicholas wrote:
> > From my experience, it's still relatively slow. A lot of stuff is still
> > single
> > threaded although they've done a lot of work to improve that recently.
> > Be
> > ready
> > to eat up a lot of disk space too, as you'll be caching stuff out all
> > the
> > time
> > to make up for the lack of speed.
> >
> >
> > Despite what many say about Houdini being great for particles, compared
> > to
> > ICE,
> > the particles workflow is bloody awful. The nodes are super basic which
> > means
> > you have to roll your own out of VOPs, which are then super slow. ICE
> > and
> > Arnold
> > are a dream for instancing, but Houdini drives me insane with slow and
> > flaky
> > workflows (although I probably need to update my knowledge since some of
> > the
> > new
> > features have come out - e.g. packed primitives).
> >
> >
> > Generally in production, expect not to see any significant results out
> > of
> > Houdini artists for the first 70-80% of the job. That can be a real pain
> > for
> > working with needy clients. Once you get past that point though, they'll
> > be
> > able
> > to turn new versions out very quickly. Unfortunately, if it doesn't look
> > good at
> > that point you've got a crap load of work to redo, and it can really
> > bite
> > you in
> > the ass if you don't have a good backup plan.
> >
> >
> > When it comes to commercials, not a lot beats ICE and it's rigid body
> > implementation for speed and ease of use, and I really miss not having
> > that
> > in
> > Houdini. Doing simple stuff in Houdini's DOPs can require an hour of
> > research
> > trying to find out what data you need to modify, and how to actually
> > implement
> > it.
> >
> > I could go on a lot longer, but all I'll say is that you have to be
> > super
> > careful when you decide to throw a job at Houdini. Make sure you have
> > R&D
> > time
> > built in if you haven't done a particular effect before.
> >
> > A
> >
> >
> >
> >
> > On 21 May 2014 at 19:42 Francois Lord  wrote:
> >
> >> So...
> >> What are houdini weaknesses? What is missing in Houdini compared to
> >> Softimage? Would you run a company only using Houdini as 3D app? Why
> >> not?
> 
> >>
>

Re: Houdini Weaknesses

[Andy Nicholas]

 BTW, it's worth saying that despite all the faults I've mentioned, I still love
using Houdini. Especially now that it's my main route of escape from the
wonderful world of Maya ;) And for those who are looking for a tool to support
complex effects, I'd totally recommend getting into it.

If you haven't checked out Jordi's PDFs on SideFX's website yet BTW, that should
be your first port of call as they're a great transitionary guide.


A




On 21 May 2014 at 22:16 Jordi Bares  wrote:

> It is the same with any package the only thing is that Houdini artists tend to
> be more of a peculiar type… you just have to make sure they stick to the
> conventions like all Softimage users do (for example on how we setup passes)
>
> Jordi Bares
> jordiba...@gmail.com
>
> On 21 May 2014, at 22:12, Andy Nicholas  wrote:
>
> > Sure. There's certainly a lot of potential there. It's just that the
> > openness
> > means that the workflow is very open to interpretation. Houdini's a bit like
> > coding, everyone has their own style so you can get in a mess. It's very
> > easy to
> > add in quick little "fixes" which other people might look on as hacks
> > instead.
> >
> > A
> >
> >
> > On 21 May 2014 at 21:25 Francois Lord  wrote:
> >
> >> And how would it fare as a lighting/shading/rendering hub?
> >> I'm very hesitant to move to Maya just for it's lack of a true a pass
> >> system. But then, there's only Houdini and Katana. We could add to the
> >> list Modo and Clarisse (which I'm surprised nobody talked about here
> >> yet) but we need Arnold.
> >>
> >> On 21-May-14 15:55, Andy Nicholas wrote:
> >>>  From my experience, it's still relatively slow. A lot of stuff is still
> >>> single
> >>> threaded although they've done a lot of work to improve that recently. Be
> >>> ready
> >>> to eat up a lot of disk space too, as you'll be caching stuff out all the
> >>> time
> >>> to make up for the lack of speed.
> >>>
> >>>
> >>> Despite what many say about Houdini being great for particles, compared to
> >>> ICE,
> >>> the particles workflow is bloody awful. The nodes are super basic which
> >>> means
> >>> you have to roll your own out of VOPs, which are then super slow. ICE and
> >>> Arnold
> >>> are a dream for instancing, but Houdini drives me insane with slow and
> >>> flaky
> >>> workflows (although I probably need to update my knowledge since some of
> >>> the
> >>> new
> >>> features have come out - e.g. packed primitives).
> >>>
> >>>
> >>> Generally in production, expect not to see any significant results out of
> >>> Houdini artists for the first 70-80% of the job. That can be a real pain
> >>> for
> >>> working with needy clients. Once you get past that point though, they'll
> >>> be
> >>> able
> >>> to turn new versions out very quickly. Unfortunately, if it doesn't look
> >>> good at
> >>> that point you've got a crap load of work to redo, and it can really bite
> >>> you in
> >>> the ass if you don't have a good backup plan.
> >>>
> >>>
> >>> When it comes to commercials, not a lot beats ICE and it's rigid body
> >>> implementation for speed and ease of use, and I really miss not having
> >>> that
> >>> in
> >>> Houdini. Doing simple stuff in Houdini's DOPs can require an hour of
> >>> research
> >>> trying to find out what data you need to modify, and how to actually
> >>> implement
> >>> it.
> >>>
> >>> I could go on a lot longer, but all I'll say is that you have to be super
> >>> careful when you decide to throw a job at Houdini. Make sure you have R&D
> >>> time
> >>> built in if you haven't done a particular effect before.
> >>>
> >>> A
> >>>
> >>>
> >>>
> >>>
> >>> On 21 May 2014 at 19:42 Francois Lord  wrote:
> >>>
>  So...
>  What are houdini weaknesses? What is missing in Houdini compared to
>  Softimage? Would you run a company only using Houdini as 3D app? Why not?
> >>
>

Re: Houdini Weaknesses

[Jordi Bares]

I do miss XSI passes a bit… The thing as you know is that there is no the 
concept of passes, you can mimic it although not 100% so people just find their 
approach and become very proud of it not knowing XSI has the very finest system 
since day 1.

I never use takes for passes but for overrides and use ROPs together with 
bundles instead of explicit references of "object merge" style approaches.

The thing I am not sure i want to give up now is the approach of ROP networks 
dependencies so I can trigger very complex setups and simply go home.

;-)

Jordi Bares
jordiba...@gmail.com

On 21 May 2014, at 22:51, Andy Nicholas  wrote:

> Sure, conventions are always necessary, but more so with Houdini. Some people
> use Takes as passes, others use ROPs with object masks into subnets as passes.
> Or you could use a mix of the two approaches.
> 
> 
> At least in Soft, passes are passes!
> 
> 
> A
> 
> 
> 
> 
> On 21 May 2014 at 22:16 Jordi Bares  wrote:
> 
>> It is the same with any package the only thing is that Houdini artists tend 
>> to
>> be more of a peculiar type… you just have to make sure they stick to the
>> conventions like all Softimage users do (for example on how we setup passes)
>> 
>> Jordi Bares
>> jordiba...@gmail.com
>> 
>> On 21 May 2014, at 22:12, Andy Nicholas  wrote:
>> 
>>> Sure. There's certainly a lot of potential there. It's just that the
>>> openness
>>> means that the workflow is very open to interpretation. Houdini's a bit like
>>> coding, everyone has their own style so you can get in a mess. It's very
>>> easy to
>>> add in quick little "fixes" which other people might look on as hacks
>>> instead.
>>> 
>>> A
>>> 
>>> 
>>> On 21 May 2014 at 21:25 Francois Lord  wrote:
>>> 
 And how would it fare as a lighting/shading/rendering hub?
 I'm very hesitant to move to Maya just for it's lack of a true a pass
 system. But then, there's only Houdini and Katana. We could add to the
 list Modo and Clarisse (which I'm surprised nobody talked about here
 yet) but we need Arnold.
 
 On 21-May-14 15:55, Andy Nicholas wrote:
> From my experience, it's still relatively slow. A lot of stuff is still
> single
> threaded although they've done a lot of work to improve that recently. Be
> ready
> to eat up a lot of disk space too, as you'll be caching stuff out all the
> time
> to make up for the lack of speed.
> 
> 
> Despite what many say about Houdini being great for particles, compared to
> ICE,
> the particles workflow is bloody awful. The nodes are super basic which
> means
> you have to roll your own out of VOPs, which are then super slow. ICE and
> Arnold
> are a dream for instancing, but Houdini drives me insane with slow and
> flaky
> workflows (although I probably need to update my knowledge since some of
> the
> new
> features have come out - e.g. packed primitives).
> 
> 
> Generally in production, expect not to see any significant results out of
> Houdini artists for the first 70-80% of the job. That can be a real pain
> for
> working with needy clients. Once you get past that point though, they'll
> be
> able
> to turn new versions out very quickly. Unfortunately, if it doesn't look
> good at
> that point you've got a crap load of work to redo, and it can really bite
> you in
> the ass if you don't have a good backup plan.
> 
> 
> When it comes to commercials, not a lot beats ICE and it's rigid body
> implementation for speed and ease of use, and I really miss not having
> that
> in
> Houdini. Doing simple stuff in Houdini's DOPs can require an hour of
> research
> trying to find out what data you need to modify, and how to actually
> implement
> it.
> 
> I could go on a lot longer, but all I'll say is that you have to be super
> careful when you decide to throw a job at Houdini. Make sure you have R&D
> time
> built in if you haven't done a particular effect before.
> 
> A
> 
> 
> 
> 
> On 21 May 2014 at 19:42 Francois Lord  wrote:
> 
>> So...
>> What are houdini weaknesses? What is missing in Houdini compared to
>> Softimage? Would you run a company only using Houdini as 3D app? Why not?
 
>> 

Re: Houdini Weaknesses

[Andy Nicholas]

 Sure, conventions are always necessary, but more so with Houdini. Some people
use Takes as passes, others use ROPs with object masks into subnets as passes.
Or you could use a mix of the two approaches.


At least in Soft, passes are passes!


A




On 21 May 2014 at 22:16 Jordi Bares  wrote:

> It is the same with any package the only thing is that Houdini artists tend to
> be more of a peculiar type… you just have to make sure they stick to the
> conventions like all Softimage users do (for example on how we setup passes)
>
> Jordi Bares
> jordiba...@gmail.com
>
> On 21 May 2014, at 22:12, Andy Nicholas  wrote:
>
> > Sure. There's certainly a lot of potential there. It's just that the
> > openness
> > means that the workflow is very open to interpretation. Houdini's a bit like
> > coding, everyone has their own style so you can get in a mess. It's very
> > easy to
> > add in quick little "fixes" which other people might look on as hacks
> > instead.
> >
> > A
> >
> >
> > On 21 May 2014 at 21:25 Francois Lord  wrote:
> >
> >> And how would it fare as a lighting/shading/rendering hub?
> >> I'm very hesitant to move to Maya just for it's lack of a true a pass
> >> system. But then, there's only Houdini and Katana. We could add to the
> >> list Modo and Clarisse (which I'm surprised nobody talked about here
> >> yet) but we need Arnold.
> >>
> >> On 21-May-14 15:55, Andy Nicholas wrote:
> >>>  From my experience, it's still relatively slow. A lot of stuff is still
> >>> single
> >>> threaded although they've done a lot of work to improve that recently. Be
> >>> ready
> >>> to eat up a lot of disk space too, as you'll be caching stuff out all the
> >>> time
> >>> to make up for the lack of speed.
> >>>
> >>>
> >>> Despite what many say about Houdini being great for particles, compared to
> >>> ICE,
> >>> the particles workflow is bloody awful. The nodes are super basic which
> >>> means
> >>> you have to roll your own out of VOPs, which are then super slow. ICE and
> >>> Arnold
> >>> are a dream for instancing, but Houdini drives me insane with slow and
> >>> flaky
> >>> workflows (although I probably need to update my knowledge since some of
> >>> the
> >>> new
> >>> features have come out - e.g. packed primitives).
> >>>
> >>>
> >>> Generally in production, expect not to see any significant results out of
> >>> Houdini artists for the first 70-80% of the job. That can be a real pain
> >>> for
> >>> working with needy clients. Once you get past that point though, they'll
> >>> be
> >>> able
> >>> to turn new versions out very quickly. Unfortunately, if it doesn't look
> >>> good at
> >>> that point you've got a crap load of work to redo, and it can really bite
> >>> you in
> >>> the ass if you don't have a good backup plan.
> >>>
> >>>
> >>> When it comes to commercials, not a lot beats ICE and it's rigid body
> >>> implementation for speed and ease of use, and I really miss not having
> >>> that
> >>> in
> >>> Houdini. Doing simple stuff in Houdini's DOPs can require an hour of
> >>> research
> >>> trying to find out what data you need to modify, and how to actually
> >>> implement
> >>> it.
> >>>
> >>> I could go on a lot longer, but all I'll say is that you have to be super
> >>> careful when you decide to throw a job at Houdini. Make sure you have R&D
> >>> time
> >>> built in if you haven't done a particular effect before.
> >>>
> >>> A
> >>>
> >>>
> >>>
> >>>
> >>> On 21 May 2014 at 19:42 Francois Lord  wrote:
> >>>
>  So...
>  What are houdini weaknesses? What is missing in Houdini compared to
>  Softimage? Would you run a company only using Houdini as 3D app? Why not?
> >>
>

Re: SI and Houdini

[Sebastian Kowalski]

I am experiencing the same. Amazed by it actually.
And all the sexy things one can do in a ROP Network.. 
Never would thought of XSI pass system being too rigid. 



Am 21.05.2014 um 20:33 schrieb Andy Goehler :

> 
> 
>> On 21.05.2014, at 19:35, Ciaran Moloney  wrote:
>> 
>> Mantra aint too shabby...
> 
> I'm running a test scene and surprisingly Mantra keeps pace with Arnold 
> speed/quality wise (brute force). I really like all the options that Mantra 
> brings along. There's is an unmatched flexibility with lights, objects and 
> shaders with Mantra all inside Houdini without having to resort to external 
> C++ IDEs.
> 
> Andy

Re: Houdini Weaknesses

[Jordi Bares]

It is the same with any package the only thing is that Houdini artists tend to 
be more of a peculiar type… you just have to make sure they stick to the 
conventions like all Softimage users do (for example on how we setup passes)

Jordi Bares
jordiba...@gmail.com

On 21 May 2014, at 22:12, Andy Nicholas  wrote:

> Sure. There's certainly a lot of potential there. It's just that the openness
> means that the workflow is very open to interpretation. Houdini's a bit like
> coding, everyone has their own style so you can get in a mess. It's very easy 
> to
> add in quick little "fixes" which other people might look on as hacks instead.
> 
> A
> 
> 
> On 21 May 2014 at 21:25 Francois Lord  wrote:
> 
>> And how would it fare as a lighting/shading/rendering hub?
>> I'm very hesitant to move to Maya just for it's lack of a true a pass
>> system. But then, there's only Houdini and Katana. We could add to the
>> list Modo and Clarisse (which I'm surprised nobody talked about here
>> yet) but we need Arnold.
>> 
>> On 21-May-14 15:55, Andy Nicholas wrote:
>>>  From my experience, it's still relatively slow. A lot of stuff is still
>>> single
>>> threaded although they've done a lot of work to improve that recently. Be
>>> ready
>>> to eat up a lot of disk space too, as you'll be caching stuff out all the
>>> time
>>> to make up for the lack of speed.
>>> 
>>> 
>>> Despite what many say about Houdini being great for particles, compared to
>>> ICE,
>>> the particles workflow is bloody awful. The nodes are super basic which
>>> means
>>> you have to roll your own out of VOPs, which are then super slow. ICE and
>>> Arnold
>>> are a dream for instancing, but Houdini drives me insane with slow and flaky
>>> workflows (although I probably need to update my knowledge since some of the
>>> new
>>> features have come out - e.g. packed primitives).
>>> 
>>> 
>>> Generally in production, expect not to see any significant results out of
>>> Houdini artists for the first 70-80% of the job. That can be a real pain for
>>> working with needy clients. Once you get past that point though, they'll be
>>> able
>>> to turn new versions out very quickly. Unfortunately, if it doesn't look
>>> good at
>>> that point you've got a crap load of work to redo, and it can really bite
>>> you in
>>> the ass if you don't have a good backup plan.
>>> 
>>> 
>>> When it comes to commercials, not a lot beats ICE and it's rigid body
>>> implementation for speed and ease of use, and I really miss not having that
>>> in
>>> Houdini. Doing simple stuff in Houdini's DOPs can require an hour of
>>> research
>>> trying to find out what data you need to modify, and how to actually
>>> implement
>>> it.
>>> 
>>> I could go on a lot longer, but all I'll say is that you have to be super
>>> careful when you decide to throw a job at Houdini. Make sure you have R&D
>>> time
>>> built in if you haven't done a particular effect before.
>>> 
>>> A
>>> 
>>> 
>>> 
>>> 
>>> On 21 May 2014 at 19:42 Francois Lord  wrote:
>>> 
 So...
 What are houdini weaknesses? What is missing in Houdini compared to
 Softimage? Would you run a company only using Houdini as 3D app? Why not?
>> 

Re: Houdini Weaknesses

[Jordi Bares]

Houdini, like Maya, Softimage, Modo, Cinema4D, Max, etc… is not perfect and has 
some flaws.

In my opinion after doing the transition I still miss a few things but these 
are the key ones

- Procedural modelling is useful but the whole non-procedural workflow is in 
this age very bad, for this reason all Houdini artists either rely on a 
modeller using whatever that guy likes or simply use a Zbrush + retopology 
approach. So no biggie but for small things is a pain in the ass.

- Viewport is not great, and specially the whole application is not really 
viewport centric so you can see the tools operate mostly on the network view 
with some quirky approach to the viewport (for mirroring skeletons is an 
operation done on the viewport, a non-procedural one) So you will get used like 
me but won't like it.

- Shading is very granular and the examples and setups provided are not very 
good so once you get it is good but not great yet. The actual implementation of 
Arnold for Houdini is s much user friendly (looks a quite a lot like the 
render tree to be honest)

- Animation tools are not there yet, not too bad but you will miss the mixer 
and specially the animation layers. I don't particularly like the f-curve 
interpolation but that is not that big of a deal really.

All in all these are my issues with Houdini, the good news is that they are 
working on these so we may find a first batch of improvements very very soon 
which will make it easier to access.

Regarding some comments about Houdini, it may be a bit slower as the 
multithreading is not being finished, there were massive improvements on the 
last versions (some nodes running 2500x faster) so together with new OpenCL 
support and multithreading on the pipe this problem should be gone (just look 
at Pyro with a proper K5000 graphic card and you will see what I mean)

Regarding talent the truth is that mostly are FXTD and it shows in how they 
work and the training has been geared towards that as sidefx did want to 
position themselves there and truly they are untouchable on that area but yes, 
you needs some good people supporting a bigger team.

Regarding artist friendliness, it is simply that it is quite different in 
approach but like Zbrush, once you pass that point which is not that hard (look 
at my transition guides here 
http://www.sidefx.com/index.php?option=com_content&task=view&id=2711&Itemid=132 
you will see it is pretty similar to XSI.

Regarding the learning curve, if you want to get directly into dynamics, 
particles and vex then be prepared to dive into some more complex stuff, I 
would recommend to start with the basis and you will feel comfortable quickly.

It is very true as Andy pointed that Houdini is very granular (for example, 
only recently you see flocking as a tool, till now the approach was for you to 
build it your way) but the attitude is changing fast and you can see Side 
Effects responding quickly. 

Regarding Softimage I would put it this way, I still love it and even with the 
lack of proper muscle deformers, limit with number of objects, awful viewport 
and pretty bad sdk documentation I still think is the best 3D tool but the 
problem is that the very clever people at Autodesk has killed it so no very 
good.


As I said, I could set a list of things I don't like about every single 
particular package, to me the fact that houdini scales massively to 
super-complex stuff you can't even open in Maya or Softimage plus the fact they 
have the best support makes me thing is the best bet for my career. Plus you 
get paid more and do the really nice stuff.  ;-)

So again, would I configure a studio with Houdini as the only package? well, 
that is my daily basis and works very very well although of course I have 
around me a few true experts.

Would I set it up with Softimage instead if was still available? oh man, yes… 
would get both in fact!!!

hope that helps.


Jordi Bares
jordiba...@gmail.com

On 21 May 2014, at 19:42, Francois Lord  wrote:

> So...
> What are houdini weaknesses? What is missing in Houdini compared to 
> Softimage? Would you run a company only using Houdini as 3D app? Why not?

Re: Houdini Weaknesses

[Andy Nicholas]

 Sure. There's certainly a lot of potential there. It's just that the openness
means that the workflow is very open to interpretation. Houdini's a bit like
coding, everyone has their own style so you can get in a mess. It's very easy to
add in quick little "fixes" which other people might look on as hacks instead.

A


On 21 May 2014 at 21:25 Francois Lord  wrote:

> And how would it fare as a lighting/shading/rendering hub?
> I'm very hesitant to move to Maya just for it's lack of a true a pass
> system. But then, there's only Houdini and Katana. We could add to the
> list Modo and Clarisse (which I'm surprised nobody talked about here
> yet) but we need Arnold.
>
> On 21-May-14 15:55, Andy Nicholas wrote:
> >   From my experience, it's still relatively slow. A lot of stuff is still
> > single
> > threaded although they've done a lot of work to improve that recently. Be
> > ready
> > to eat up a lot of disk space too, as you'll be caching stuff out all the
> > time
> > to make up for the lack of speed.
> >
> >
> > Despite what many say about Houdini being great for particles, compared to
> > ICE,
> > the particles workflow is bloody awful. The nodes are super basic which
> > means
> > you have to roll your own out of VOPs, which are then super slow. ICE and
> > Arnold
> > are a dream for instancing, but Houdini drives me insane with slow and flaky
> > workflows (although I probably need to update my knowledge since some of the
> > new
> > features have come out - e.g. packed primitives).
> >
> >
> > Generally in production, expect not to see any significant results out of
> > Houdini artists for the first 70-80% of the job. That can be a real pain for
> > working with needy clients. Once you get past that point though, they'll be
> > able
> > to turn new versions out very quickly. Unfortunately, if it doesn't look
> > good at
> > that point you've got a crap load of work to redo, and it can really bite
> > you in
> > the ass if you don't have a good backup plan.
> >
> >
> > When it comes to commercials, not a lot beats ICE and it's rigid body
> > implementation for speed and ease of use, and I really miss not having that
> > in
> > Houdini. Doing simple stuff in Houdini's DOPs can require an hour of
> > research
> > trying to find out what data you need to modify, and how to actually
> > implement
> > it.
> >
> > I could go on a lot longer, but all I'll say is that you have to be super
> > careful when you decide to throw a job at Houdini. Make sure you have R&D
> > time
> > built in if you haven't done a particular effect before.
> >
> > A
> >
> >
> >
> >
> > On 21 May 2014 at 19:42 Francois Lord  wrote:
> >
> >> So...
> >> What are houdini weaknesses? What is missing in Houdini compared to
> >> Softimage? Would you run a company only using Houdini as 3D app? Why not?
>

RPF files?

[John Richard Sanchez]

Is there any way to render out .rpf files from XSI?
Thanks
John

-- 
www.johnrichardsanchez.com

Re: Houdini Weaknesses

[Sebastien Sterling]

can't mtoa bypass maya's shitty pass system ?


On 21 May 2014 21:25, Francois Lord  wrote:

> And how would it fare as a lighting/shading/rendering hub?
> I'm very hesitant to move to Maya just for it's lack of a true a pass
> system. But then, there's only Houdini and Katana. We could add to the list
> Modo and Clarisse (which I'm surprised nobody talked about here yet) but we
> need Arnold.
>
>
> On 21-May-14 15:55, Andy Nicholas wrote:
>
>>   From my experience, it's still relatively slow. A lot of stuff is still
>> single
>> threaded although they've done a lot of work to improve that recently. Be
>> ready
>> to eat up a lot of disk space too, as you'll be caching stuff out all the
>> time
>> to make up for the lack of speed.
>>
>>
>> Despite what many say about Houdini being great for particles, compared
>> to ICE,
>> the particles workflow is bloody awful. The nodes are super basic which
>> means
>> you have to roll your own out of VOPs, which are then super slow. ICE and
>> Arnold
>> are a dream for instancing, but Houdini drives me insane with slow and
>> flaky
>> workflows (although I probably need to update my knowledge since some of
>> the new
>> features have come out - e.g. packed primitives).
>>
>>
>> Generally in production, expect not to see any significant results out of
>> Houdini artists for the first 70-80% of the job. That can be a real pain
>> for
>> working with needy clients. Once you get past that point though, they'll
>> be able
>> to turn new versions out very quickly. Unfortunately, if it doesn't look
>> good at
>> that point you've got a crap load of work to redo, and it can really bite
>> you in
>> the ass if you don't have a good backup plan.
>>
>>
>> When it comes to commercials, not a lot beats ICE and it's rigid body
>> implementation for speed and ease of use, and I really miss not having
>> that in
>> Houdini. Doing simple stuff in Houdini's DOPs can require an hour of
>> research
>> trying to find out what data you need to modify, and how to actually
>> implement
>> it.
>>
>> I could go on a lot longer, but all I'll say is that you have to be super
>> careful when you decide to throw a job at Houdini. Make sure you have R&D
>> time
>> built in if you haven't done a particular effect before.
>>
>> A
>>
>>
>>
>>
>> On 21 May 2014 at 19:42 Francois Lord  wrote:
>>
>>  So...
>>> What are houdini weaknesses? What is missing in Houdini compared to
>>> Softimage? Would you run a company only using Houdini as 3D app? Why not?
>>>
>>
>

Re: Houdini Weaknesses

[Meng-Yang Lu]

I really like the idea of Houdini as the hub for lighting.  Considering
most FX are now done in Houdini anyway, it sort of houses two rather
complex aspects of CG really nicely.

ROPs isn't really a pass system but think of it more like separable render
globals for all outputs.  Probably one of the least touted feature of
Houdini but definitely one of the most luxurious feature set.  You can pick
and choose to your hearts desire what can be done via AOVs, what grouping
of ROPs you want to use, and what should be overidden via Takes (though
usually shyed away from).

We've had Maya guys migrate over feeling really bummed having to go back to
Maya's pass system.

-Lu


On Wed, May 21, 2014 at 1:25 PM, Francois Lord  wrote:

> And how would it fare as a lighting/shading/rendering hub?
> I'm very hesitant to move to Maya just for it's lack of a true a pass
> system. But then, there's only Houdini and Katana. We could add to the list
> Modo and Clarisse (which I'm surprised nobody talked about here yet) but we
> need Arnold.
>
>
> On 21-May-14 15:55, Andy Nicholas wrote:
>
>>   From my experience, it's still relatively slow. A lot of stuff is still
>> single
>> threaded although they've done a lot of work to improve that recently. Be
>> ready
>> to eat up a lot of disk space too, as you'll be caching stuff out all the
>> time
>> to make up for the lack of speed.
>>
>>
>> Despite what many say about Houdini being great for particles, compared
>> to ICE,
>> the particles workflow is bloody awful. The nodes are super basic which
>> means
>> you have to roll your own out of VOPs, which are then super slow. ICE and
>> Arnold
>> are a dream for instancing, but Houdini drives me insane with slow and
>> flaky
>> workflows (although I probably need to update my knowledge since some of
>> the new
>> features have come out - e.g. packed primitives).
>>
>>
>> Generally in production, expect not to see any significant results out of
>> Houdini artists for the first 70-80% of the job. That can be a real pain
>> for
>> working with needy clients. Once you get past that point though, they'll
>> be able
>> to turn new versions out very quickly. Unfortunately, if it doesn't look
>> good at
>> that point you've got a crap load of work to redo, and it can really bite
>> you in
>> the ass if you don't have a good backup plan.
>>
>>
>> When it comes to commercials, not a lot beats ICE and it's rigid body
>> implementation for speed and ease of use, and I really miss not having
>> that in
>> Houdini. Doing simple stuff in Houdini's DOPs can require an hour of
>> research
>> trying to find out what data you need to modify, and how to actually
>> implement
>> it.
>>
>> I could go on a lot longer, but all I'll say is that you have to be super
>> careful when you decide to throw a job at Houdini. Make sure you have R&D
>> time
>> built in if you haven't done a particular effect before.
>>
>> A
>>
>>
>>
>>
>> On 21 May 2014 at 19:42 Francois Lord  wrote:
>>
>>  So...
>>> What are houdini weaknesses? What is missing in Houdini compared to
>>> Softimage? Would you run a company only using Houdini as 3D app? Why not?
>>>
>>
>

Re: Houdini Weaknesses

[Francois Lord]

And how would it fare as a lighting/shading/rendering hub?
I'm very hesitant to move to Maya just for it's lack of a true a pass 
system. But then, there's only Houdini and Katana. We could add to the 
list Modo and Clarisse (which I'm surprised nobody talked about here 
yet) but we need Arnold.


On 21-May-14 15:55, Andy Nicholas wrote:

  From my experience, it's still relatively slow. A lot of stuff is still single
threaded although they've done a lot of work to improve that recently. Be ready
to eat up a lot of disk space too, as you'll be caching stuff out all the time
to make up for the lack of speed.


Despite what many say about Houdini being great for particles, compared to ICE,
the particles workflow is bloody awful. The nodes are super basic which means
you have to roll your own out of VOPs, which are then super slow. ICE and Arnold
are a dream for instancing, but Houdini drives me insane with slow and flaky
workflows (although I probably need to update my knowledge since some of the new
features have come out - e.g. packed primitives).


Generally in production, expect not to see any significant results out of
Houdini artists for the first 70-80% of the job. That can be a real pain for
working with needy clients. Once you get past that point though, they'll be able
to turn new versions out very quickly. Unfortunately, if it doesn't look good at
that point you've got a crap load of work to redo, and it can really bite you in
the ass if you don't have a good backup plan.


When it comes to commercials, not a lot beats ICE and it's rigid body
implementation for speed and ease of use, and I really miss not having that in
Houdini. Doing simple stuff in Houdini's DOPs can require an hour of research
trying to find out what data you need to modify, and how to actually implement
it.

I could go on a lot longer, but all I'll say is that you have to be super
careful when you decide to throw a job at Houdini. Make sure you have R&D time
built in if you haven't done a particular effect before.

A




On 21 May 2014 at 19:42 Francois Lord  wrote:


So...
What are houdini weaknesses? What is missing in Houdini compared to
Softimage? Would you run a company only using Houdini as 3D app? Why not?

Re: Houdini Weaknesses

[Andy Nicholas]

 From my experience, it's still relatively slow. A lot of stuff is still single
threaded although they've done a lot of work to improve that recently. Be ready
to eat up a lot of disk space too, as you'll be caching stuff out all the time
to make up for the lack of speed.


Despite what many say about Houdini being great for particles, compared to ICE,
the particles workflow is bloody awful. The nodes are super basic which means
you have to roll your own out of VOPs, which are then super slow. ICE and Arnold
are a dream for instancing, but Houdini drives me insane with slow and flaky
workflows (although I probably need to update my knowledge since some of the new
features have come out - e.g. packed primitives).


Generally in production, expect not to see any significant results out of
Houdini artists for the first 70-80% of the job. That can be a real pain for
working with needy clients. Once you get past that point though, they'll be able
to turn new versions out very quickly. Unfortunately, if it doesn't look good at
that point you've got a crap load of work to redo, and it can really bite you in
the ass if you don't have a good backup plan.


When it comes to commercials, not a lot beats ICE and it's rigid body
implementation for speed and ease of use, and I really miss not having that in
Houdini. Doing simple stuff in Houdini's DOPs can require an hour of research
trying to find out what data you need to modify, and how to actually implement
it.

I could go on a lot longer, but all I'll say is that you have to be super
careful when you decide to throw a job at Houdini. Make sure you have R&D time
built in if you haven't done a particular effect before.

A




On 21 May 2014 at 19:42 Francois Lord  wrote:

> So...
> What are houdini weaknesses? What is missing in Houdini compared to
> Softimage? Would you run a company only using Houdini as 3D app? Why not?

Re: Houdini Weaknesses

[Jon Swindells]

houdini is pretty much where it was 6yrs ago, utterly fantastic
procedural workflow. abysmal for anything else,



normal modelling tasks are painful. forget uv/topo work. the tools just
aren't there and the selection model gets in the way.



rigging is light years ahead of anything i've ever seen but it's mostly
moot because the anim workflow is dire compared to xsi (or any other
app for that matter)



sim/fx - no real need to comment on this other than to utter 'sweet
mother of god!! look at the waves!' :)



mantra is the poodles plums



the glsl implementation has the potential to make vp 2.0 look like s/w
TnL - i got matcap, a rudimentary grease pencil and currently having a
go at getting a pixar style rig selection/manip workflow going.
viewport tech is fantastic













i'm having a rather bizarre time with houdini.



--
Jon Swindells
jon_swinde...@fastmail.fm





On Wed, May 21, 2014, at 09:59 PM, Sebastien Sterling wrote:

well... there's no organic modeling ?



On 21 May 2014 19:42, Francois Lord <[1]flordli...@gmail.com> wrote:

So...

What are houdini weaknesses? What is missing in Houdini compared to
Softimage? Would you run a company only using Houdini as 3D app? Why
not?

References

1. mailto:flordli...@gmail.com

Re: Houdini Weaknesses

[Oscar Juarez]

About the Arnold Support, there is indeed arnold support.

https://vimeo.com/81443048


On Wed, May 21, 2014 at 9:01 PM, Ed Manning  wrote:

> For NYC anyway, the main weakness is the small base of trained artists.
> Then there's the fact that most of them are fairly senior TD-types who
> charge justifiably high rates, and are either overqualified for most
> artist-level assignments, or just not character animators since most of the
> Houdini artists I know are focused on FX and sim work (assuming that
> Houdini's character animation tools are in fact up to the job). Then
> there's the relatively high cost of Houdini itself, the lack of Arnold
> support, the steep learning curve that makes it hard to train anyone but a
> dedicated staff artist in Houdini...
>
> Don't misunderstand -- it's an awesomely powerful tool in the right hands;
> I wish I had taken the time to learn it years ago.  But just as I wouldn't
> want to run a woodshop that did all of its work using, say, CNC mills and
> lathes instead of hand tools, I wouldn't want to run a small commercial CG
> shop with just Houdini.  I mean, you *could* do it, and the work could be
> done at awesome quality, but it would be pretty strange workflow at times
> and very expensive I think.
>
>
>

Re: Houdini Weaknesses

[Sergio Mucino]

My personal experience it's that it's not an artist-friendly tool. It's 
incredibly powerful, but it requires quite a bit of technical knowledge and the 
learning curve is steep. I know many artists (modelers, animators, environment 
artists) that the moment you bring up a graph, they start bleeding from the 
nose. It's hard to avoid these workflows in Houdini. 
I'm not sure I would solely re a production in Houdini purely for this aspect. 
However, complimenting it with a more "traditional" DCC, it'd make up for a 
killer combo. 

Sergio Muciño.
Sent from my iPad.

> On May 21, 2014, at 3:01 PM, Ed Manning  wrote:
> 
> For NYC anyway, the main weakness is the small base of trained artists. Then 
> there's the fact that most of them are fairly senior TD-types who charge 
> justifiably high rates, and are either overqualified for most artist-level 
> assignments, or just not character animators since most of the Houdini 
> artists I know are focused on FX and sim work (assuming that Houdini's 
> character animation tools are in fact up to the job). Then there's the 
> relatively high cost of Houdini itself, the lack of Arnold support, the steep 
> learning curve that makes it hard to train anyone but a dedicated staff 
> artist in Houdini...
> 
> Don't misunderstand -- it's an awesomely powerful tool in the right hands; I 
> wish I had taken the time to learn it years ago.  But just as I wouldn't want 
> to run a woodshop that did all of its work using, say, CNC mills and lathes 
> instead of hand tools, I wouldn't want to run a small commercial CG shop with 
> just Houdini.  I mean, you *could* do it, and the work could be done at 
> awesome quality, but it would be pretty strange workflow at times and very 
> expensive I think.
> 
> 

Re: Houdini Weaknesses

[Ed Manning]

For NYC anyway, the main weakness is the small base of trained artists.
Then there's the fact that most of them are fairly senior TD-types who
charge justifiably high rates, and are either overqualified for most
artist-level assignments, or just not character animators since most of the
Houdini artists I know are focused on FX and sim work (assuming that
Houdini's character animation tools are in fact up to the job). Then
there's the relatively high cost of Houdini itself, the lack of Arnold
support, the steep learning curve that makes it hard to train anyone but a
dedicated staff artist in Houdini...

Don't misunderstand -- it's an awesomely powerful tool in the right hands;
I wish I had taken the time to learn it years ago.  But just as I wouldn't
want to run a woodshop that did all of its work using, say, CNC mills and
lathes instead of hand tools, I wouldn't want to run a small commercial CG
shop with just Houdini.  I mean, you *could* do it, and the work could be
done at awesome quality, but it would be pretty strange workflow at times
and very expensive I think.

Re: Houdini Weaknesses

[Sebastien Sterling]

well... there's no organic modeling ?


On 21 May 2014 19:42, Francois Lord  wrote:

> So...
> What are houdini weaknesses? What is missing in Houdini compared to
> Softimage? Would you run a company only using Houdini as 3D app? Why not?
>

Re: Houdini Weaknesses

[Artur Woźniak]

Learning Curve

Wysłane z iPhone'a

Dnia 21 maj 2014 o godz. 20:42 Francois Lord  napisał(a):

> So...
> What are houdini weaknesses? What is missing in Houdini compared to 
> Softimage? Would you run a company only using Houdini as 3D app? Why not?

Houdini Weaknesses

[Francois Lord]

So...
What are houdini weaknesses? What is missing in Houdini compared to 
Softimage? Would you run a company only using Houdini as 3D app? Why not?

Re: SI and Houdini

[Andy Goehler]

> On 21.05.2014, at 19:35, Ciaran Moloney  wrote:
> 
> Mantra aint too shabby...

I'm running a test scene and surprisingly Mantra keeps pace with Arnold 
speed/quality wise (brute force). I really like all the options that Mantra 
brings along. There's is an unmatched flexibility with lights, objects and 
shaders with Mantra all inside Houdini without having to resort to external C++ 
IDEs.

Andy

Re: SI and Houdini

[Jordi Bares]

Once you mix it with VEX it is pretty formidable what you can do with it...

Jordi Bares
jordiba...@gmail.com

On 21 May 2014, at 18:35, Ciaran Moloney  wrote:

> Mantra aint too shabby...
> 
> 
> On Wed, May 21, 2014 at 3:08 AM, Sylvain Lebeau  wrote:
> My God Jordi
> 
> I am playing around with Houdini for the render sides of things with Arnold 
> these days We already use it for VFX in a somehow encapsulated way.
> 
> And I just finished reading all of your pdfs. Except for animation and 
> rigging. 
> Your guides are such invaluable help and incredibly informative.  My eyes are 
> so wide opened now that it's even stretching my skull. I feel it cracks!!!
> Now we just need HtoA to grow up!!
> 
> thanks so much for taking the time to do this. 
> 
> sly
> 
> 
> Sylvain Lebeau // SHED
> V-P/Visual effects supervisor
> 1410, RUE STANLEY, 11E ÉTAGE MONTRÉAL (QUÉBEC) H3A 1P8
> T 514 849-1555 F 514 849-5025 WWW.SHEDMTL.COM 
> 
> 
> VFX Curriculum 03: Compositing Basics
> mail to: s...@shedmtl.com
> 

Re: SI and Houdini

[Oscar Juarez]

Mantra is really nice!


On Wed, May 21, 2014 at 7:35 PM, Ciaran Moloney wrote:

> Mantra aint too shabby...
>
>
>
> On Wed, May 21, 2014 at 3:08 AM, Sylvain Lebeau  wrote:
>
>> My God Jordi
>>
>> I am playing around with Houdini for the render sides of things with
>> Arnold these days We already use it for VFX in a somehow encapsulated
>> way.
>>
>> And I just finished reading all of your pdfs. Except for animation and
>> rigging.
>> Your guides are such invaluable help and incredibly informative.  My eyes
>> are so wide opened now that it's even stretching my skull. I feel it
>> cracks!!!
>> Now we just need HtoA to grow up!!
>>
>> thanks so much for taking the time to do this.
>>
>> sly
>>
>>
>> *Sylvain Lebeau // SHED*
>>  V-P/Visual effects supervisor
>> 1410, RUE STANLEY, 11E ÉTAGE MONTRÉAL (QUÉBEC) H3A 1P8
>> T 514 849-1555 F 514 849-5025 WWW.SHEDMTL.COM  <
>> http://WWW.SHEDMTL.COM >
>>
>>  VFX Curriculum 03: Compositing Basics
>> mail to: s...@shedmtl.com
>>
>>

Re: SI and Houdini

[Ciaran Moloney]

Mantra aint too shabby...


On Wed, May 21, 2014 at 3:08 AM, Sylvain Lebeau  wrote:

> My God Jordi
>
> I am playing around with Houdini for the render sides of things with
> Arnold these days We already use it for VFX in a somehow encapsulated
> way.
>
> And I just finished reading all of your pdfs. Except for animation and
> rigging.
> Your guides are such invaluable help and incredibly informative.  My eyes
> are so wide opened now that it's even stretching my skull. I feel it
> cracks!!!
> Now we just need HtoA to grow up!!
>
> thanks so much for taking the time to do this.
>
> sly
>
>
> *Sylvain Lebeau // SHED*
>  V-P/Visual effects supervisor
> 1410, RUE STANLEY, 11E ÉTAGE MONTRÉAL (QUÉBEC) H3A 1P8
> T 514 849-1555 F 514 849-5025 WWW.SHEDMTL.COM  <
> http://WWW.SHEDMTL.COM >
>
>  VFX Curriculum 03: Compositing Basics
> mail to: s...@shedmtl.com
>
>

Re: OT: Graphic card for optimous performance with Redshift

[Tim Crowson]

Redshift can handle that just fine. I know the term 'out-of-core' has 
been tossed around a lot, but it bears repeating. When Redshift either 
1) reaches its maximum geocache amount (which is currently capped at 4GB 
for various reasons), or 2) reaches the ram limits of the card, it sends 
data out-of-core, which means it starts offloading it from the card to 
the system ram. For this reason, you still need plenty of system ram. 
But what this means is that you can use your GPU to render scenes whose 
render-time memory footprint far exceed the ram amount on the card. I 
have a GTX 470 at home with a measly 1.2GB and I render all kinds of 
stuff on it that would never be possible with something like Octane 
(unless they've changed something recently?).


The chief effect of the whole OOC thing is on the final render time: the 
less frequently Redshift has to go OOC, the less time it will take to 
render the frame. If you have a card with 4GB or 6GB or higher, RS will 
have to go OOC far less frequently. And yes, there are plans to raise 
that geocache cap to a higher number to accomodate cards with higher 
addressable ram amounts.


-Tim


On 5/21/2014 3:30 AM, Dan Yargici wrote:

All said and done, Redshift is crazy-good though... Just saying.

...and how often are we rendering 100mio polys in commercials?  In 
those instances I'll split my scenes into layers and render them 50x 
faster (not a joke) thank you very much.


DAN

Re: More on Weights - Merge, Filter, Smooth compounds

[pedro santos]

Did and used them prior to the holidays. Just had to polish them for
release and be bothered about doing a video :)
And you know ICE can be fun. Well maybe not holidays-fun, but still fun,
ehehe.

Cheers


On Wed, May 21, 2014 at 11:29 AM, Nuno Conceicao <
nunoalexconcei...@gmail.com> wrote:

> Weren't you supposed to be on holiday break instead of doing cool stuff in
> ICE at home? :)
>
>
>
>
> On Wed, May 21, 2014 at 2:26 AM, pedro santos  wrote:
>
>> https://vimeo.com/95920562
>>
>> Here are some compounds I created while working a character. I really
>> like the ease of ICE when it comes down to solve these kind of issues when
>> the stock tools aren't enough, whithout making me run into hardcore
>> scripting.
>>
>> Cheers
>>
>
>


-- 
[img]http://i153.photobucket.com/albums/s202/animatics/avatar_1.gif[/img]

Re: Ice UV

[Alex Dorman]

Thanks guys, I seem to have this working now following the process Thomas
mentioned. thanks for the help


On 21 May 2014 13:21, Thomas Volkmann  wrote:

>   I should have read your post to the end, since this was exactly what
> you were doing... so no news then from my end. Except for a very helpful:
> "Normally it shouldn't crash that way"
>
>
> Thomas Volkmann  hat am 21. Mai 2014 um 14:17
> geschrieben:
>
>  I think you can generate a new(real) UVset and write the ICE-UVs to it.
> Something like: getData(ICE-UVs)->setData(newUVs)
>  I don't have SI open right now, but that should work somehow hopefully
>
>
> Stefan Kubicek  hat am 21. Mai 2014 um 13:51
> geschrieben:
>
>  What format are you trying to export to?
>  I don't know of any tool or exporter that would translate ICE UVs to
> standard UVs (worst case though I'm pretty sure that could be scripted),
> but that doesn't mean it doesn't exist.
>  Have you looked at Alembic or emTopolizer? I believe to have read that
> the latter does ICE geo baking to standard geometry, maybe it handles the
> UVs as well?
>
>  Eric?
>
>
>
>
>  Hi List
>
>  I was wondering if anyone had a way of getting ice UV's out from ice and
> onto geometry, I basically have some strands that are deforming. I have a
> empty poly that has strands extrusion applied, I can access the uv that it
> generates in the render tree but I need to export this geo out of softimage
> so need to bake the uv down onto the actual geo.
>
>  I was looking at this but was wondering if there was a better workflow in
> place now.
>
>  Simon Anderson simonbenandersonl...@gmail.com 
> via
>  listproc.autodesk.com
> 15/08/2012
>
>to softimage
>
>
>  looks like something out of Mortal Combat..
>
>  - Get Empty Mesh
>  - Apply ICETree (Create Topo-Part)
>  - Freeze
>  - Planar TextureProjection
>  - Freeze
>  - Apply ICETree (Create UV-Part)
>  - Freeze
>  - Freeze
>  - Freeze
>  - [..]
>  - Open TextureEditor -> Crash
>
>
>   Thnaks for any help.
>
>  Alex.
>
>
>
>
>  --
>
>  -
>Stefan Kubicek 
> ste...@keyvis.at<%22ste...@keyvis.at%22+%3cste...@keyvis.at%3E>
> -
>   Alfred Feierfeilstraße 3
> A-2380 Perchtoldsdorf bei Wien
>  Phone: +43 (0) 699 12614231
> www.keyvis.at
>  This email and its attachments are
> confidential and for the recipient only
>
>
>
>
>
>
>

Re: Ice UV

[Thomas Volkmann]

I should have read your post to the end, since this was exactly what you were
doing... so no news then from my end. Except for a very helpful: "Normally it
shouldn't crash that way"


> Thomas Volkmann  hat am 21. Mai 2014 um 14:17
> geschrieben:
> 
>  I think you can generate a new(real) UVset and write the ICE-UVs to it.
> Something like: getData(ICE-UVs)->setData(newUVs)
>  I don't have SI open right now, but that should work somehow hopefully
> 
> 
>   > > Stefan Kubicek  hat am 21. Mai 2014 um 13:51
>   > > geschrieben:
> > 
> >   What format are you trying to export to?
> >   I don't know of any tool or exporter that would translate ICE UVs to
> > standard UVs (worst case though I'm pretty sure that could be scripted), but
> > that doesn't mean it doesn't exist.
> >   Have you looked at Alembic or emTopolizer? I believe to have read that the
> > latter does ICE geo baking to standard geometry, maybe it handles the UVs as
> > well?
> > 
> >   Eric?
> > 
> > 
> > 
> >> > >Hi List
> > > 
> > >I was wondering if anyone had a way of getting ice UV's out from ice
> > > and onto geometry, I basically have some strands that are deforming. I
> > > have a empty poly that has strands extrusion applied, I can access the uv
> > > that it generates in the render tree but I need to export this geo out of
> > > softimage so need to bake the uv down onto the actual geo.
> > > 
> > >I was looking at this but was wondering if there was a better workflow
> > > in place now.
> > > 
> > > 
> > > 
> > >Simon Anderson simonbenandersonl...@gmail.com
> > >   via
> > > 
> > >  
> > > 
> > >15/08/2012
> > > 
> > >to softimage
> > > 
> > > 
> > >looks like something out of Mortal Combat..
> > > 
> > >- Get Empty Mesh
> > >- Apply ICETree (Create Topo-Part)
> > >- Freeze
> > >- Planar TextureProjection
> > >- Freeze
> > >- Apply ICETree (Create UV-Part)
> > >- Freeze
> > >- Freeze
> > >- Freeze
> > >- [..]
> > >- Open TextureEditor -> Crash
> > > 
> > > 
> > >Thnaks for any help.
> > > 
> > >Alex.
> > > 
> > >   > > 
> > 
> >   --
> > 
> >   -
> >  Stefan Kubicek ste...@keyvis.at
> >   -
> > Alfred Feierfeilstraße 3
> >   A-2380 Perchtoldsdorf bei Wien
> >Phone: +43 (0) 699 12614231
> > 
> >This email and its attachments are
> >   confidential and for the recipient only
> > 
> >  > 
> 
> 

Re: Ice UV

[Thomas Volkmann]

I think you can generate a new(real) UVset and write the ICE-UVs to it.
Something like: getData(ICE-UVs)->setData(newUVs)
I don't have SI open right now, but that should work somehow hopefully


> Stefan Kubicek  hat am 21. Mai 2014 um 13:51
> geschrieben:
> 
>  What format are you trying to export to?
>  I don't know of any tool or exporter that would translate ICE UVs to standard
> UVs (worst case though I'm pretty sure that could be scripted), but that
> doesn't mean it doesn't exist.
>  Have you looked at Alembic or emTopolizer? I believe to have read that the
> latter does ICE geo baking to standard geometry, maybe it handles the UVs as
> well?
> 
>  Eric?
> 
> 
> 
>   > >   Hi List
> > 
> >   I was wondering if anyone had a way of getting ice UV's out from ice and
> > onto geometry, I basically have some strands that are deforming. I have a
> > empty poly that has strands extrusion applied, I can access the uv that it
> > generates in the render tree but I need to export this geo out of softimage
> > so need to bake the uv down onto the actual geo.
> > 
> >   I was looking at this but was wondering if there was a better workflow in
> > place now.
> > 
> > 
> > 
> >   Simon Anderson simonbenandersonl...@gmail.com
> >   via
> > 
> >  
> > 
> >   15/08/2012
> > 
> >   to softimage
> > 
> > 
> >   looks like something out of Mortal Combat..
> > 
> >   - Get Empty Mesh
> >   - Apply ICETree (Create Topo-Part)
> >   - Freeze
> >   - Planar TextureProjection
> >   - Freeze
> >   - Apply ICETree (Create UV-Part)
> >   - Freeze
> >   - Freeze
> >   - Freeze
> >   - [..]
> >   - Open TextureEditor -> Crash
> > 
> > 
> >   Thnaks for any help.
> > 
> >   Alex.
> > 
> >  > 
> 
>  --
> 
>  -
> Stefan Kubicek ste...@keyvis.at
>  -
>Alfred Feierfeilstraße 3
>  A-2380 Perchtoldsdorf bei Wien
>   Phone: +43 (0) 699 12614231
>
>   This email and its attachments are
>  confidential and for the recipient only
> 

Re: Ice UV

[Stefan Kubicek]

What format are you trying to export to?
I don't know of any tool or exporter that would translate ICE UVs to standard 
UVs (worst case though I'm pretty sure that could be scripted), but that 
doesn't mean it doesn't exist.
Have you looked at Alembic or emTopolizer? I believe to have read that the 
latter does ICE geo baking to standard geometry, maybe it handles the UVs as 
well?

Eric?




Hi List
I was wondering if anyone had a way of getting ice UV's out from ice and onto 
geometry, I basically have some strands that are deforming. I have >a empty poly 
that has strands extrusion applied, I can access the uv that it generates in the 
render tree but I need to export this geo out of >softimage so need to bake the uv 
down onto the actual geo.

I was looking at this but was wondering if there was a better workflow in place 
now.

Simon Anderson simonbenandersonl...@gmail.com via listproc.autodesk.com

>15/08/2012

>>

to softimage





looks like something out of Mortal Combat..
- Get Empty Mesh
- Apply ICETree (Create Topo-Part)
- Freeze
- Planar TextureProjection
- Freeze
- Apply ICETree (Create UV-Part)
- Freeze
- Freeze
- Freeze
- [..]
- Open TextureEditor -> Crash



Thnaks for any help.



Alex.




--

-
   Stefan Kubicek ste...@keyvis.at
-
  Alfred Feierfeilstraße 3
A-2380 Perchtoldsdorf bei Wien
 Phone: +43 (0) 699 12614231
   www.keyvis.at
 This email and its attachments are
confidential and for the recipient only

Re: experience with svn

[Leendert A. Hartog]

I can't recall any specific tool/plugin/addon of the sort (but that's 
not saying much).

But the process outlined in this older Mailing List thread
https://groups.google.com/forum/#!topic/xsi_list/uVitUSo5jcU
seems rather painless...

Greetz
Leendert

--

Leendert A. Hartog AKA Hirazi Blue
Administrator NOT the owner of si-community.com

Re: experience with svn

[Angus Davidson]

You might  want to have a look at perforce. They have a 20 user server to test 
on and have integrations up to and including Softimage 2014 .



From: Doeke Wartena mailto:doeke.wart...@gmail.com>>
Reply-To: 
"softimage@listproc.autodesk.com" 
mailto:softimage@listproc.autodesk.com>>
Date: Wednesday 21 May 2014 at 11:57 AM
To: "softimage@listproc.autodesk.com" 
mailto:softimage@listproc.autodesk.com>>
Subject: experience with svn

hi,

i readed once that someone made svn support for softimage.
Where can i find it?
And does anyone here have any experience with svn with softimage?
I would like to know the experience was with multiple people working on the 
same thing.
I assume it requires all people to have the same version of si?

best Doeke



This communication is 
intended for the addressee only. It is confidential. If you have received this 
communication in error, please notify us immediately and destroy the original 
message. You may not copy or disseminate this communication without the 
permission of the University. Only authorised signatories are competent to 
enter into agreements on behalf of the University and recipients are thus 
advised that the content of this message may not be legally binding on the 
University and may contain the personal views and opinions of the author, which 
are not necessarily the views and opinions of The University of the 
Witwatersrand, Johannesburg. All agreements between the University and 
outsiders are subject to South African Law unless the University agrees in 
writing to the contrary. 

Ice UV

[Alex Dorman]

Hi List

I was wondering if anyone had a way of getting ice UV's out from ice and
onto geometry, I basically have some strands that are deforming. I have a
empty poly that has strands extrusion applied, I can access the uv that it
generates in the render tree but I need to export this geo out of softimage
so need to bake the uv down onto the actual geo.

I was looking at this but was wondering if there was a better workflow in
place now.

Simon Anderson simonbenandersonl...@gmail.com
via
 listproc.autodesk.com
15/08/2012
to softimage
looks like something out of Mortal Combat..

- Get Empty Mesh
- Apply ICETree (Create Topo-Part)
- Freeze
- Planar TextureProjection
- Freeze
- Apply ICETree (Create UV-Part)
- Freeze
- Freeze
- Freeze
- [..]
- Open TextureEditor -> Crash


Thnaks for any help.

Alex.

Re: More on Weights - Merge, Filter, Smooth compounds

[Nuno Conceicao]

Weren't you supposed to be on holiday break instead of doing cool stuff in
ICE at home? :)




On Wed, May 21, 2014 at 2:26 AM, pedro santos  wrote:

> https://vimeo.com/95920562
>
> Here are some compounds I created while working a character. I really like
> the ease of ICE when it comes down to solve these kind of issues when the
> stock tools aren't enough, whithout making me run into hardcore scripting.
>
> Cheers
>

experience with svn

[Doeke Wartena]

hi,

i readed once that someone made svn support for softimage.
Where can i find it?
And does anyone here have any experience with svn with softimage?
I would like to know the experience was with multiple people working on the
same thing.
I assume it requires all people to have the same version of si?

best Doeke

Re: OT: Graphic card for optimous performance with Redshift

[Dan Yargici]

All said and done, Redshift is crazy-good though... Just saying.

...and how often are we rendering 100mio polys in commercials?  In those
instances I'll split my scenes into layers and render them 50x faster (not
a joke) thank you very much.

DAN



On Wed, May 21, 2014 at 2:41 AM, Raffaele Fragapane <
raffsxsil...@googlemail.com> wrote:

> Speak for yourself, I'm perfectly adequately stupid for any thread.
>
>
> On Wed, May 21, 2014 at 11:05 AM, Steven Caron  wrote:
>
>> i think we are all too smart for this thread... :)
>>
>>
>> On Tue, May 20, 2014 at 6:03 PM, Matt Lind wrote:
>>
>>> You still need to store the results at each sample on each hair.
>>>
>>>
>>>
>
>
> --
> Our users will know fear and cower before our software! Ship it! Ship it
> and let them flee like the dogs they are!
>