[Sidefx-houdini-list] Standalone geo converters+ frame numbers
rangi at kanuka.com.au
Thu Mar 10 23:24:14 EST 2011
Holy crap! You're right. I had used frame number for FBio in the past... but
long deep dark past, transferring frames to Accoms...
Sorry for bum steer. It must do as you say; gets the converter to write a
temp file then copy it to actual destination.
I'm out of ideas.
On 11 March 2011 13:54, Miles Green <Miles.Green at al.com.au> wrote:
> Hi Rangi,
> unfortunately thats not the case, printing the value of filename passed by
> %s returns a sting similar to:
> so I can only assume that some post process outside of the standalone
> converter renames this file to the actual filename afterwards :(
> Rangi Sutton wrote:
>> On 11 March 2011 10:27, Miles Green <Miles.Green at al.com.au> wrote:
>>> does anyone know anyway to pass the current frame into a standalone geo
>>> converter (like geo2voxel in the HDK examples)? unfortunately the file
>>> format I'm working with likes to have the frame stored as one of it's
>>> attributes in the file header
>>> I guess ideally I'm looking for a flag like %f that can be added to the
>>> GIOio table
>>> I thought I would be cleaver and extract the frame from the input/output
>>> filename but Houdini saves the files on the fly to /tmp/ with a temporary
>>> filename string thats doesn't reference the frameNumber..
>>> any help appreciated
>> Don't know about a framenumber string, but your idea of pulling it out of
>> the filename should work!
>> The GIOio entry here for instance:
>> .obj "gwavefront %s stdout.bgeo" "gwavefront stdin.bgeo %s"
>> Means that if I save a file as myobj.0001.obj then this gets run:
>> gwavefront stdin.bgeo myobj.0001.obj
>> So.. where gwavefront would be replaced with your standalone converter,
>> the second argument given to it is the output filename it should be saving
>> to, so it could strip the framenumber out of there, no?
More information about the Sidefx-houdini-list