after a very short render time I am getting an extended (up to a couple of minutes) wait while the Frame buffer is returned.
This did not happen in the last version of Krakatoa, but I am using a diff workstation.
anyone, or is this just me.
cheers
I think I know what it is, and it is most probably my fault.
I would like to ask you to try something:
In the Krakatoa Scripted GUI, open the History rollout and uncheck the “Save History” checkbox. Try rendering as usual - does anything change?
I am pretty sure the delay is caused by the History feature collecting scene data and that it was fixed in the upcoming 0.9.5. I can give you details if you want to know what was going on. I can even send you an update of the 0.9.4 script with this fixed!
Cheers,
Borislav “Bobo” Petrov
Technical Director 3D VFX
Frantic Films Winnipeg
Ok, please try replacing your KrakatoaGUI.ms file with this version and see if it changes anything.
Unzip and place in the C:\Program Files\Frantic Films\Krakatoa\3dsmax9\Win32 or whatever version you are using. The script is the same for all Max versions.
Cheers,
Borislav “Bobo” Petrov
Technical Director 3D VFX
Frantic Films Winnipeg
ah good stuff,
thx
all works just fine now.
cheers
hi,
I’m using 0.9.8 sp1 and save history is off – and it still takes a while (5-8 seconds) to release the framebuffer…
thanks,
joe
I’m using 0.9.8 sp1 and save history is off – and it still takes a
while to release the framebuffer… <<
I haven’t noticed this. How much time is it taking?
>hi,
>
>I'm using 0.9.8 sp1 and save history is off -- and it still
>takes a while (5-8 seconds) to release the framebuffer...
>
>thanks,
>joe
>
Please try this:
1. Open the Log Window.
2. Clear the Log Window (Edit>Clear)
3. Set it to Debug mode (Edit>Logging Level>Logging Debug)
4. Render a frame
Now see the content of the Log file after PRG:Done! (which is the end of the rendering process). Does it list anything else?
On my machine, it returns immediately and the last lines printed are
PRG: Returning Framebuffer
PRG: Done!
DBG: -Render History NOT SAVED!
If you see the last line and it takes 5-8 seconds to return to normal mode AFTER that point, then the wait is NOT in Krakatoa but might be in Max itself or Thinking Particles, or PFlow, or who knows where.
If the wait is BEFORE the last DBG line is printed, I will have to add some more debug prints and send you a version to test so we can figure out where it happens.
Btw, Saving History has precise debug prints with milliseconds timestamps so you can enable it and watch how it goes - I expect it to be fast.
Thanks in advance for helping us debug this issue...
Cheers,
Borislav "Bobo" Petrov
Technical Director 3D VFX
Frantic Films Winnipeg
thanks,Bobo,
maybe it’s just the Returning Framebuffer that feels part of the delay…
once the framebuffer is returned the system is ready again.
here’s what the log shows:
PRG: Returning Framebuffer
PRG: Done!
DBG: >Populating Particle Systems List with All Sources
DBG: +Particle Systems List POPULATED in 5906ms.
DBG: -Render History NOT SAVED!
thanks
>DBG: +Particle Systems List POPULATED in 5906ms.
>DBG: -Render History NOT SAVED!
>
There you go!
6 seconds to repopulate the Particle Systems List!
I fixed this by adding a new default List mode "None" that does not update at all. So by default, the Particle Systems List will be empty until you specify a type of particles to show.
Just out of curiosity, how many objects and faces are in the scene?
Cheers,
Borislav "Bobo" Petrov
Technical Director 3D VFX
Frantic Films Winnipeg
hehe, just a 4x4 plane! 16 polys
TP is set to emit ~10k particles via Matterwaves, actual emission is 9990.
and that SP2 works great! super fast update -- no delay at all. Thanks!
I was calling classof several times to collect data to populate the list. Since I don't have TP installed at all on my new 64 bit machine, I had no idea how TP would react. It is possible that it gets refreshed each time it gets hit by a loop checking for the object class... I will add some time stamping per object next time around, would be good to know what the 6 seconds were caused by.
Does the new one behave as expected (read: faster) ?
Borislav "Bobo" Petrov
Technical Director 3D VFX
Frantic Films Winnipeg
yep, the new SP2 script works uber-fast - no delay at all. thanks
yep, the new SP2 script works uber-fast - no delay at all. thanks <<
Excellent! Good catch! Thanks for the report and troubleshooting help.
my pleasure!
sadly, it sounds like testing TP will be limited for a while, but I’ll see what else can be found…
thanks