Grimm's take on the turntable anim script

[grimm]

Hi Beppe,

You have it right, you should be able to switch render targets with the drop down. I think I have found the problem, it looks like the findItemsByName function is not working right. When I checked the ocs file you posted I would get the correct node type (56) on "rt1" and "rt2", but on rt3 Octane found node type (1), which is a NT_GEO_MESH type. It looks like, even with recursive set to true, that the functions not finding the rt node inside the group graph. This causes the script to say that you don't have a render target selected and it quits. I will post this in the release candidate forum.

Jason

[bepeg4d]

thanks grimm,
looking forward for the solution

ciao beppe

[stratified]

see my answer here: http://render.otoy.com/forum/viewtopic. ... 84#p168884

TLDR; the thing returned isn't a node at all, it's a graph of type octane.GT_STANDARD = 1.

cheers,
Thomas

[stratified]

Hi Jason,

Continuing the discussion in this thread. I had a look at your code and I think findItemsByName works correctly. The logic in your script doesn't look correct. I've annotated what I think is botched in case of selecting the graph rt3 in Bepe's example:

Code: Select all

-- See if we are working with a graph, if so then pull the first render target from it.
local currSelection = octane.project.getSelection()[1]
local foundTarget
if currSelection:getProperties().isGraph then
  -- THOMAS: here, foundTarget is the string "rt3"
  foundTarget = currSelection:findNodes(octane.NT_RENDERTARGET, true)[1]:getProperties().name
  print(foundTarget)
else
  foundTarget = nil
end

-- THOMAS snip, ...

function getSceneCopy(renderTarget)
    print("getSceneCopy", renderTarget)
    -- get the selected render target
    local selectedRt
    if renderTarget then
        -- THOMAS: here we search for the name "rt3" in the root graph there recursive searching will return 2 items
        -- the graph named "rt3" and the render target named "rt3". It all depends on how lucky you are? Do you feel lucky Today?
        selectedRt = octane.nodegraph.getRootGraph():findItemsByName(renderTarget, true)[1]
    else
        selectedRt = octane.project.getSelection()[1]
    end

If you change it to this, the code works:

Code: Select all

-- See if we are working with a graph, if so then pull the first render target from it.
local currSelection = octane.project.getSelection()[1]
local foundTarget
if currSelection:getProperties().isGraph then
  -- THOMAS: don't take just the name but the actual node. When in doubt always take the node and run. Names are ambiguous.
  foundTarget = currSelection:findNodes(octane.NT_RENDERTARGET, true)[1]
else
  foundTarget = nil
end

function getSceneCopy(renderTarget)
    -- get the selected render target
    local selectedRt
    if renderTarget then
        -- THOMAS: just pull the rt from the graph as before
        selectedRt = renderTarget
    else
        selectedRt = octane.project.getSelection()[1]
    end

Still to me the code doesn't feel "right" and it will still break. If the user has several nested render targets, the script always takes the first one which might not be the one the user selected. IMHO, allowing the selection of graphs and hoping that there's a render target inside them is not worth the added complexity.

Does this solve your problems?

cheers,
Thomas

[stratified]

Just noticed that my suggested fixes break other stuff in your script because your version of getSceneCopy expects nil or a string. Sorry about that

cheers,
Thomas

[grimm]

Ah, I see, thanks Thomas. I need to make the check a little smarter. I think that if the user selects a graph without a render target then the script should just error out.

Although now I'm thinking that I should just do away with selecting a node and just pull in all render targets and default to the first one found. Then the user can pick which one they want, whether it's in another graph or not. If the script doesn't find any render target nodes in the current root graph then error out.

Is there a reason why you only look for a render target with a thin-lense camera? Is it because the animation support only works with thin-lense?

Jason

[stratified]

Sure, you can make it as smart as you want. We just didn't bother in our scripts with the extra functionality because it wasn't there in the old daylight and turntable animations either. I do think that using selection for the render target still makes sense.

There's no reason why it wouldn't work with a panoramic camera besides the fact that it might look funky.

cheers,
Thomas

[grimm]

I think you are right about selecting the node first, at least keep it as an option.

Ok how about the following logic:

1) Check for selected node, if it's a render target use it, if not then ignore it.
2) Find all render target nodes, if none then error out.
3) If no selected target node then choose the first one in the list and use it.

I was also thinking that it might be nice to keep the list of render targets in a table, would that work with node index(or the objects themselves), or is it still not good to rely on the index?

Thanks,

Jason

[stratified]

That logic makes sense to me.

I gave the combo box some extra thinking and I think it was a really bad idea to use the string as the currently selected item in the combo. It should just have been a number from 1..n. If it would work like that, you could just use the index of the combo box in the list of all the render targets. I'll probably change that in 1.29.

It would make your targetDropDownCallback a lot simpler.

cheers,
Thomas

[r-username]

There's no reason why it wouldn't work with a panoramic camera besides the fact that it might look funky.

I use the pano camera all the time, granted not as useful with turntable animations at FOV 360 degrees but can be quite nice at FOV 180 degrees.

Just to inquire do we just do a find and replace and swap out thinlens or is there a method in lua just to check that there is a render target with a camera, but any type of camera.

thanks in advance.