Finally, as a pie in the sky request, some way to insert new points into a shape as it animates. I doubt any rotoshape solution has this, and I have no idea how you could do it, but if you could it would be insanely good

Yeah, it'd almost have to be a blend between the auto-interpolated point (when point = off) and the user-positioned point (on), so that you don't get any curve popping during animation. Like a short buildup/falloff to that point's lifetime.

That's why I suspect the Houdini's architecture is somehow against compositing inside it. I really hope I'm wrong though.

I think one of the main hurdles here is Houdini's Achilles heel - the fact that the UI doesn't run in a separate thread. This is true for compositing as well, and most compositing apps I know of have this feature. It makes a pretty big perceptual different in interactivity. Without it, you're constantly waiting for cooking to complete before you can do anything. I've thrown in a lot of tricks to circumvent this as much as possible, but it's still an issue. Unfortunately, it's a massive technical undertaking at this point (but doable).

Of course, certain COPs and bits of the underlying engine could use some work too One is simply to automatically resize the tiles to the resolution the user's working at (ie, the default 200x200 is rather small & slow if you're working at 1080p - 640x640 works a lot better). Of course, that requires the user to specific the resolution in the Compositing Project options, which I'm not sure that many people do - especially considering it's an integrated part of Houdini (for some reason, it fits a lot more for standalone apps). There may be a more automatic way around it, I'd have to see.

digitallysane

jeff
Rayz was built on top of Halo. Lots of great building.
Then Apple bought it along with Shake.

I thought Rayz was built from scratch and that Chalice, it's predecessor, was started from SESI code.
Anyway, Rayz was awesome.

Yep, Rayz was brand-new from the ground up. I was talking to one of the developers from Silicon Grail and they basically said that Apple bought it to deep six it as a competitor. He didn't think that any tech from Rayz would make it into Shake. Sad, really.

twod
I think one of the main hurdles here is Houdini's Achilles heel - the fact that the UI doesn't run in a separate thread. This is true for compositing as well, and most compositing apps I know of have this feature. It makes a pretty big perceptual different in interactivity.

You mean actual difference in interactivity, but perceptual difference in performance.

I've said it often enough but I wish for the day when the whole of Houdini to has this, 3D as well as Compositing - imagine never having to hit Escape to cancel cooking when you're dragging a SOP slider around, imagine it immediately recooking without slowing down.

twod
I think one of the main hurdles here is Houdini's Achilles heel - the fact that the UI doesn't run in a separate thread. This is true for compositing as well, and most compositing apps I know of have this feature. It makes a pretty big perceptual different in interactivity. Without it, you're constantly waiting for cooking to complete before you can do anything. I've thrown in a lot of tricks to circumvent this as much as possible, but it's still an issue. Unfortunately, it's a massive technical undertaking at this point (but doable).

That's exactly that I was suspecting, that would explain many things. I'm not going to pretend I understand whole that C++ business but by institution I see the problem. If I'm not wrong Shake's viewer is like a external application that grabs script from a interface, renders it and displays. Pretty much like Houdini->ifd->mantra->mplay pipeline.

Second thing is a cache system, that normally should work automatically flushing data to disk and not allowing this way overflow memory and shut down the process.

Anyway I finally made this test scene today (Edward ops: ). Rather simple real life scenario used to published on the Nothing Real site: desert ship in 2K on stills.

Ubuntu 7.10, 32bit, PentiumD, 3GHz, 2GB RAM:

Shake 4.0: 3.5 seconds for a first frame, average time for rest of 50 frames: 2 seconds. Ram usage ~110MB

Halo 9.1.216: 7 seconds for a first one, 5 seconds for rest. Ram usage 460MB

Well, could be worse actually, only memory usage concerns me. This is very simple scene, what about some huge stuff? Rendering is not so bad, the problems were 4 times hangs, overall GUI sluggish and lack of some features (color compress, expand, Switch Alpha doesn't allow me to choose alpha channel… can be done in VEX though. Does lin/log conversion is only available via FileIn Cineon option!? What about tiffs for example with logarithmic color space, do I have to convert it into cineon?).

Does Halo has some kind of DOD or ROI support (limit the processing area in a plate)? Trying to heavily blur image of 3500x2000 causes immediate shut down.

PS I made this test some years ago for a Combustion and Afx also. On my previous machine Shake 2.4 performed in 12 sec per frame, Afx 6.0 was about 58 seconds, Combustion (2?) couldn't finish any frame btw.

You mean actual difference in interactivity, but perceptual difference in performance.

Well, sort of. Take moving a point on a surface with a peak handle, for example. If you killed the cook & restarted every time the user moved the handle, you'd get next to no interactivity on the geometry, but your handle would be moving around with a good update speed.

I think what would generally be better would be to complete the current interactive cook (while allowing the handle to move about) and when it is finished, take the most recent handle values and recook. The only time you get an interrupt is when you release the mouse button (because obviously you want the final result ASAP).

Second thing is a cache system, that normally should work automatically flushing data to disk and not allowing this way overflow memory and shut down the process.

Yep, this needs to be addressed and I think I may have an idea of why it's using too much memory.

Well, could be worse actually, only memory usage concerns me.

It's probably just caching the results at all nodes. You can change this, if you like, in the compositing options.

lack of some features (color compress, expand, Switch Alpha doesn't allow me to choose alpha channel… can be done in VEX though.

Yep, they're just named differently:

color compress/expand = Color Map cop
arbitrary switch alpha = Channel Copy cop. Switch alpha is just there for convenience.

Does lin/log conversion is only available via FileIn Cineon option!? What about tiffs for example with logarithmic color space, do I have to convert it into cineon?).

Currently, yes, the File node's lin/log conversion is cineon-only (it's actually part of the cineon reader). There are COPs you can use to create an asset to do this (Function>Log, color map, etc), though I agree it's unfortuante that there is no out-of-the-box solution for it.

Does Halo has some kind of DOD or ROI support (limit the processing area in a plate)? Trying to heavily blur image of 3500x2000 causes immediate shut down.

Yep, Shift+LMB drag (or click) on the area you want in the viewer. Shift+S clears the selection.

PS I made this test some years ago for a Combustion and Afx also. On my previous machine Shake 2.4 performed in 12 sec per frame, Afx 6.0 was about 58 seconds, Combustion (2?) couldn't finish any frame btw.

Good to know. Thanks for your investigation!

twod
Yep, they're just named differently:

color compress/expand = Color Map cop
arbitrary switch alpha = Channel Copy cop. Switch alpha is just there for convenience.

I was trying to use Color Map Cop but I couldn't get results similar to Compress/Expand in Shake so I just cheat by adding colors instead of compressing it. Had to look on it again :roll: . I knew I can do this with LookUp but didn't want to bother.

Yep, Shift+LMB drag (or click) on the area you want in the viewer. Shift+S clears the selection.

Hmm, I'm not sure if this is what I meant, sorry. Doesn't that “Shift+LMB” thing apply only in the viewer? What DOD actually does is that it's assigned to a plate in the current point of a composition so it's like cropping the image without cutting out the rest. Even when rendering from a command line, region outside DOD won't be affected until another definition covers it. So its like a resolution inside a actual resolution (OpenExr supports this meta data I think, also Shake's iffs).

I was trying to use Color Map Cop but I couldn't get results similar to Compress/Expand in Shake so I just cheat by adding colors instead of compression it.

Perhaps it's doing something slightly different than just a strict remap then. I'd have to check as well.

Hmm, I'm not sure if this is what I meant, sorry. Doesn't that “Shift+LMB” thing apply only in the viewer?

Yes, it only applies to the viewer. You can use a Window COP to do something similar (crop without cropping), but if you were to go back to the original image size later, it'd still cook the entire image. So it's not quite the same thing.

Having said that, COP will only compute what it needs to for the final image. If you only output a small portion of the image, it'll only cook that. It'll also allow you to output extra information around the frame in the ROP as well, if you like. By default, it only saves the image data in the frame (see the Image Area tab). This works for .pic & .exr. For example, you could output the frame plus the surrounding 200 pixels.

The File In COP will also load these correctly, whether they come from COPs or mantra (or anywhere else, for that matter)

twod

I was trying to use Color Map Cop but I couldn't get results similar to Compress/Expand in Shake so I just cheat by adding colors instead of compression it.

Perhaps it's doing something slightly different than just a strict remap then. I'd have to check as well.

Don't bother with this, please. Any tool works correctly if it's used properly… ops:, sorry.

Thanks for your help,
Cheers,
Simon.

Don't bother with this, please. Any tool works correctly if it's used properly… sorry.

No problem, thanks for checking it out.

twod

You mean actual difference in interactivity, but perceptual difference in performance.

Well, sort of. Take moving a point on a surface with a peak handle, for example. If you killed the cook & restarted every time the user moved the handle, you'd get next to no interactivity on the geometry, but your handle would be moving around with a good update speed.

I'd hope there'd be a throttle/timeout/tolerance on it that wouldn't restart the cook for 0.5 sec or something, especially if the UT_Interrupt can provide a percentage complete so the managing process might get a clue how rapidly the SOP executes.

twod
I think what would generally be better would be to complete the current interactive cook (while allowing the handle to move about) and when it is finished, take the most recent handle values and recook. The only time you get an interrupt is when you release the mouse button (because obviously you want the final result ASAP).

This might herald a new approach when writing SOPs - depending on the parameters/handles being animated, try to update that part of the mesh first. So if cooking is restarted, hopefully the display would show you the currently cooked state of the mesh - and hopefully it'll represent the area of the mesh currently being edited. So it might be okay to see flickering meshes if the region of interest is nicely represented.

SYmek
..Being able to turn off hand animation for some points so that Halo would interpolate them based on a curve shape would let me forget about them once I don't need those additional points on a roto curve.

Normally you have to use a few roto shapes in such a case and switch between them in proper frames.

Being able to have a toggle next to each point that said interpolate from neighbours would be perfect - (in fact not a toggle but a keyable int 0-1, maybe you key toggles in H9 now??). I know switching shapes is doable but with lots of rotos its a real pain and having this option too would be very handy.

The stuff we do doesn't equate to roto-ing a person walking though a shot so the likelyhood is that you will have to switch shapes too many times to make it very practical. Keying an interpolate option on or off would be much more useful.

Also some kind of onion skining to see where points have been animated from would be useful too.