Grimm's take on the turntable anim script

Forums: Grimm's take on the turntable anim script
Forum for OctaneRender Lua scripting examples, discussion and support.

Re: Grimm's take on the turntable anim script

Postby stratified » Wed Jan 01, 2014 8:56 pm

stratified Wed Jan 01, 2014 8:56 pm
grimm wrote:Hi Thomas,

Still have some problems with the code fix: :oops:

Did you mean:

Code: Select all
local copyCam = getInputNode(copyRt, octane.P_CAMERA)


instead of:

Code: Select all
local copyCam = copyRt:getInputNode(octane.P_CAMERA)


Even with changing that line of code I'm still getting an error:

"attempt to call method 'getConnectedNode' (a nil value)"

on this line:

Code: Select all
local connected = node:getConnectedNode(pinId)


Now my test scene is real simple, all I have is a mesh node with two render targets connected to it. To test this I grouped both of the target nodes, would this work?

Thanks,

Jason


Hmm, both versions should work but I think I should read up on the Lua docs tomorrow. At least the one without the colon should work. I would've sworn that it worked yesterday. Maybe my new year hangover?

When grouping the render target nodes, you should select the render target node inside the group (not the group itself because this is a graph). However with the code as is it wouldn't work. The problem is that we create a copy of the root scene graph, but the render target nested in the grouped graph isn't returned in getOwnedItems(). So the script would error out before it finds it.

You can make it work by only copying the owner graph of the render target or by writing a custom getOwnedItems(). Here's how you would modify getSceneCopy to work with the graph that owns the render target:

Code: Select all
-- Returns copies of the original scene graph, the camera node and the rendertarget.
-- This prevents us from modifying the original scene.
function getSceneCopy()

    -- Get the selected render target and check it
    local selectedRt = octane.project.getSelection()[1]
    if not selectedRt or selectedRt:getProperties().type ~= octane.NT_RENDERTARGET then
        showError("TurntableG Error!","no render target selected", true)
    end

    -- Get the graph that owns the rt node (THIS IS WHAT CHANGED HERE!)
    local ownerGraph = selectedRt:getProperties().graphOwner
    print(ownerGraph)

    -- find the index of the selected render target node
    local idx = -1
    for i, item in ipairs(ownerGraph:getOwnedItems()) do
        if item == selectedRt then
            idx = i
            break
        end
    end
    -- see if we could find the node
    if idx == -1 then showError("TurntableG Error!","no render target selected", true) end
   
    -- create a full copy of the project so that we don't modify the original project
    local copyScene = octane.nodegraph.createRootGraph("Project Copy")
    copyScene:copyFromGraph(ownerGraph)
    copies = copyScene:getOwnedItems()
    copyRt = copies[idx]
   
    -- check if the copied node is a render target with a thinlens camera connected to it
    if not copyRt or copyRt:getProperties().type ~= octane.NT_RENDERTARGET then
        showError("TurntableG Error!","no render target selected", true)
    end

    -- check if a thin lens camera is connected to the render target
    local copyCam = copyRt:getInputNode(octane.P_CAMERA)
    if not copyCam or copyCam :getProperties().type ~= octane.NT_CAM_THINLENS then
        showError("TurntableG Error!","no thinlens camera connected to the render target", true)
    end

    -- Find all render targets
    local renderTargets = octane.nodegraph.getRootGraph():findNodes(octane.NT_RENDERTARGET)
    local renTargList = {}
    for i, item in ipairs(renderTargets) do
        -- renTargList[item:getProperties().name] = item
        renTargList[#renTargList + 1] = item:getProperties().name
    end

    return copyScene, copyRt, copyCam, renTargList
end


The downside of the above method is that when the camera is in the root scene graph but the render target is nested in another graph, the original camera is modified by this script.

Another approach would be the create a function that returns all the items, including the nested items. This would work like this:

Code: Select all
-- Returns all the items, even those owned by nested graphs.
local function getAllItems(graph)
    local all = {}
    for i, item in ipairs(graph:getOwnedItems()) do
        -- for graphs we recursively collect all the items
        if item:getProperties().isGraph then
            local nested = getAllItems(item)
            -- merge the tables
            for j, nestedItem in ipairs(nested) do
                table.insert(all, nestedItem)
            end
        else
            table.insert(all, item)
        end
    end
    return all
end


-- Returns copies of the original scene graph, the camera node and the rendertarget.
-- This prevents us from modifying the original scene.
function getSceneCopy()
    -- get the selected render target
    local selectedRt = octane.project.getSelection()[1]
    -- find the index of the selected render target node
    local idx = -1
    for i, item in ipairs(getAllItems(octane.nodegraph.getRootGraph())) do
        if item == selectedRt then
            idx = i
            break
        end
    end
    -- see if we could find the node
    if idx == -1 then showError("TurntableG Error!","no render target selected", true) end
   
    -- create a full copy of the project so that we don't modify the original project
    local copyScene = octane.nodegraph.createRootGraph("Project Copy")
    copyScene:copyFrom(octane.nodegraph.getRootGraph():getOwnedItems())
    copies = getAllItems(copyScene)
    copyRt = copies[idx]
   
    -- check if the copied node is a render target with a thinlens camera connected to it
    if not copyRt or copyRt:getProperties().type ~= octane.NT_RENDERTARGET then
        showError("TurntableG Error!","no render target selected", true)
    end

    -- check if a thin lens camera is connected to the render target
    local copyCam = copyRt:getInputNode(octane.P_CAMERA)
    if not copyCam or copyCam :getProperties().type ~= octane.NT_CAM_THINLENS then
        showError("TurntableG Error!","no thinlens camera connected to the render target", true)
    end

    -- Find all render targets
    local renderTargets = octane.nodegraph.getRootGraph():findNodes(octane.NT_RENDERTARGET)
    local renTargList = {}
    for i, item in ipairs(renderTargets) do
        -- renTargList[item:getProperties().name] = item
        renTargList[#renTargList + 1] = item:getProperties().name
    end

    return copyScene, copyRt, copyCam, renTargList
end


This is the most flexible, maybe we should add getAllItems to the API itself.

I hope this helps to clarify things a bit.

cheers,
Thomas
User avatar
stratified
OctaneRender Team
OctaneRender Team
 
Posts: 945
Joined: Wed Aug 15, 2012 6:32 am
Location: Auckland, New Zealand

Re: Grimm's take on the turntable anim script

Postby stratified » Wed Jan 01, 2014 9:10 pm

stratified Wed Jan 01, 2014 9:10 pm
pixelrush wrote:Diverting this thread momentarily,
Thomas,
I was wondering about reading in camera xyz points to a table, either obtained from excel as interpolated points on a best fit curve or obtained from a CAD program or say Maple/Mathematica. Excel might allow a quick way to come up with a smooth path between known points without getting overly serious about providing this inside Octane. I know this is getting more complex for animation than you wanted though. Aside from the possibility of a simple custom list of sequential camera shots for oneself I was thinking of a user shared library of std paths. Elliptical orbit , or shallow parabolic flyby come to mind. I know that instance data can be inserted into Octane so I guess those or camera positions ought to be loadable from Lua as well?


Parsing files from external programs shouldn't be an issue (if you know how to parse them). And camera positions could be loaded in Lua, Octane doesn't have like a "standard" file format for this like with scatter nodes so scripts need to come up with their own format.

A library of paths is a great idea but that's something we (Octane devs) don't want to maintain. It doesn't scale, there will always be paths missing in Octane ... . And there are excellent open source libraries available that do this:

https://github.com/emmanueloga/easing

cheers,
Thomas
User avatar
stratified
OctaneRender Team
OctaneRender Team
 
Posts: 945
Joined: Wed Aug 15, 2012 6:32 am
Location: Auckland, New Zealand

Re: Grimm's take on the turntable anim script

Postby pixelrush » Wed Jan 01, 2014 11:36 pm

pixelrush Wed Jan 01, 2014 11:36 pm
OK thanks.
Looking at the easing docs it isn't clear to me if the functions handle 3d or not?
We still need to input a list of camera way points somehow or be able to pick them with a cursor in the render window. I think the way you have described it we are locked out of doing that running a script so that leaves reading in a file originating elsewhere like a simple .txt or .csv Anyway I realise this is all much harder than just using the animation capability inside Blender or Maya...
Aside from this stuff it occurs to me you could write a short script to climb stairs with a key assignment while using WASD navigation... for this type of thing you might like the editor and UI to run minimised by choice.
Sorry to interrupt here. ;)
i7-3820 @4.3Ghz | 24gb | Win7pro-64
GTS 250 display + 2 x GTX 780 cuda| driver 331.65
Octane v1.55
User avatar
pixelrush
Licensed Customer
Licensed Customer
 
Posts: 1618
Joined: Mon Jan 11, 2010 7:11 pm
Location: Nelson, New Zealand

Re: Grimm's take on the turntable anim script

Postby grimm » Thu Jan 02, 2014 12:32 am

grimm Thu Jan 02, 2014 12:32 am
Thanks Thomas,

I'm thinking that we might not want to require the user to select the render target before the script is ran. I already have a render target pulldown to choose one so the getAllItems function might be the best way. Also we could weed out any targets that are not thin lense and if the list is empty put up an error. This might solve these problems?

Jason
Linux Mint 20 x64 | Nvidia GTX 980 4GB (displays) RTX 2070 8GB| Intel I7 5820K 3.8 Ghz | 32Gb Memory | Nvidia Driver 460.56
User avatar
grimm
Licensed Customer
Licensed Customer
 
Posts: 1321
Joined: Wed Jan 27, 2010 8:11 pm
Location: Spokane, Washington, USA

Re: Grimm's take on the turntable anim script

Postby grimm » Thu Jan 02, 2014 12:38 am

grimm Thu Jan 02, 2014 12:38 am
pixelrush wrote:OK thanks.
Looking at the easing docs it isn't clear to me if the functions handle 3d or not?
We still need to input a list of camera way points somehow or be able to pick them with a cursor in the render window. I think the way you have described it we are locked out of doing that running a script so that leaves reading in a file originating elsewhere like a simple .txt or .csv Anyway I realise this is all much harder than just using the animation capability inside Blender or Maya...
Aside from this stuff it occurs to me you could write a short script to climb stairs with a key assignment while using WASD navigation... for this type of thing you might like the editor and UI to run minimised by choice.
Sorry to interrupt here. ;)


No problem, I have been giving this some thought. I was thinking that maybe a series of render targets might work. You could adjust the camera's position and target for each one and the script would animate the camera through them. There are problems with this though, we would need a way to keep them in order so the animation doesn't skip around randomly. Also you would have to be very careful in how you set up each of the targets, it would be easy to have a situation where the camera would swing around in the wrong direction. Finally it would not be very intuitive in how it works and you would only be able to see the path from the camera's point of view.

Jason
Linux Mint 20 x64 | Nvidia GTX 980 4GB (displays) RTX 2070 8GB| Intel I7 5820K 3.8 Ghz | 32Gb Memory | Nvidia Driver 460.56
User avatar
grimm
Licensed Customer
Licensed Customer
 
Posts: 1321
Joined: Wed Jan 27, 2010 8:11 pm
Location: Spokane, Washington, USA

Re: Grimm's take on the turntable anim script

Postby stratified » Thu Jan 02, 2014 12:49 am

stratified Thu Jan 02, 2014 12:49 am
Hi Jason,

It isn't mandatory to select the render target before running the script. I used that approach because it was used in the turntable animation in older Octane versions. You could use the combo box exclusively. It's less usefull (I think) if the user has 10 render targets, all named "Render Target". You could give some visual clues by selecting the render target in the editor but I don't think it's worth it. That's just my opinion of course and it's your code. You already made it way more useful than the script we presented initially.

BTW: You don't have to credit Roeland and me in the header of your script. The code we provide can just be used. Of course we don't guarantee that it won't stop the universe.

cheers,
Thomas
User avatar
stratified
OctaneRender Team
OctaneRender Team
 
Posts: 945
Joined: Wed Aug 15, 2012 6:32 am
Location: Auckland, New Zealand

Re: Grimm's take on the turntable anim script

Postby stratified » Thu Jan 02, 2014 4:03 am

stratified Thu Jan 02, 2014 4:03 am
pixelrush wrote:OK thanks.
Looking at the easing docs it isn't clear to me if the functions handle 3d or not?
We still need to input a list of camera way points somehow or be able to pick them with a cursor in the render window. I think the way you have described it we are locked out of doing that running a script so that leaves reading in a file originating elsewhere like a simple .txt or .csv Anyway I realise this is all much harder than just using the animation capability inside Blender or Maya...
Aside from this stuff it occurs to me you could write a short script to climb stairs with a key assignment while using WASD navigation... for this type of thing you might like the editor and UI to run minimised by choice.
Sorry to interrupt here. ;)


The easing lib seems to use support only 2D curves. But this shouldn't be any problem for camera animations where the position stays in the same plane (Like most of the movements discussed here).

Like Roeland already pointed out, animation capabilities aren't supposed to be a core part of Octane. The host apps are better equiped to do that, fully scripted animation capabilities (key frame editor, fully controlable camera, vertex, ... paths) will require a non-trivial amount of code and time.

cheers,
Thomas
User avatar
stratified
OctaneRender Team
OctaneRender Team
 
Posts: 945
Joined: Wed Aug 15, 2012 6:32 am
Location: Auckland, New Zealand

Re: Grimm's take on the turntable anim script

Postby pixelrush » Thu Jan 02, 2014 4:49 am

pixelrush Thu Jan 02, 2014 4:49 am
I tried a wee experiment in Solidworks. The path here is a projected one arising from an ellipse and a parabola. I then divided the path equally into 24 (edit actually I see one is accidentally repeated) and used a macro to save out the co-ords to a txt file.
This was quite quick and easy to do. Virtually any imaginable geometry could be used as a basis for obtaining the camera position for each frame. All it needs is to be read into the script.
You are right though, how much functionality is enough considering cg apps do this natively?
Still at least if someone wanted to, they could do this type of thing, although you are 'not supposed to'. Just don't tell Uncle Roeland about it :)
Attachments
camera path experiment.txt
(1.28 KiB) Downloaded 277 times
camera path experiment.jpg
i7-3820 @4.3Ghz | 24gb | Win7pro-64
GTS 250 display + 2 x GTX 780 cuda| driver 331.65
Octane v1.55
User avatar
pixelrush
Licensed Customer
Licensed Customer
 
Posts: 1618
Joined: Mon Jan 11, 2010 7:11 pm
Location: Nelson, New Zealand

Re: Grimm's take on the turntable anim script

Postby stratified » Thu Jan 02, 2014 8:39 pm

stratified Thu Jan 02, 2014 8:39 pm
hi all,

I just realised that getInputNode and getInputNodeIx are already part of the Lua API. It's important to use these instead of getConnectedNode and getConnectedNodeIx, unless you explicitely want to do something with the linker nodes in between. But if not, it might save you a lot of headaches.

We've been using it in all our examples as well so it's an oversight on our side.

cheers,
Thomas
User avatar
stratified
OctaneRender Team
OctaneRender Team
 
Posts: 945
Joined: Wed Aug 15, 2012 6:32 am
Location: Auckland, New Zealand

Re: Grimm's take on the turntable anim script

Postby r-username » Thu Jan 02, 2014 9:22 pm

r-username Thu Jan 02, 2014 9:22 pm
stratified wrote:Like Roeland already pointed out, animation capabilities aren't supposed to be a core part of Octane. The host apps are better equiped to do that, fully scripted animation capabilities (key frame editor, fully controlable camera, vertex, ... paths) will require a non-trivial amount of code and time.


hmm.
Over the holidays I purchased the blender-octane plugin just for path and pan/truck animation, while the plugin works ok and is worth the price it's nowhere near the performance that the standalone provides.

If I were to set up a turntable animation in blender and render using blender plugin/render server, it's not even close to the speed and quality (motion blur, etc) that I would get with the lua turntable script.

It's like having a render session over lunch vs. overnight.

just my experience
i7 960 - W7x64 - 12 GB - 2x GTX 780ti
http://www.startsimple.com/ - http://www.gigavr.com/
r-username
Licensed Customer
Licensed Customer
 
Posts: 217
Joined: Thu Nov 24, 2011 3:39 pm
PreviousNext

Return to Lua Scripting


Who is online

Users browsing this forum: No registered users and 7 guests

Fri Apr 19, 2024 12:28 pm [ UTC ]