Pages: [1] 2 
|
 |
|
|
Author
|
Topic: Scriptability...and...Custom Buffers (Read 7942 times)
|
jeremyhardin
Pixlet
 Offline
Posts: 31
infiniMap User
|
2 requests. I know how one would work. I don't know if the other one is doable. But I'd sure love it.
1. Scriptability (using the Comm Ring). So I can get/set values to/from the buffer saver interface with Lscript.
2. Custom writable buffers. Newtek won't give us custom buffers, but if there were some way to make a buffer(s) writeable into the exr file (i.e. motion vector data from that free RSMB lscript, or iDof), that would be incredible.
Thoughts?
|
|
|
|
|
Logged
|
|
|
|
|
lightwolf
|
2 requests. I know how one would work. I don't know if the other one is doable. But I'd sure love it.
1. Scriptability (using the Comm Ring). So I can get/set values to/from the buffer saver interface with Lscript.
2. Custom writable buffers. Newtek won't give us custom buffers, but if there were some way to make a buffer(s) writeable into the exr file (i.e. motion vector data from that free RSMB lscript, or iDof), that would be incredible.
Thoughts?
Both are possible, the second is in the works (well, design mode at the moment) and will involve a global. For 1), what kind of commands would you like to see? Cheers, Mike |
|
|
|
|
Logged
|
Optimism is an occupational hazard of programming: feedback is the treatment. (Kent Beck)
- skype: lupus_lux -
|
|
|
jeremyhardin
Pixlet
Offline
Posts: 31
infiniMap User
|
Both are possible, the second is in the works (well, design mode at the moment) and will involve a global.
For 1), what kind of commands would you like to see?
Cheers,
Mike
Great news on the second feature! For scriptability...I'd say the bare minimum that I would hope for is to add/remove the buffer saver and apply an existing preset and change the base name, then enable/disable it at will. Beyond that, I'd love to see the ability to test and set every parameter in the interface. If I can click it, type it, or change it, I'd love to be able to detect/alter it with lscript or plugins. But that's dreaming big.  To be honest, this is something that I'd love to see all 3rd parties do, but you're one of the few that I'm in regular communication with.  |
|
|
|
|
Logged
|
|
|
|
|
lightwolf
|
Great news on the second feature!
Yup it just needs some sussing out because there are a variety of buffer types that would be useful and that would need to be managed. I'm also still thinking about a way to extract coverage data, which is quite hard within the limitations of the SDK. For scriptability...I'd say the bare minimum that I would hope for is to add/remove the buffer saver and apply an existing preset and change the base name, then enable/disable it at will. Beyond that, I'd love to see the ability to test and set every parameter in the interface. If I can click it, type it, or change it, I'd love to be able to detect/alter it with lscript or plugins. But that's dreaming big. Adding/removing it is possible already, this code is based on LScript code shipped with LW: //exrTrader.ls
//based on bufferExport.ls
@version 2.3
@script generic
@name exrTrader OpenEXR Export
generic
{
appActive = false;
curScene = Scene();
applied = curScene.server("ImageFilterHandler");
if(applied)
{
counter = size(applied);
for(x = 1; x <= counter; x++)
{
if(applied[x] == "exrTrader")
{
appActive = true;
break;
}
}
}
if(!appActive) ApplyServer("ImageFilterHandler", "exrTrader");
openServer = string("EditServer ImageFilterHandler ",x);
CommandInput(openServer);
}
This sample applies the plugin if it isn't applied already, and the opens the interface. Removing the plugin would be similar (using "RemoveServer" instead of "Apply Server"), I haven't found a command to enable/disable the plugin from LScript though (but I've only checked the LW 7.5 commands). Beyond that I'll look into the comRing from an LScript point of view to check on how to best accomplish a connection. The only thing I don't see happening soon is changing any enveloped values, since these are completely controlled by LW (well, it could be possible, but it require major work). To be honest, this is something that I'd love to see all 3rd parties do, but you're one of the few that I'm in regular communication with. Hehe  I'd love to see a more standardized way of passing commands and retrieving values from LScript as well. Something along exrTrader.ouputFile = "images/test.exr" to set the filename from Lscript would be grand. The ComRing is a good start, but doesn't standardize how commands are passed, it just allows some information to be passed (which may be anything). I'll check it out though. Cheers, Mike |
|
|
|
« Last Edit: October 13, 2006, 01:19:47 PM by lightwolf »
|
Logged
|
Optimism is an occupational hazard of programming: feedback is the treatment. (Kent Beck)
- skype: lupus_lux -
|
|
|
|
lightwolf
|
Allright, I had a quick look at the ComRing. the best way would be if exrTrader inits a ComRing for Scripts to hook into. The ComRing passes on an event ID (which is interpreted by the involved applications) as well as "data". In the SDK sample this is just a string, and I think this would be the way to go for a ComRing hook into exrTrader as well. Sample code could look like this: @define RINGNAME "exrTrader_ComRing"
comringattach(RINGNAME,"myCallcackUDF");
data = comringencode(@"s:100", "s:1024"@, "setOuputFilename", filename);
comringmsg(RINGNAME,1234,data); //assuming event ID #1234 has been defined as changing settings in exrTrader
comringdetach(RINGNAME);
Not pretty, but it should work. I don't know if the attach/detach bits are actually needed to send out messages only. The event ID would likely control the message flow, i.e. one ID code tells exrTrader to set a value, the other tells it to send a value asked for back to the ComRing, which in turn could be read by any subscriber. Cheers, Mike |
|
|
|
|
Logged
|
Optimism is an occupational hazard of programming: feedback is the treatment. (Kent Beck)
- skype: lupus_lux -
|
|
|
|
zareh
|
I'm not sure I follow this conversation, maily due to my lack of knowledge in this area.
It would be nice if we could assign each surface in LightWave a special code that would end up as a separate channel in an exr file. Maybe this is already what you guys are talking about. This way you could mask out a specific surface in Fusion and do things to it and not the entire frame.
Don't know how doable this is...
Best Regards,
Zareh
|
|
|
|
|
Logged
|
|
|
|
|
lightwolf
|
It would be nice if we could assign each surface in LightWave a special code that would end up as a separate channel in an exr file. Maybe this is already what you guys are talking about. This way you could mask out a specific surface in Fusion and do things to it and not the entire frame.
That would be possible. Basically, you will be able to define named buffers (i.e. "mySurfaceRGB"), using nodes you can then write _anything_ into that buffer... in this case the shaded RGB. However, since I'm also going to add object/surface IDs you'll be able to use those to isolate objects/surfaces easily. Cheers, Mike |
|
|
|
|
Logged
|
Optimism is an occupational hazard of programming: feedback is the treatment. (Kent Beck)
- skype: lupus_lux -
|
|
|
|
zareh
|
That would be possible.
Basically, you will be able to define named buffers (i.e. "mySurfaceRGB"), using nodes you can then write _anything_ into that buffer... in this case the shaded RGB.
However, since I'm also going to add object/surface IDs you'll be able to use those to isolate objects/surfaces easily.
Cheers,
Mike
That's amazing Mike! Thank you!Best Regards, Zareh |
|
|
|
|
Logged
|
|
|
|
|
lightwolf
|
That's amazing Mike! Thank you!
Hey, no thanking before it's coded Cheers, Mike |
|
|
|
|
Logged
|
Optimism is an occupational hazard of programming: feedback is the treatment. (Kent Beck)
- skype: lupus_lux -
|
|
|
|
zareh
|
we're already using exrTrader in production, it's such a useful tool. Thank you for coding it so fast and making it available. I think LightWave is one of the only 3D apps out there that doesn't support exr images out of the box. Now at least there is an option for users to purchase your plugin and get pretty robust exr support, one that works with VIPER too no less. It's very handy to use VIPER to check out the various buffers that we're outputting before submitting a full blown render job to the stack.
Best Regards,
Zareh
|
|
|
|
|
Logged
|
|
|
|
|
lightwolf
|
we're already using exrTrader in production, it's such a useful tool. Thank you for coding it so fast and making it available. I think LightWave is one of the only 3D apps out there that doesn't support exr images out of the box. Now at least there is an option for users to purchase your plugin and get pretty robust exr support, one that works with VIPER too no less. It's very handy to use VIPER to check out the various buffers that we're outputting before submitting a full blown render job to the stack.
Thanks *blush* Well, and you can even use the vanilla saver without shelling out at all... The VIPER support has proven to be much more useful than I initially suspected, I use it all the time as well. Cheers, Mike |
|
|
|
|
Logged
|
Optimism is an occupational hazard of programming: feedback is the treatment. (Kent Beck)
- skype: lupus_lux -
|
|
|
|
zareh
|
Well, and you can even use the vanilla saver without shelling out at all...
good point. There were'nt any good vanilla savers available for LightWave till exrTrader came out. Best Regards, Zareh |
|
|
|
|
Logged
|
|
|
|
jeremyhardin
Pixlet
Offline
Posts: 31
infiniMap User
|
and thanks for being open to these ideas as well.
with the writeable buffers, are you saying that you'll have a node in the image processing that lets you pipe things into your buffers?
|
|
|
|
|
Logged
|
|
|
|
|
lightwolf
|
and thanks for being open to these ideas as well.
Hey, we can't produce all good ideas ourselves now, can we We're very grateful for any feedback we get, including feature requests (and we surely prefer them to bug reports ). with the writeable buffers, are you saying that you'll have a node in the image processing that lets you pipe things into your buffers?
Note quite... a node in the shading part, which will write into (named) buffers. This would, for example, allow to to extract ambient occlusion to a separate buffer. It just needs careful designing to take all possibilities and pitfalls into account, it does sound easier than it is - if it is supposed to work as wxpected. Cheers, Mike |
|
|
|
|
Logged
|
Optimism is an occupational hazard of programming: feedback is the treatment. (Kent Beck)
- skype: lupus_lux -
|
|
|
|
zareh
|
this is probably another dumb question, but here it goes:
would this node solution you're talking about allow plugins like G2 to write their shadow buffers into it?
Best Regards,
Zareh
|
|
|
|
|
Logged
|
|
|
|
|
Pages: [1] 2 
|
|
|
 |
