Page 1 of 2
Node order issue
Posted: Fri Jan 03, 2014 10:51 pm
by grimm
Hi Thomas,
I have come across an interesting issue. I noticed that the order that the nodes are returned is in the opposite order in which they were created. I wanted to select the first node created but what I got was a render target node called "Old Mesh Preview RenderTarget" which wasn't really what I was after. Any way to sort these so they are in the order they were created?
Thanks,
Jason
Re: Node order issue
Posted: Fri Jan 03, 2014 11:00 pm
by stratified
Hi Jason,
You mean calling getSelection()
or calling getOwnedItems
? Don't know which function your getting the returned nodes from...
thanks,
Thomas
Re: Node order issue
Posted: Fri Jan 03, 2014 11:20 pm
by grimm
Oops, sorry.

That would be the getOwnedItems function. Thanks,
Jason
Re: Node order issue
Posted: Sat Jan 04, 2014 4:07 am
by stratified
Hi Jason,
We can't guarantee the order of the table returned by
getOwnedItems()
, we don't keep an explicit sorting order in Octane.
If you want a fixed order, you'll have to sort them yourself (for example on name or horizontal position). You can use Lua's sort function
http://www.lua.org/manual/5.1/manual.ht ... table.sort.
I hope this helps.
cheers,
Thomas
Re: Node order issue
Posted: Sat Jan 04, 2014 4:42 am
by grimm
Yes that is what I attempted to do but I keep pulling in nodes that I didn't place in the graph, the "Old Mesh Preview RenderTarget" named node is one that getOwnedItems finds at the end of the node list. Usually I just break when I find the first node, this is usually the last node I have created in the graph. I wanted the first node created so I removed the break and let the for loop run to the very last node (which should be the first one created?). Instead I get a node that I didn't create and it doesn't work anyway because it has no camera associated with it.
1.24 is acting very strangely with Lua, it seems that every time I run the script something different happens. I removed the break command so the script would find the last node and I got this error:
Code: Select all
No pin P_CAMERA in nodes with type NT_CAM_THINLENS
I run it again and I get:
Code: Select all
No pin P_CAMERA in nodes with type NT_GEO_MESH
And again I get:
No pin P_CAMERA in nodes with type NT_KERN_DIRECTLIGHTING
The error is for this line in turntableG_anim.lua:
Code: Select all
local copyCam = copyRt:getInputNode(octane.P_CAMERA)
I posted the rest of the code in my turntable thread, very strange. It's probably me doing something bad in the code.
Thanks,
Jason
Re: Node order issue
Posted: Sat Jan 04, 2014 5:02 am
by stratified
Yeah, this is the problem that I described in the other post (using the same index in lists that don't have the same order).
The "Old Mesh Preview Target" is there when you opened a pre 1.21 project. But like I said, don't rely on the order of getOwnedItems
. I think we somehow need to find a way to "copy" the original selection.
cheers,
Thomas
Re: Node order issue
Posted: Wed Jan 08, 2014 8:16 pm
by stratified
Hi Jason,
In the next release (1.26), we should be able to work around these problems.
copyFrom
and
copyFromGraph
now take an optional list of nodes for which you want to now what it's copy it. So you're able to get a full mapping from originals to copies without doing any special hacks.
For example
getSceneCopy()
got a lot simpler because we don't have to do any special hacks to find the selected render target:
Code: Select all
-- Returns copies of:
-- * the original scene graph
-- * the sun direction node connected to the daylight environment
-- * the render target node
-- These copies prevent us from modifying the original scene
local function getSceneCopy()
-- get the selected render target
local selectedRt = octane.project.getSelection()[1]
if not selectedRt or selectedRt:getProperties().type ~= octane.NT_RENDERTARGET then
showError("no render target selected", true)
end
-- Create a full copy of the whole project so we don't modify the original project.
local copyScene = octane.nodegraph.createRootGraph("Project Copy")
local copyRt = copyScene:copyFromGraph(octane.nodegraph.getRootGraph(), { selectedRt })[1]
-- check if a daylight environment is connected to the render target
local copyEnv = copyRt:getInputNode(octane.P_ENVIRONMENT)
if not copyEnv or copyEnv:getProperties().type ~= octane.NT_ENV_DAYLIGHT then
showError("no daylight environment connected to the render target", true)
end
-- check if a sun direction is connected to the daylight environment
local copySunDir = copyEnv:getInputNode(octane.P_SUN_DIR)
if not copySunDir or copySunDir:getProperties().type ~= octane.NT_SUN_DIRECTION then
showError("no sun direction connected to the daylight environment", true)
end
return copyScene, copyRt, copySunDir
end
cheers,
Thomas
Re: Node order issue
Posted: Wed Jan 08, 2014 9:27 pm
by grimm
Thanks Thomas, good news.

How will this affect pulling in all the render target nodes from the graph? I need to do this to populate the render target pulldown.
Jason
Re: Node order issue
Posted: Thu Jan 09, 2014 2:49 am
by stratified
grimm wrote:Thanks Thomas, good news.

How will this affect pulling in all the render target nodes from the graph? I need to do this to populate the render target pulldown.
Jason
We'll add an optional parameter to the graph module's "find" functions to search recursively. That way you can pull all render targets without having to worry where exactly they are.
cheers,
Thomas
Re: Node order issue
Posted: Thu Jan 09, 2014 7:13 am
by grimm
Awesome that's perfect! Thanks Thomas. I'm looking forward to 1.26.
Jason