Jump to content
McNistor

Object visibility

Recommended Posts

Hey crowd,

 

I'm used to the way Softimage deals with object visibility which I think is versatile as it has separate params for viewport-vis, render-vis and selectability.

In houdini the first two seem to be merged into one -blue tag and the selectability as the green one.

 

Problem is, I often work on something (modeling for example) and have other objects invisible in the viewport but visible at render-time, useful for checking things out.

 

How would someone adapt this workflow to Houdini?

Share this post


Link to post
Share on other sites

You can unlink the render and visibility flag I think

I think its control or alt click on the blue (most right) flag of a node.

Im not sure of the hotkey, but I know it is possible, I think you can also unlink them by default in your preferences

Edited by acey195

Share this post


Link to post
Share on other sites

It seems that the ctrl/alt option is available only at SOP level. But it seems it doesn't work or at least I can't make work.

My test scene is: a sphere.

Share this post


Link to post
Share on other sites

Ah, another node is needed, a null or something.

Well this is far from optimal.

I'll submit a RFE.

 

Thanks, acey195.

Edited by McNistor

Share this post


Link to post
Share on other sites

If SOP's level Display/Render flag unlinking doesn't fit your workflow you can hide object from viweport (but keep them renderable) by going into Render Tab and set Display As to "Hidden".

 

Also there is force visibility at mantra rop.

Share this post


Link to post
Share on other sites

Yeah, thanks, but In complex models you'll have more than one geometry in an OBJ. I think a better separation for objects vibility at both OBJ and SOP level is worth having.

 

As a side note the visibility matter in Houdini seems to follow the same pattern of poor organization. For example, why is a viewport display option under the render tab?

Would be simpler to have a visility tab and there: viewport visibility, render visibility. ON/OFF and 'display as' for each, independetly, problem solved, no confusion, no scratching to the right ear with the left hand.

Edited by McNistor

Share this post


Link to post
Share on other sites

It doesn't have to be all over the place. Many other options in Houdini are scattered around and the prefs is overdue a reordering on logical and intuitive categories.

 

Have all transformation related things on a "transforms" section. All selection options in a "selection" section and so on.

 

Being used to something doesn't mean it's OK as it is and in fact it takes an outside mind to spot these things which to a seasoned user have become 2nd nature. Having things better organized isn't beneficial just to the newcomers.

post-11913-0-53596700-1433850850_thumb.j

Share this post


Link to post
Share on other sites

Why are the separate flags for viewing and rendering on SOP level a problem? The viewport still obeys the display flag from inside and being able to set a render flag to anything makes it flexible.

I guess this is more applicable in cases where you want to use a proxy for high detailed geometry but the logic is very clear. You want to render nothing? Set a flag on a node containing nothing.

For rendering I often use the "force objects" field on the mantra node to put my final OBJ nodes in. Inside these nodes I still use the separate render flag but at least you know random nodes you put down won't be rendered.

 

Also technically rendering can mean a whole lot of things, including  creating a final image of your scene with lighting and shaders etc but also drawing objects in your viewport.

Edited by Robert

Share this post


Link to post
Share on other sites

I don't think you understood what I'm saying. Or I don't understand what you're saying.

Separate flags for viewing and rendering is not a problem, in fact, the limited and unorganized way they're implemented is a problem.

Share this post


Link to post
Share on other sites

Again, what I'm after, is separate render/viewport params for both OBJ and SOP lvls. Also,

 

here is a bulleted list with problems I'm having:

-selectability is under "misc" ("misc" being IMO a clear evidence that at the time, some params seemed to not fit in any category which is of course not true) and "viewport visibility" is under Render tab.

-where in the param. view at OBJ level is the node blue tag's param?

-in SOPs you need to have a null or another obj to which you need to "transfer" the rendering visibility (instead of being a toggle) - this has to be rethinked (i.e. make it a toggle).

 

The current way Houdini deals with this matter is a mess IMO. Like someone else said (don't remember who): Houdini's unnecessarily complicated.

Edited by McNistor

Share this post


Link to post
Share on other sites

I don't think its mess at all. Maybe not so visually nice as it's inisde SOPs but it's fully functional. Try to read help files, Softimage2Houdini guide and learn basics of Houdini workflow first, please.

 

Display flag at Object level is quick toggle to set both render and viewport visibility on/off.

 

For rendering you usually define your object's render visibility at mantra rop via Force Objects parameter (so it's independent of the display visibility).

(For same reason there are partitions in XSI where you can force visiblity on/off too).

 

SOPs Display/Render flag is for low res proxy/debug purposes mainly.

 

On the Render tab there are both Viewport and Render visibility options as it should be (as object is rendered in viewport or in mantra, arnold etc.. There are also other options that are tight to rendering on this tab (and it's subtabs).

 

Having separate Visiblity tab would lead to slower workflow as it would require switching between tabs and as mentioned earlier render visiblity is usally set on rop node itself. (For me it makes more sense to named it Render tab (as there are Shading, Sampling etc.. parameters))

 

There is Display parameter (on Render tab) where you can animate Viewport Visibility.

Only issue I see there is that this parameter is not linked to object's blue Display Flag same way as Viewport Selecting Enabled is linked to green selection flag (RFE (ID# 69257))

 

 

But having violet flag for renderable would be nice too (If you like it: RFE (ID# 69258), see attached image for explanation)

 

 

 

Cheers

post-5365-0-96698500-1433857707_thumb.pn

Edited by pezetko
  • Like 1

Share this post


Link to post
Share on other sites

Stop ruining my rants! :)

 

Well of course you don't think it's a mess. You are accustomed to it and have embraced it, but what you're telling me now is that having these options scattered around various tabs is better than having a single visibility tab where you deal with viewport/render visibility, display mode and selectability in one place.

 

Display flag at Object level is quick toggle to set both render and viewport visibility on/off.

 

 

Yes I know, cool. Now let's make that flag "point" to a visibility tab's two params: viewport and render which will be checked/uncheckd along with the blue thingy.

Do you agree this would be an improvement? Up next...

 

The purple flag (activate with ctrl or alt or whatever) points to render in the Visibility tab.

Teal (or other) points to viewport in the Visibility Tab.

 

Have the option to activate these (at the node flag) with ctrl/alt like at SOP level.

 

For SOPs, the same: color coding pointing to params. in a centralized Visibility tab. This means toggles, not switching the value (true or false) from one SOP to another.

 

Pretty sure this is better organized and more intuitive than the current way.

 

Having separate Visiblity tab would lead to slower workflow as it would require switching between tabs

 

I too support a single tab for visibility (where did I say that I don't?) and to that, add display and selectable options too.

 

p.s. It's cute how you mention the partitions in XSI but somehow fail to mention XSI visibility parameters per object and how clear and simple they are :)

Also, I have learned the basics of Houdini so please stick to the arguments presented, don't appeal to the argument of a superior know-how.

You should not be so quick to dismiss a beginner's experience and impressions. By the time I'll become an expert in Houdini I will probably also think it's great as it is and don't you know, thinking it doesn't make it so.

Edited by McNistor

Share this post


Link to post
Share on other sites

Now let's make that flag "point" to a visibility tab's two params: viewport and render which will be checked/uncheckd along with the blue thingy.

Do you agree this would be an improvement? Up next...

 

Maybe I'm missing something but it is on single tab already. Viewport Visibility parameter is called "Display" and Render visibility parameter is called "Renderable". (There are toggle and integer value parameters for Display what could be confusing, I think it's something from past...).

 

You can move Viewport Selecting Enabled parameter from Misc tab to Render tab in Edit Parameter Interface if you wish.

(But for me it doesn't have sense to have Selecting on Render tab the way like it's in XSI)

 

 

The purple flag (activate with ctrl or alt or whatever) points to render in the Visibility tab.

Teal (or other) points to viewport in the Visibility Tab.

I would keep same color coding as it's now inside sops (that one I ilustrated in image attached to my previous post).

 

 

Have the option to activate these (at the node flag) with ctrl/alt like at SOP level.

That's good point! RFE it  ;)

 

 

 

For SOPs, the same: color coding pointing to params. in a centralized Visibility tab. This means toggles, not switching the value (true or false) from one SOP to another.

I don't get this one.  Tab centralized to what? There is already color coding for display/render flag.

 

Try to look at Output SOP. Is it what are you after?

 

What's difference between Toggle and True/False or On/Off switch?

 

If you want to render different branches of the tree at once just merge them together with Merge SOP.

 

Inside SOPs it's very roughly something like Operator Stack in Softimage. You get only one result (that is node with render flag turned on (or Output SOP in H14)). But you can visualise some other node (for debug, for speed (lowres proxy)) with visibility flag. So you can see fast proxy mesh in viewport and render hires model during render.

If you want to hide part of the model (e.g. some polygon groups similar way like you could hide cluster or polygons in Softimage) you can use Visibility SOP.

Edited by pezetko

Share this post


Link to post
Share on other sites
Maybe I'm missing something but it is on single tab already. Viewport Visibility parameter is called "Display" and Render visibility parameter is called "Renderable". (There are toggle and integer value parameters for Display what could be confusing, I think it's something from past...).

I have edited my previous post while you were wrting this one probably.

I'm saying that we need visibility (viewport/render-time), display (as a b-box, wireframe, etc), selectable in one tab. Get rid of "Misc"

Now looking back at our discussion I can see that some confusion might arise from what seasoned H users call "display" and what S users understand by that. As you probably know, display in XSI is a property that deals with how is an object shown in the viewport, while viewport visibility (is a toggle) is separate from that. In H all seem to be togehter in the same drop-down list. That's fine, it's not as well organized, but I can live with it, no biggie.

 

 

I would keep same color coding as it's now inside sops (that one I ilustrated in image attached to my previous post).

Color coding should be consistent, that's all I care about, so yeah... whatever feels nice.

 

That's good point! RFE it

This whole thread is part of a RFE :)

 

 

I don't get this one.  Tab centralized to what? There is already color coding for display/render flag.

I think we clarified this one. If not, let me know.

 

What's difference between Toggle and True/False or On/Off switch?

None. Poor explanation from my part apparently.

What I say is this: right now, if you have a single SOP inside an OBJ you can't make it unrenderable by ctrl LMB on its flag, you have to click another node or create a null if you don't need/have another.

You have to have at least two SOPs (two boxes for example) and moreover, if you indeed have say three, you can't make two of them renderable and one not, unless ofcourse you merge the two, but maybe I don't want them merged.

ANyway basically have a better viewport/render control at SOP lvl - exposed vis. params. Is it clearer now?

 

edit: I can see how evaluating data trees with multiple render tags ON could be a problem and as of now I can't know if there's a big no-no reason for which it was chosen this approach (one single render flag inside at SOP lvl), but maybe it's possible, only the Houdini guru's and the devs. can know.

Edited by McNistor

Share this post


Link to post
Share on other sites

Why do not you just use Visibility SOP? Or I did not understood what you need :D

Share this post


Link to post
Share on other sites
This whole thread is part of a RFE :)

If it's not submited to SESI there is a little to none chance that it will be ever implemented. (Ctrl/Alt + Click shortcuts to define viewport/render visible flags at object level)

 

 

 

What I say is this: right now, if you have a single SOP inside an OBJ you can't make it unrenderable by ctrl LMB on its flag, you have to click another node or create a null if you don't need/have another.

You have to have at least two SOPs (two boxes for example) and moreover, if you indeed have say three, you can't make two of them renderable and one not, unless ofcourse you merge the two, but maybe I don't want them merged.

ANyway basically have a better viewport/render control at SOP lvl - exposed vis. params. Is it clearer now?

 

edit: I can see how evaluating data trees with multiple render tags ON could be a problem and as of now I can't know if there's a big no-no reason for which it was chosen this approach (one single render flag inside at SOP lvl), but maybe it's possible, only the Houdini guru's and the devs. can know.

 

If you have single sop inside object (e.g. file sop) you can define which part of it will be rendered with Render Group property on the object. If you set it to non-existing group it will render nothing.

Limitation (afaik) is that you can specify single group only in this property. See attached example file.

render_groups.hipnc

 

That way you can render different parts of the mesh with single object and multiple takes (in those take you will override rendergroup parameter).

(But there is still single render node) - It's like result of the operator stack in Softimage.

 

 

 

I think that for rendering you confuse Object and SOP contexts .

Don't be confused that Object/Sop level looks similar. It's different thing.

Object level could be described as things, items. Sop level could be described as process how this things/items are made/created.

 

At object level:

You can have/see or don't soccer ball (object visibility) but you usually don't care how it was made.

 

At SOP level:

You can watch all day long how raw material is picked at warehouse (Display flag in SOP context) but result will be always soccer ball (Render Flag (or Output SOP inside subnets)).

 

 

If you work with your SOP content like with it's your factory that produces soccer balls, shoes and hats at once you can object merge each of them (result or work in progress) to new objects (with help of Object Merge SOP) and render them separately - Object Display/Renderable parameter (property).

 

So you have one object that represents factory and three other objects that represents items created in this factory.

 

 

 

btw: Visibility SOP is only for viewport visibility.

Share this post


Link to post
Share on other sites

Alright, that makes sense, thanks.

 

As a side note, op.stacks in Soft are on "geometry objects" (might be confusing to "purebred" Houdini users) only, but OBJ in H is a different breed of animal. I understand that you've made just an analogy, but being just that, I was thinking (and still am) whether there's a technical limitation (or basically any other good reason) for why one can't have multiple render tags on renderable geometry nodes (poly-meshes, surfaces) at SOP level.

Share this post


Link to post
Share on other sites

I would prefer having single Display/Render flag just for reason that this way it's very clear where the final output is (because it's always only one that you need to find/track).

 

 

Look at this example for "having multiple render/display flag outputs" - it's workaround but you can specify which nodes gonna render and which gonna be displayed just by toggles.

 

Hope it helps.

pz_object_merge_workflow.hipnc

Share this post


Link to post
Share on other sites

It does helpo, thanks a bunch.

 

As a probably uninteresting note, we (XSI users) hate workarounds. There was a joke circulating on the list that sounded like this: in Soft you work, in Maya you work around :)

Share this post


Link to post
Share on other sites

I'm struggling with something similar. What I want to do is have a checkbox on a OBJECT MERGE or other object based node that I can keyframe so that things are not 'seen' by the camera until they are needed.

For example, right now, I have an animation INSIDE a geometry SOP where I have 3 pieces of geometry I'm bringing in using 3 different OBJECT MERGE SOPs. I have 3 transforms, etc.

One of the items will animate in, and when it stops, the other two items will animate from behind that object. Only I don't want them visible (renderable) until the main object which is animating in is blocking them from view of the camera.

I have this option in Cinema 4D. I guess I could keyframe it into place from off screen, but then that seems more complicated.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×