Just wanted to say thanks again for the help on this and a big thanks to 
Fabricio for sending that compound.
These texture issues I was having seem to be alleviated by using this compound.
In addition I was also having all sort of problems with the crowd not sticking 
to the ground and with custom variables not being read correctly by the render 
tree.  With a few tweaks of this compound all of the issues I was having  seem 
fixed and all is working as expected now.

What a drag to have gone around in circles so many times trying to fix this.  I 
recall seeing the topic of these problems being caused by overly aggressive 
optimization before but had not assumed it was as widespread as I was 
experiencing.  This was really key a lot of the problems I was having and I am 
looking forward to more warm dinners in my future.

Also thanks to Adam and Stephen for their insight and suggestion on the issue 
as well.  Being a somewhat isolated user I would never be able to make as much 
use of this software without all the help and insight this list provides.

Jeff





From: Jeff McFall
Sent: Tuesday, February 26, 2013 8:58 PM
To: 'softimage@listproc.autodesk.com'
Subject: RE: ice crowds and rendering

Thanks all, this compound seemed to lock them pretty well in my first test.


From: 
softimage-boun...@listproc.autodesk.com<mailto:softimage-boun...@listproc.autodesk.com>
 [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Fabricio Chamon
Sent: Tuesday, February 26, 2013 3:40 PM
To: softimage@listproc.autodesk.com<mailto:softimage@listproc.autodesk.com>
Subject: Re: ice crowds and rendering

I do what Adam said...but before I make sure the ice projection is calculated 
correclty (not bypassed by those evil ice optimizations) by using the attached 
compound at the very end of in the first icetree on each "actor_copies" mesh. 
It's really simple, it ensures the attribute is set by using it inside a null 
equation that get/set point positions.



2013/2/26 Jeff McFall <jeff.mcf...@sas.com<mailto:jeff.mcf...@sas.com>>
Thanks Adam, I appreciate your response
Yeah, I have done that a gazillion times and they still seem to disconnect when 
rendering.  Though I have been jiggling with the materials quite a bit...
However I'll try again as my experience seems to indicate that things magically 
begin to work *after* after posting on the list

I don't do much scripting so would like to ask if it is conceivable that one 
could create a script that would execute every frame and snap those connections 
together?

Thanks again
Jeff


From: 
softimage-boun...@listproc.autodesk.com<mailto:softimage-boun...@listproc.autodesk.com>
 
[mailto:softimage-boun...@listproc.autodesk.com<mailto:softimage-boun...@listproc.autodesk.com>]
 On Behalf Of Adam Sale
Sent: Tuesday, February 26, 2013 1:37 PM
To: softimage@listproc.autodesk.com<mailto:softimage@listproc.autodesk.com>
Subject: Re: ice crowds and rendering

Hi Jeff.. This is a known issue for sure.

I work around the issue by doing the following,

I generally just get in and edit the texture projection in the render tree per 
image node on each actor copy. You have to point each image to the 
TextureProjection UV available to each ActorCopy.)
On the Mesh Proxy you have to set the UV's to the correct projection in the Set 
Mesh Proxy compound in the ICE tree.

Once I do that, I have no problems with textures showing on rendered sequences.

Adam

On Tue, Feb 26, 2013 at 9:08 AM, Jeff McFall 
<jeff.mcf...@sas.com<mailto:jeff.mcf...@sas.com>> wrote:
I have been working with crowds and am excited about some of the results I am 
getting but have one nagging problem that I have not been able to overcome.

That problem has to do with rendering and the fact that texture projections 
seem to become broken/disconnected from the material when the job distributed 
to a farm (we are using RR).
When submitting jobs as a continuous sequence that begin on the first frame 
(frame 1) all seems to work fine.  However when the job is spread across 
machines the textures are broken.

As a quick overview of my setup I am using an random integer to drive a color 
switch in the render tree which basically selects the appropriate texture.
As I said this all works fine as long as I render from the first frame of the 
sequence.

Just a guess but I suspect this has something to do with the fact that the 
texture projections are created when the ice tree initializes on the first 
frame.
Has anyone else experienced this and maybe know of a fix or workaround?

I am wondering if I can tweak the scene or render software somehow to force the 
simulation to begin on frame 1 for each frame rendered?
Seems I recall some scripts that may do this but I have been unable to track 
any down.

Any suggestions much appreciated
Thanks
Jeff


Reply via email to