%SUMATRAPATH%\moaudio.dll and FXTree errors

[Eric Lampi]

' ERROR : 2000 - Unable to create object
[CLSID{A8BF89CA-1025-11D2-B5FD-006094EB029C}] :
%SUMATRAPATH%moaudio.dll, Cleanup will be performed.

I've been getting this error and I am not sure why. It just started
happening all of the sudden and Soft 2013, and sp1 will not load these
scenes.

Reinstallation fixes it, as does the runonce.bat file, but now I am
crashing when using the FXtree. I adjust the amount of RAM to what is
suggested by SoftImage (8000 mb in this case) and restart. When
reloading that scene, it tells me that 0 mb of RAM is allocated to the
FXtree when I know for a fact it isn't.

I've never had a problem with the FXtree and I am at a loss as to how
to fix this. I tried deleting my user folder, reinstalling and
starting from a new scene to build the comp.

It's as if the FXtree is busted somehow...

Suggestions appreciated!

Eric

--
Freelance 3D and VFX animator

http://vimeopro.com/user7979713/3d-work

[Luc-Eric Rousseau]

the fxtree will need to create a 8 gig temp file in the temp folder
and allocate 8 gig of continuous ram. It may crash if it can't,
I recommend not giving the fxtree so much RAM. If you're dealing with
large images larger than 2k, I recommend you use a another product.
For example, Composite will handle 12k, it does tile-based rendering.

The registry error is unrelated.

[Jason S]

FXTree does become unstable if you give it too much memory (in preferences).

Although..  I don't know if any of you here ever managed to overwhelm the FXTree, but I sure haven't..

In this project, (4k wide projections for Celine Dion) we started in Nuke,
and actually moved to the FXTree for the shots with the most stuff,
because it would just crunch through whatever the frame (or tree) size at a couple of seconds per frame, even at insane resolutions.

While Nuke would just slow to a crawl (with 16 gigs of ram at the time)
(as Nuke (like many others) just *can't* run out of memory without taking forever.)

I this screenshot, I put resize nodes at the root (just after sources) tripling the already high resolution and still went without flinching(!)

So I don't know how it manages memory.. but it sure does not shy away from lifting anything heavy!

On 16/04/2013 10:34 AM, luceric wrote:    

the fxtree will need to create a 8 gig temp file in the temp folder 
and allocate 8 gig of continuous ram. It may crash if it can't, 
I recommend not giving the fxtree so much RAM. If you're dealing with 
large images larger than 2k, I recommend you use a another product. 
For example, Composite will handle 12k, it does tile-based rendering. 

The registry error is unrelated. 

[pet...@skynet.be]

I almost agree.

In my experience FXtree is great as long as you stick to 8 or 16 bit images and perhaps very localized switching to 32bit on a small part of the tree.

EXR images, handled in float - has been a total no-go for me – even a simple 4 layer slap comp at HD res was painstakingly slow, and yes I did try to give it more ram. I’d love to be proven wrong though.

Either way it doesn’t offer much in terms of a linear workflow, and clamps pretty much anything – so not a lot you can do with those EXRs - and that’s where Nuke delivers in spades. It can be a drag taking up ram and slowing down - emptying buffers should be the operation you do the most on Nuke.

[Jason S]

Well,

It supports float images (exr's or otherwise)
in the sense that color values can go beyond 1
that includes added/multiplied values using color corrects or composite nodes,
and blurring (or anything) will consider those values.

Yet in my example scene,
I put all sources in float (previously in 16 bit) in 12k
and displayed an 'out of memory' message.

So I guess what prevents the FXTree's memory to be increased
is something else that could need some fixing.  :\

OT/FYI  In nuke, you can put  nukescripts.cache_clear("")    (when rendering)
in the  after each frame  field in the Python tab of write nodes which really helps alot.

[Luc-Eric Rousseau]

None of the blurs, but most of the color correction nodes will clamp values above 1.0 or below 0.0, you have to watch yourself carefully.  For example, everything that works in HSV or uses a lookup table.  The "half float" pixel format survives more cases than the "float" case, and should be also faster