I remember doing some timing tests on hair with cut maps. Back on that
version - 5.0 I think - there was an overhead if you had areas of the
surface that were cut back using textures. If you can localize it a bit,
minimize the bald areas by putting the hair onto clusters you may find it'll
help. I'd do a quick test first though.
> -----Original Message-----
> From: owner-xsi(at)Softimage.COM [mailto:owner-xsi(at)Softimage.COM] On
> Behalf Of Kris Rivel
> Sent: 01 June 2007 22:08
> To: XSI(at)Softimage.COM
> Subject: Re: hair instance up vector
>
> Wow, well thanks for sharing the pain. I cringe at the thought of
> having to do any custom shader writing to push this job through. I
> wonder if the actual amount of guide hairs effects rendering. In other
> words, my viewport is almost solid with guide hairs but I'm only really
> rendering hairs in areas I painted with a weight map. Do these
> "ignored" hairs play any part in rendering if no render hair or
> instance
> is applied to that area? I also wish there was a way to limit the
> amount of guide hairs you see on screen. This would be much better for
> interaction purposes when doing simulation.
>
> Kris
>
> Ben Barker wrote:
> > It wasn't easy for the lighters. Lots of splitting up passes. The
> tree
> > assets were designed with little thought to rendering more than one
> or
> > two, and layout ended up making thousands of them with no concern of
> > them rendering. We designed a proxy system and Matt Lind wrote a
> > custom shader that did fancy 3D shading on a 2D card and we
> > procedurally replaced most of the trees with those.
> > The renderfarm ended up being pretty awesome in the end, both
> hardware
> > and software. 64bit with gigs of memory, dedicated translation
> > machines, etc and that helped a great deal as well when it went
> > online, but there was still a good share of pain before that, and of
> > course you still needed real trees in many shots. At that stage
> > optimizing the actual tree assets was the biggest help (as opposed to
> > render settings which only give you so much). They had an insane
> > amount of texture data as well as high subdivisions and hair count, a
> > good deal of which could be reduced with no visible effect (SubD
> level
> > 2 on 5 pixel tall parts, etc). Hair instancing, especially
> > recursively, multiplies any waste exponentially. Texture data was a
> > huge killer too, not just on trees. Being fairly brutal with reducing
> > this sometimes was the only way to get things to render.
> >
> > On 5/31/07, Kris Rivel <krisrivel(at)gmail.com> wrote:
> >> Thanks Ben. Sounds like you guys had the same problems I'm having.
> I'm
> >> spending more time grooming and keeping turbulence to a minimum so
> as to
> >> not get too much flipping. Right now I'm finding the biggest
> problem is
> >> rendering. MR really doesn't seem to play nice in a case like this.
> >> I'm optimizing to the nines but man is it slow. How did you guys
> manage
> >> to get so many leaves and trees to render? Did you have a lot of
> bits
> >> rendered separately? What was your memory limit on your farm? Its
> a
> >> shame because I'm working on a Win64 box but I have to stick with
> not
> >> only XSI 32 bit but also can't take advantage of v6 either since the
> >> farm this is rendering on does not yet have it in place. Looks like
> >> there's going to be a lot of coffee breaks (well I don't drink
> coffee so
> >> soda or tea) for me.
> >>
> >> Kris
> >>
> >> Ben Barker wrote:
> >> > I don't think it's possible to use scripted ops to control hair
> >> > instances that specifically, since they operate on the scene data
> and
> >> > hair instances don't really exist until rendering. You might be
> able
> >> > to use a scripted op to scatter model instances based on guide
> hairs,
> >> > essentially implement a "scatter" op, but it would be very slow
> >> > relative to hair instancing and potentially very involved if you
> >> > wanted it to be robust.
> >> >
> >> > Unfortunately if you use a global Y upvector (like the goal object
> you
> >> > mentioned) instances that "aim" down that vector will still
> >> > potentially flip during animation. There isn't really any
> bulletproof
> >> > way around this as it is a problem with the philosophy of the
> >> > algorithm not really the implementation. Careful grooming really.
> >> >
> >> > We had this issue on Barnyard, where all the tree leaves were
> >> > hair-instanced clumps. This was before tangent maps and all that
> good
> >> > stuff too, so careful grooming (trial and error) was the only
> >> > solution. Pretty sure a non-trivial amount of flipping made it to
> >> > paint and even into a few into finished shots. Huge pain in the
> ass :(
> >> >
> >> > On 5/31/07, Kris Rivel <krisrivel(at)gmail.com> wrote:
> >> >> Is there any way to get hair instances to point up along the
> >> global Y?
> >> >> Ideally to have some variance as well. This possible via
> scripted
> >> >> operators? I'm looking to get more rigid control over my hair
> >> instances
> >> >> which are incredibly difficult to keep from flipping around
> wildly
> >> when
> >> >> adding slight turbulence. I'm using tangent maps and tried
> >> pointing the
> >> >> instance to a goal but they don't give me the effect I'm looking
> for.
> >> >>
> >> >> Kris
> >> >> ---
> >> >> Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text
> in
> >> >> body:
> >> >> unsubscribe xsi
> >> >>
> >> >
> >> >
> >> ---
> >> Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in
> >> body:
> >> unsubscribe xsi
> >>
> >
> >
> ---
> Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in
> body:
> unsubscribe xsi
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi
