I'm a bit confused. Looking at the $HH/public/tomdisplay/README.html

it says at the bottom “When a renderer other than mantra is asked to render to the the SHOP viewer or the render state, the filename for the output driver will be set to socket:number”

in fact no parameters are altered at all. the socket number is not passed at all, as far as I can tell;


print self.sprop('picture')
print self.sprop('soho_outputmode')
print self.sprop('soho_diskfile')
print self.sprop('soho_pipecmd')
print “foo”

returns:

ip
2


foo

(the diskfile and pipecmd 2 lines are blank)

ivan
I'm a bit confused. Looking at the $HH/public/tomdisplay/README.html

it says at the bottom “When a renderer other than mantra is asked to render to the the SHOP viewer or the render state, the filename for the output driver will be set to socket:number”

in fact no parameters are altered at all. the socket number is not passed at all, as far as I can tell;


print self.sprop('picture')
print self.sprop('soho_outputmode')
print self.sprop('soho_diskfile')
print self.sprop('soho_pipecmd')
print “foo”

returns:

ip
2


foo

(the diskfile and pipecmd 2 lines are blank)

You probably want to look at $HH/soho/overrides/RenderViewer.

These override files allow certain parameter values to be “overridden” for a particular usage case.

This causes the vm_picture parameter to be overridden with “ip” and the vm_image_mplay_socketport to be overridden with the socket set by the viewer.

Hope this points you in the right direction.

yes, I think I have my RenderViewer correct, I have this at the bottom:


{
override.inherit CommonView
override.name ASS

ar_picture
}

and

print self.sprop('ar_picture')
print self.sprop('soho_outputmode')

returns
ip
2

so, that's not it. odd.

ivan
yes, I think I have my RenderViewer correct, I have this at the bottom:


{
override.inherit CommonView
override.name ASS

ar_picture
}

and

print self.sprop('ar_picture')
print self.sprop('soho_outputmode')

returns
ip
2

so, that's not it. odd.

If you look in the RenderState and RenderViewer, you'll see that for hrmanpipe, the RiDisplay is set to “iprsocket:$socket”. So when the IPR viewer renders, the RIB renderer (i.e. prman or 3delight) would see “iprsocket:2” as the filename.

In the d_houdini display driver for RIB, we check for the filename iprsocketORT and pass that on to hrmanpipe. hrmanpipe acts as a pipe between stdin and the specified socket. However, it looks like there might be a little data translation going on – but there might not be.

It seems that hrmanpipe just reads an image from stdin and writes it to the output device. I think hrmanpipe reads data in the same format as imdisplay… You might be able to substitude hrmanpipe for imdisplay in the display driver when sending to an ipr filename.

I haven't been able to verify any of this, it's just by inspection of the code. So, please let me know if you have any success.