Thanks for the scripting nodes, they are very cool.
Scripted node stuff
Hi Thomas, Roland,
Thanks for the scripting nodes, they are very cool.
I'm having a ton of fun playing around with them, which gave me some ideas that would be nice to have for them. Would it be possible to have the onEvaluate function be passed another parameter, like a table? The table would have in it what triggered the event (caller), like which input linker or animator if a time change. Also it would be great if the table also had in it some other ancillary information, like frame number or time stamp, etc. Having this would make it easier to do different things for different event types and be able to handle animations better. Unless there is already a method in place to do such things that I not aware of. 
Thanks for the scripting nodes, they are very cool.
Linux Mint 21.3 x64 | Nvidia GTX 980 4GB (displays) RTX 2070 8GB| Intel I7 5820K 3.8 Ghz | 32Gb Memory | Nvidia Driver 535.171
- stratified

- Posts: 945
- Joined: Wed Aug 15, 2012 6:32 am
- Location: Auckland, New Zealand
Hi Jason,
Happy to hear you like it
You can use
cheers,
Thomas
Happy to hear you like it
You can use
inputWasChanged to check which input linker changed. Time events are only triggered by the user or a script moving the timeline. You can query the current time directly from every node or graph (e.g. node.time). Have a look at the script I posted on Friday for the details.cheers,
Thomas
Thanks Thomas that is perfect. Your script is giving me a lot of ideas, very cool.
I'm having a problem with the values that the .time function returns, it doesn't appear to be the same as the timeline scrubber. Look like it's off by one. If I'm on frame 0 it reports 0, which is good. If I move the scrubber to frame 1 it reports zero again. Move the scrubber to frame 2 and it reports the time for frame one, etc.
Then if I move the scrubber back to zero from frame 2 it first reports the time for frame 2 instead of 1. Then when the scrubber reaches zero it reports the time for frame 1. Looks like it's reporting the time it came from instead of the time it is currently on?
Thanks,
Jason
I'm having a problem with the values that the .time function returns, it doesn't appear to be the same as the timeline scrubber. Look like it's off by one. If I'm on frame 0 it reports 0, which is good. If I move the scrubber to frame 1 it reports zero again. Move the scrubber to frame 2 and it reports the time for frame one, etc.
Then if I move the scrubber back to zero from frame 2 it first reports the time for frame 2 instead of 1. Then when the scrubber reaches zero it reports the time for frame 1. Looks like it's reporting the time it came from instead of the time it is currently on?
Thanks,
Jason
Linux Mint 21.3 x64 | Nvidia GTX 980 4GB (displays) RTX 2070 8GB| Intel I7 5820K 3.8 Ghz | 32Gb Memory | Nvidia Driver 535.171
- stratified

- Posts: 945
- Joined: Wed Aug 15, 2012 6:32 am
- Location: Auckland, New Zealand
Can you post a little example script so I can have a look?grimm wrote:Thanks Thomas that is perfect. Your script is giving me a lot of ideas, very cool.
I'm having a problem with the values that the .time function returns, it doesn't appear to be the same as the timeline scrubber. Look like it's off by one. If I'm on frame 0 it reports 0, which is good. If I move the scrubber to frame 1 it reports zero again. Move the scrubber to frame 2 and it reports the time for frame one, etc.
Then if I move the scrubber back to zero from frame 2 it first reports the time for frame 2 instead of 1. Then when the scrubber reaches zero it reports the time for frame 1. Looks like it's reporting the time it came from instead of the time it is currently on?
Thanks,
Jason
Hey Thomas,
Sorry looks like more issues, maybe? When I render my animation through the turntable script the script node is getting ignored. Also when I stop the render and exit the script it put Octane in a very strange state. If I try and load another ocs file it locks up Octane so tight I have to kill it with the -9 option.
Sorry looks like more issues, maybe? When I render my animation through the turntable script the script node is getting ignored. Also when I stop the render and exit the script it put Octane in a very strange state. If I try and load another ocs file it locks up Octane so tight I have to kill it with the -9 option.
Linux Mint 21.3 x64 | Nvidia GTX 980 4GB (displays) RTX 2070 8GB| Intel I7 5820K 3.8 Ghz | 32Gb Memory | Nvidia Driver 535.171
Well now it looks like the ocs file I saved of the scene crashes Octane.
One of my CPUs gets pegged at 100% and I have to kill -9 it.
Thanks Thomas, I'm a pest today aren't I.
Thanks Thomas, I'm a pest today aren't I.
Linux Mint 21.3 x64 | Nvidia GTX 980 4GB (displays) RTX 2070 8GB| Intel I7 5820K 3.8 Ghz | 32Gb Memory | Nvidia Driver 535.171
- stratified

- Posts: 945
- Joined: Wed Aug 15, 2012 6:32 am
- Location: Auckland, New Zealand
Hi Jason,
Don't worry, we're happy that you're willing to help fleshing out the bugs.
The crash is a bug in Octane you uncovered. It happens when you tried to access the root graph of the project while the project is still loading. You can work around this by refraining from doing anything with the root node graph in the
cheers,
Thomas
Don't worry, we're happy that you're willing to help fleshing out the bugs.
You should usegrimm wrote:Thanks Thomas that is perfect. Your script is giving me a lot of ideas, very cool.
I'm having a problem with the values that the .time function returns, it doesn't appear to be the same as the timeline scrubber. Look like it's off by one. If I'm on frame 0 it reports 0, which is good. If I move the scrubber to frame 1 it reports zero again. Move the scrubber to frame 2 and it reports the time for frame one, etc.
Then if I move the scrubber back to zero from frame 2 it first reports the time for frame 2 instead of 1. Then when the scrubber reaches zero it reports the time for frame 1. Looks like it's reporting the time it came from instead of the time it is currently on?
Thanks,
Jason
graph.time instead of rootGraph.time, The time in the document is updated bottom-up. This means that the scripted graph is updated first and then the root graph. The callbacks are done as soon as the scripted graph is updated but at that point the root graph isn't updated yet and hence has still the old time stamp.I haven't tested this but the turntable animation takes a copy of the full scene but your graph script still grabs the original root graph on initialization. So I think you're always querying the time of the original unmodified project.grimm wrote:Hey Thomas,
Sorry looks like more issues, maybe? When I render my animation through the turntable script the script node is getting ignored. Also when I stop the render and exit the script it put Octane in a very strange state. If I try and load another ocs file it locks up Octane so tight I have to kill it with the -9 option.
The crash is a bug in Octane you uncovered. It happens when you tried to access the root graph of the project while the project is still loading. You can work around this by refraining from doing anything with the root node graph in the
onInit function.cheers,
Thomas
Thanks Thomas, that makes sense, unfortunately I'm still getting the lag after I changed the code to use graph instead of the root graph. Here is an updated test script:stratified wrote: You should usegraph.timeinstead ofrootGraph.time, The time in the document is updated bottom-up. This means that the scripted graph is updated first and then the root graph. The callbacks are done as soon as the scripted graph is updated but at that point the root graph isn't updated yet and hence has still the old time stamp.
Ah, that makes sense too.stratified wrote: I haven't tested this but the turntable animation takes a copy of the full scene but your graph script still grabs the original root graph on initialization. So I think you're always querying the time of the original unmodified project.
I removed all of the references to the root graph in onInit but it's still locking Octane up.stratified wrote: The crash is a bug in Octane you uncovered. It happens when you tried to access the root graph of the project while the project is still loading. You can work around this by refraining from doing anything with the root node graph in theonInitfunction.
Edit: Or is the get project settings also affecting it?
Linux Mint 21.3 x64 | Nvidia GTX 980 4GB (displays) RTX 2070 8GB| Intel I7 5820K 3.8 Ghz | 32Gb Memory | Nvidia Driver 535.171
- stratified

- Posts: 945
- Joined: Wed Aug 15, 2012 6:32 am
- Location: Auckland, New Zealand
Hi Jason,
I think you're getting confused by the rounding errors:
The time in Octane is represented in floating point. For example if you have 25 fps, the frame duration is 0.04 seconds. In floating point this is represented as 0.03999... . If you then use math.floor(currentTime / frameTime), you will always underestimate the frame number. What you should do is have an epsilon and if you're close enough to the integer, clamp it to the integer. I know it's subtle but there's not much we can do here.
It is operating in it's own graph. The turntable animation script takes a copy of the root graph of the project but not of the project itself. But
Accessing the project settings is the culprit here. I guess the best thing is to always fetch them during evaluation.
cheers,
Thomas
I think you're getting confused by the rounding errors:
Code: Select all
****Event Started****
Scrubber Time - 0.03999999910593
I think this is frame # 0
It is operating in it's own graph. The turntable animation script takes a copy of the root graph of the project but not of the project itself. But
octane.project.getSceneGraph() will always return the root graph of the original project. You can get around this by getting the parent graph of the scripted graph which is always the correct one.Accessing the project settings is the culprit here. I guess the best thing is to always fetch them during evaluation.
cheers,
Thomas
