Relight For Nuke

[elmlish]

I started the porting of a plugin suite I wrote for Fusion that does 3d relighting - ie if you have depth channel and normals you can light the image in true 3d with spotlights and pointlights, besides the usual directional lights.
There's only the basic stuff - which is not very 'basic' anyway - plus, I bet, a bunch of bugs. All Nuke users are encouraged to test and use it, in exchange for feedback
Well, I'm afraid not ALL users, since right now it is for 4.6win only.

More information and the nice .zip with the plugins can be found here:
http://www.lowrez.net/relightnuke.html

I hope the feedbacks/downloads ratio will be over 0.001 this time...

All the best

[user_deleted]

very cool, thanks!

We should get Will to set up a plugin section in the Nuke/downloads area so these kind of things can managed better. This way it's easy to find if people are looking for something specific later on.
Will, are you listening??

cheers,
frank

[user_deleted]

the plugin section in the dowload are is up and running so feel free to upload any compiled goodness .

http://www.fxshare.com/nuke/downloads/plugins/

thanks Will for making this happen so quickly!

[user_deleted]

I don't have windows so I haven't been able to test this out but am I correct that all your nodes are just custom Iops and not working with 3d and vertext shaders etc?

The 3d section of the NDK docs are pretty limited atm, I haven't the time to start a trial by error session of working with anything related to the 3d workspace yet. Wish I did though because I would like to port my extended bicubic node and add it to the nfxplugins pack.

Hopefully I will get some more time to mess with the 3d part of Nukes ndk, guess I'll have to bother Bill and Matt on the dev list when I get around to it.

[elmlish]

Frank, thank you! I really feel honoured for the words of a great pro like you
anyway, I'm unsure about giving such a widespread availability to the plugins; I only started the porting and did very little testing, so they are likely to crash or, worse, substitute snippets of tcl in scripts with random trek technobabble - that's why I'm looking for feedback.
Do you think it's a reasonable stand or should I just put huge glowing disclaimers and hope not to be blamed by the world? I really don't know...

nrgy, i saw your plugins, cool work! I actually had to subclass LightOp for the lights (nothing fancy, just needed more knobs along with the transformation matrix), but didn't have to use any *vtx luckily Could you smuggle a SceneOp.h out of the devlist for me?
When I overcome my laziness and boot Linux again I'll try a compile; I started the porting with CodeBlocks Linux actually - are you using an IDE?

[user_deleted]

For the longest time I used plain old gedit for my coding, however the past few months I've switched to using Eclipse for most of my work.

You could always do your compiling in vmplayer or some other vmware product running a distro. Only problem I can see from that would be testing since no opengl, you could always send me the libs in that case if you want.

Why exactly did you subclass LightOp, I don't think I quite follow you explanation?

[mattao]

Hi, is it possible to compile for MAC OSX to? since a lot of users are running MAC OSX from there Shake background and we the "Macs" whould love to test this plugin also.

Thanks

Hugo guerra

[elmlish]

nrgy, so how do you like Eclipse? Did you find it hard to make it 'behave' (eg configure) in the beginning?
For compiling, I think you underestimated my laziness... all I have to do is downarrow-enter when GRUB kicks in at boot I'll do it eventually and immediatly give up as soon as I see the first compile error...
As for LightOp subclassing, I did it basically because I like C syntax better than tcl - besides, is it even possible to address user knobs from compiled nodes? To explain further, a LightOp has an AxisOp (just a 3D transform matrix), a color and an intensity, but I also needed a decay knob - and cone control knobs for spotlights. Now, what about that SceneOp.h deal?

Hugo, hi and thank you for your interest. I'm quite surprised - I thought "Macs" would just wait for Phenomenon and wonder how it could possibly work without RMB - let alone MMB-dragging . Now seriously, I have no Apple gear around, I think the only way to have an OSX compile in a reasonable timeframe would be to give somebody the sources, but I don't know anybody... Really, I'd want you to play with the plugin more than you want to, but I don't know how to do it; I'm not sure I want to go opensource, not yet at least. Right now I can only suggest BootCamp
Sorry for not being of help; rest assured that as soon as I get my hands on a OSX Nuke (maybe when I manage to get a decent job - openings anybody?) I'll try and compile.

[user_deleted]

Eclipse is like any other IDE, I use my own make files so I just setup projects as such.

If I understand, you picked the LightOp class for its provided knobs? You can use a regular Iop or GeoOp and add knobs such as the Axis_knob() instead of sub-classing LightOp. You can also create custom drawing handles in the ui if you wanted to do custom displays in the viewer in 3D mode.

As for addressing knobs inside compiled plugins, yes you can access other nodes knobs along with its own. Take a deeper look inside DDImage::Knobs would be my suggestion.

You can also skip a nodes input and access ITS input, a crude example would be instead of accessing the input by calling input(0) you woud do input(0)->input(0). This would completely skip whatever is incoming to your node and instead grab its input. Obviously this crude example doesn't include checks to make sure input(0)'s input is not null but you get the idea.

What exactly do you need with SceneOp.h? Do you not have the file?

[elmlish]

Hi nrgy,
I picked the LightOp just for similarity... the (axis) knobs are already there, and rlLights can still be valid lights for pure 3d scenes (though I wonder what happened to 3D lighting code from 4.7 on); I'd love to override draw_handles to provide for full 3D UI controls in a 2D viewer, but that one requires a bit of thought and trial/error. As a sidenote, (now that I compiled for Linux too) it looks like I can't instantiate a new class (namely my rlLight class/plugin from rl3D plugin, needed for default_input()) under Linux... Nuke complains about missing .so file (I wonder then why it can find DDImage.so and related exports...); to my understanding, you have great expertise on Linux: any words of advice?

About addressing knobs: the problem was about addressing GIZMO knobs from compiled plugins; is it possible? I doubt it.

SceneOp.h: in NDK the file is simply MISSING (like many others)... the provided Scene.h WON'T provide a correct interface to a Scene op/node (fact is, the Scene node class is called SceneOp, not Scene); your suggestion about (recursively) querying inputs of inputs is interesting, but it is asking for far more headaches then reasonable (for one, transform-matrix recalculation from scratch, something I had to do in Fusion - because of a lacking SDK - and that I was delighted to not being forced to do in Nuke).

All the best

[user_deleted]

What exactly is the error you are having on Linux - I don't quit follow, is it a compile error or a coding error you are running into?

Bug: rl3d upon creation spits this error out on Linux.

CODE
"warning: rl3D.output_specular[1] was not initialized correctly"

When someone creates your rl3D node it obviously cant have all the inputs connected on creation and this appears to be causing errors to be printed out to the terminal. I would suggest creating a check inside _validate to see if certain inputs are indeed connected to other nodes that contain data, if an input is unconnected it will usually return an input of the Class DD::Image::Black, that way you can skip all your processing and just pass through the image since it can't perform operations without certain inputs.

What exactly do you mean by accessing a knob by a gizmo, do you mean getting a knob that is from a node inside the gizmo itself? If thats the case I don't believe you can but don't take my word because I haven't tried it myself.

If your going to work with Nukes NDK I suggest you create yourself a small Iop node that is completely empty and does nothing more then copy the inputs row to the output. Use this node for testing ideas out and other coding related things, this way you don't have to work with big nodes while messing around with ideas. I labeled mine NFXCrash for a while now its just NFXTest.

I haven't messed with anything 3d yet so I can't comment on Scene.h but are you sure you understand the concept of the Class? You can always ask on the dev list if you have any questions, I'm sure Matt or Bill can help you out.

When I was talking about working up inputs->inputs it was just an example and isn't something I would recommend doing, it was just an example of trying to explain what you can do inside a tree.

Lastly what is your problem with Nuke creating two instances of your light node? If you can could you private message me or post the constructor code for the light node? I don't know why you are having this problem, it could be a bug with the LightOp class or your constructor for the node.

[stempy]

Any hope of seeing version updates on the linux side of Relight?

cool plugin though