Hi list1
How can I enable camera motion blur in H9?
Thanks

lisux
Hi list1
How can I enable camera motion blur in H9?
Thanks

There was a bug when rendering from the viewport render menu. Rendering from the ROP would correctly pick up camera motion blur.

I believe that later versions of H9 will have correct camera motion blur when rendering from the viewport menu as well (though you have to be looking through the camera)

The basics? Animate a camera and enable motion blur on the output driver.

P.S. I believe it was fixed in version 9.0.731 or later (maybe 732?)

mark
The basics? Animate a camera and enable motion blur on the output driver.

P.S. I believe it was fixed in version 9.0.731 or later (maybe 732?)

Ok thanks.
Anyway I think that more control is needed, I undersatnd that enabling motion blur in the ROP enables in all part, objects and cameras, this is easy but have a great lack of control, and craete rendering properties per object in the scene is sometimes a mess I think that some of the rendering parameters in lights, objects and cameras that exists in H8 should be put in H9, maybe disabled at the beggining but they should be there, I think that rendering properties should be used only for very special parameters and not for so common parameters like motion blur or light/reflection/shadow masks, etc …

I'm not sure what more control you're looking for. A camera pretty much only supports transform motion blur anyway, right? (does it support blur from focal changes? Would be cool)

I actually found that I prefer having it all in one place, because I don't have to check each object individually.
-z

anakin78z
I'm not sure what more control you're looking for. A camera pretty much only supports transform motion blur anyway, right? (does it support blur from focal changes? Would be cool)

I actually found that I prefer having it all in one place, because I don't have to check each object individually.
-z

I am looking for the old view parametrs that are very important to adjust not only the render output but the viewport view, for example.

There's plenty of options for control - the way H9 ships is to have the most common exposed, you add what you need. Look up Edit Parameter Interface for more information. You can do that on an object, search for “blur” and samples and drag and drop them over to the object in whatever tab you want. You can mimic whatever is in a mantra ROP and it will be object-specific.

Before you say it, yes, I agree, this can get tedious. The issue of what parameters should be added where was a hotly contested one. For me, it was important, but I think a more important issue is that there needs to be a far faster methodology to managing parameter interfaces. This one is full-up, and even someone extremely familiar with H9 doesn't have that wall of parameters memorized. You need to hunt, peck, compare…it's pretty time consuming. As an example, in this case you can't get away with simply typing in “blur” in the search field - the method behind mblur has changed for H9, in a very good way, but it's different - you'd also need to search for “samples” and pick through the various results for that. I can see this being very confusing for someone coming from H8. Well, anyone, really.

You can set things to automatically create params with new node creation scripts, but this is out-of-the-box behaviour. I think this needs to be looked at in a future release.

Cheers,

J.C.

JColdrick
Before you say it, yes, I agree, this can get tedious. The issue of what parameters should be added where was a hotly contested one. For me, it was important, but I think a more important issue is that there needs to be a far faster methodology to managing parameter interfaces. This one is full-up, and even someone extremely familiar with H9 doesn't have that wall of parameters memorized. You need to hunt, peck, compare…it's pretty time consuming. As an example, in this case you can't get away with simply typing in “blur” in the search field - the method behind mblur has changed for H9, in a very good way, but it's different - you'd also need to search for “samples” and pick through the various results for that. I can see this being very confusing for someone coming from H8. Well, anyone, really.

J.C.

Complitely agree John, I think there should be a distinvtion between special parameters and common parameters, I think that almost in all the scene one touch the view parameters for the camera, ot light mask, or motion blur setting for objects, these parameters should be by default in the parameters of the object.
Even more, for example, the light linker pane don't work out nof the box because one have to add the light mask parameter to all the objects, this is illogical and crazy, and the most import cause lots of errors and mistakes that consumes a lot of time.
Ok you can custo myour objects creation to include all the parameters you want , for midle/big studios this is not a problem for small or people that want to begin with houdini this so common parameters hidded into the “Edit render parameters” dualog only causes headcaches.

lisux
Complitely agree John, I think there should be a distinvtion between special parameters and common parameters, I think that almost in all the scene one touch the view parameters for the camera, ot light mask, or motion blur setting for objects, these parameters should be by default in the parameters of the object.

What's considered a special and a common parameter depends on the person though. I personally like my nodes slim and trim and adding things as needed. I think what's needed is a nice GUI tool for saving out parameter profiles. Once you have added/removed the parameters from a node/node class that you like a fast method to save that as a $JOB/$HOME/$HSITE setting would be ideal. Like you said, its doable now, but requires messing with the creation scripts, which isn't hard but not very approachable in a panic or for new users.

Just a little clarification. Please try not to take this as a rant, that's not its intent.

To take motion blur for example.

H9 supports multi-segment motion blur. Therefore, it has controls that H8.2 didn't have. The menu in H8.2 was more like a set of presets for motion blur

* Transform Blur: Xform Segments = 2, Deform Segments = 1
* Deform Blur: Xform Segments = 2, Deform Segments = 2
* Inherit: Pick up setting from output driver

In H9, parameters are now inherited from the output driver if they aren't defined at the object level. So, if the parameters don't exist on objects, they are automatically picked up from the output driver.

The way H9 is set up, you can turn on motion blur for the entire scene by setting the parameters on the output driver. If you need finer control, you can add the parameters to individual objects. And this is more work than H8.2. In H8.2, you only had to change a menu entry. In H9, you have to add the parameter and then change the value.

Here are 4 different alternative ideas.

—-

So, one alternative, would be to put the controls for tranform/deform segments on each object.

The problem with this approach would be that to enable motion blur for the entire scene, you'd have to change the parameters on each and every object. And, I don't think this is practical. Especially when objects are locked away in OTLs.

—-

Another alternative would be to have an “inheritance” parameter for the transform and deform parameters. That is, in addition to the parameter for transform segments, you'd also have a toggle which asks whether you want to use the parameter or to inherit from the output driver.

So, instead of having to add a parameter, you'd only have to push a toggle button.

The only real problem with this approach is the extra parameters. One of the goals of H9 was to cut down on the parameter baggage that objects carried around with them. When dealing with OTLs that had 100s of objects all the extra parameters (like the sound material) were quite expensive.

It's my understanding that in typical workflow most objects inherit their behaviour from the output driver. Only in some cases, would you want to override that behaviour.

So, we had to balance having 4 motion blur parameters on each and every object, or having 0 parameters (for the most common case). In the special case, the user would have to add a rendering parameter instead of hitting a toggle button, but with the same effect.

Aside from this, it would be special casing the motion blur controls. Why special toggles for motion blur, and not, shading quality, or ray pre-dicing? Should each and every rendering parameter come with a toggle to specify it's inheritance?

This leads to the third alternative..

—-

A third alternative would be to have the transform/deform parameters added to all objects by default, but to have the parameter bypassed (See the “More->Bypass Spare Parameter” menu entry on parameters).

Instead of a toggle, use the little known spare parameter bypass feature to bypass the motion blur controls (or enable them).

This also is appealing since the parameter would be right there for you. But the whole bypass mechanism is a little obscure and probably confusing at so many levels.

—-

A fourth alternative would be to have a menu for motion blur (like H8.2)

* Specific Blur Settings/Inherit
This menu would give you the current behaviour. If the parameters didn't exist on the object, it would pick up the settings from the output driver. Otherwise, it would pick them up from the object parameters.

* Transform Blur (2 xform segments, 1 deform segment)
Regardless of the output driver settings, or the parameters on the object, choose 2 xform segments and one deform segment.

* Deform Blur (2 xform segments, 2 deform segment)
Regardless of the output driver settings, or the parameters on the object, choose 2 xform/deform segments.

To me, this is not only limiting, but bad design since it's a special case of parameter evaluation just for motion blur controls.

—-

Remember, this is all to get around the fact that you have to add the
parameters to objects… Is it really that odious to add these
parameters?

1st Choice :
I vote for better tools for saving Spare Parameter profiles like I mentioned above.

2nd Choice:
Bypass Parameter Method, IF the indication that a parameter is bypassed is different from a parameter being disabled. If a parameter is bypassed you don't know whether to unbypass it or look for some toggle somewhere to turn it on. (Parameter background turns yellow like the bypass flag in SOPs?)

3rd Choice:
Current Setup

4th Choice:
Other alternatives.

Wolfwood
1st Choice :
I vote for better tools for saving Spare Parameter profiles like I mentioned above.

We do have ideas for improving work-flow with spare parameters (rendering parameters). Some of the technology came online too late in the development cycle to be fully implemented.

The other thing that I didn't mention is that we also have to plan for future improvements in work-flow. Bogging down the interface with additional parameters isn't conducive for some of the future plans.

mark

Wolfwood
1st Choice :
I vote for better tools for saving Spare Parameter profiles like I mentioned above.

We do have ideas for improving work-flow with spare parameters (rendering parameters). Some of the technology came online too late in the development cycle to be fully implemented.

The other thing that I didn't mention is that we also have to plan for future improvements in work-flow. Bogging down the interface with additional parameters isn't conducive for some of the future plans.

great new, rendering parameters proficles will be great to save time.
And yes I think that the new properties needs a little more adjustment and ui design, they are very very powerful for complex setups but for a fast scene setup could be a pain so I think hat somethig like profiles, presets, some fast enable/disable specific properties directly in the objects will be great.
Specially a point I want to focus is when these properties directly collide with the day by day use of the tool, like I think is the case for the view properties in the camera and for the light mask in the objects.

Am I missing something? From what I can see, all geometry objects have a light mask parameter.

Just to clarify, motion blur was, for me, just an example as far as parameter configuration goes. I don't particularly want moblur re-implemented to be like H8(inherit, etc.) nor do I want to overload objects with more than they typically need. That would just be one issue, and you still need to deal with all the other parameters. While somewhat more verbose, I like the power of the new sampling mblur implementation.

Presets are fine. Really, though, the whole notion of editing the parameter interface needs a meta-layer on top of it IMHO. What's there now is fine, I wouldn't want to see it go away. But to continue the mblur example, if I'm an end user and I set mblur in my ROP, then let's say I realize I want a given object to blur differently than the others. I don't want to look at a ROP and tediously hunt and find all the params that relate to mblur to copy them - I want to right click over the params of my object and select Add Parameter Sets, and see, amongst numerous other entries, Motion Blur Control(in a nested menu, no less!). Select, it's done - all five mblur params show up. I could do the same for all sorts of meta-groups. Yes, if presets get implemented, I could write my own, but I really think this sort of thing needs to be provided by SESI. And while you're at it, make it trivial to remove them too - not require having to call up a monstrous floating dialog window, but something as simply as metakey, select, drag off the pane. That way you could very quickly add an oversized set of params very fast, pull out the ones quickly that you don't need, and there was no hunting or searching at all.

Really, that's my big problem with the way it is now. Far too time consuming to manage. I'd like to *keep* the editor that's there - it's still tremendously useful - but I'm hoping for next iteration the whole process gets streamlined. The reason you've got user's being confused by it is because it requires a significant understanding of everything that's going on in order to add(what seems to a beginner) like such a simple thing.

Cheers,

J.C.

JColdrick
Presets are fine. Really, though, the whole notion of editing the parameter interface needs a meta-layer on top of it IMHO. What's there now is fine, I wouldn't want to see it go away. But to continue the mblur example, if I'm an end user and I set mblur in my ROP, then let's say I realize I want a given object to blur differently than the others. I don't want to look at a ROP and tediously hunt and find all the params that relate to mblur to copy them - I want to right click over the params of my object and select Add Parameter Sets, and see, amongst numerous other entries, Motion Blur Control(in a nested menu, no less!). Select, it's done - all five mblur params show up. I could do the same for all sorts of meta-groups. Yes, if presets get implemented, I could write my own, but I really think this sort of thing needs to be provided by SESI. And while you're at it, make it trivial to remove them too - not require having to call up a monstrous floating dialog window, but something as simply as metakey, select, drag off the pane. That way you could very quickly add an oversized set of params very fast, pull out the ones quickly that you don't need, and there was no hunting or searching at all.

Really, that's my big problem with the way it is now. Far too time consuming to manage. I'd like to *keep* the editor that's there - it's still tremendously useful - but I'm hoping for next iteration the whole process gets streamlined. The reason you've got user's being confused by it is because it requires a significant understanding of everything that's going on in order to add(what seems to a beginner) like such a simple thing.

Cheers,

J.C.

Complitely agree with you John!