No. For viewport interaction purposes, one shouldn't have to mess with objects visibility.
In Softimage for example (Max too, but last time I checked it was rather restrictive and… wonky) one selectes a few objects in the viewport, presses a hotkey and you have them isolated. This operation doesn't change any params in the objects visibility properties, it's a purely viewport “thing”.
Likewise, in Houdini this operation should work at viewport level to avoid creating additional nodes.
Can you think of the numbers of nodes created for the amount of isolation commands in a modeling (or rigging) session one does? It would result in a delete Visibility SOPs hunt or revisiting them to unhide - am messy job.
Full Version: Houdini 15 Wishlist
Hey MacNistor, you've been using Houdini more than me so you should have noticed in the top right of the 3d viewport there is a button, the second from the right, with 3 options , and one of them is “hide other objects”.
I'm often using this option when modelling but I have noticed it's a bit buggy… Sometimes, when I select some object, other objects should disappear, but they stay visible…
Is this also the reason you're not satisfied with this button?
I'm often using this option when modelling but I have noticed it's a bit buggy… Sometimes, when I select some object, other objects should disappear, but they stay visible…
Is this also the reason you're not satisfied with this button?
just a little Render button (with choosing camera) on Mplay toolbar.
please
please
@grendizer that controls how other scene objects are displayed when at SOP level of a selected object, it doesn't have a say when staying at object level
Yeah but how would Houdini know what to hide than? Selected or what?
@SreckoM
Ideally it would show just the selection or group or whatever…
this is handy when modeling - you can see the whole model then narrow the view to just the bit you're working on.
Ideally it would show just the selection or group or whatever…
this is handy when modeling - you can see the whole model then narrow the view to just the bit you're working on.
RFE: 3d comparison tool for anything that's shown in the scene view
Imagine having memory buttons or something along those lines that will record the current geometry that's visible in the current container. So will have to work in SOPs, DOPs, etc.
Let's say you have some particles, and then you play it and go to frame 10, then you press a button/hotkey to save this to a memory slot. Then you change some parameters and then load the previously saved particles.
When you do this, it won't affect the latest result, it will only read from memory what's saved. So you could have a slice style comparison or a full toggle to toggle back and forth between 2 results to see the change.
You can support animation for the currently cached played back range.
You can have all kinds of visualizations to show you what's changed and how much, etc.
Not only that it will also save all the scene values and if you want you can restore these parameters.
Available actions would be:
Go to Main/Global state
Add new state
Save to state N
Load to state N (and via a dropdown menu in the viewport)
Restore state N (which would ask for confirmation)
It seems like Takes, but Takes don't allow immediate comparisons, auto caching which is the main goal of this tool. Restoring values is secondary.
Imagine having memory buttons or something along those lines that will record the current geometry that's visible in the current container. So will have to work in SOPs, DOPs, etc.
Let's say you have some particles, and then you play it and go to frame 10, then you press a button/hotkey to save this to a memory slot. Then you change some parameters and then load the previously saved particles.
When you do this, it won't affect the latest result, it will only read from memory what's saved. So you could have a slice style comparison or a full toggle to toggle back and forth between 2 results to see the change.
You can support animation for the currently cached played back range.
You can have all kinds of visualizations to show you what's changed and how much, etc.
Not only that it will also save all the scene values and if you want you can restore these parameters.
Available actions would be:
Go to Main/Global state
Add new state
Save to state N
Load to state N (and via a dropdown menu in the viewport)
Restore state N (which would ask for confirmation)
It seems like Takes, but Takes don't allow immediate comparisons, auto caching which is the main goal of this tool. Restoring values is secondary.
DOF and Motion Blur for the OpenGL render.
RFE: Attribute creation SOPs should show the name of the attribute created under the node tile (Descriptive Parm)
Attributes are one of the fundamental aspect of Houdini and is used all the time throughout the app. Showing these attribute names in the network editor would speed up the workflow tremendously and is not a time consuming change for SESI, where this feature is already implemented, just under used.
For SOPs that create/modify/rename attributes with a new name than the original attribute, you could use this format:
v -> oldvel
Attributes are one of the fundamental aspect of Houdini and is used all the time throughout the app. Showing these attribute names in the network editor would speed up the workflow tremendously and is not a time consuming change for SESI, where this feature is already implemented, just under used.
For SOPs that create/modify/rename attributes with a new name than the original attribute, you could use this format:
v -> oldvel
-Edit Atrributes SOP : Editing attributes in a non-procedurally way like the current editSOP but for attributes.No neeed to always paint to make changes
-Speed up the Python OBJ node
-A more visual solution to see the dependency between nodes.
-Speed up the Python OBJ node
-A more visual solution to see the dependency between nodes.
pusat
RFE: Attribute creation SOPs should show the name of the attribute created under the node tile (Descriptive Parm)
What's the problem with making extended HDA from them with this option added?
mantragorapusat
RFE: Attribute creation SOPs should show the name of the attribute created under the node tile (Descriptive Parm)
What's the problem with making extended HDA from them with this option added?
You can do that but it's gonna create dependency issues in the scenes you use those OTLs where some people can argue it wasn't justified, for little gain. Field creation DOPs already support this feature so this should be done by SESI.
If the Descriptive Parm could be modified as default preset/permanent defaults, then this would work. I do this for better defaults for certain SOPs. But these are pretty portable and doesn't require new OTLs.
Just my opinion.
On the topic of better defaults:
RFE: Better defaults for built-in OPs
I have quite a few saved as permanent defaults, one of which is the Sweep SOP that looks like this:
It's not a new HDA. It's done entirely by using spare parameters and expressions. Works really well and very portable. Would be a nice addition to H15. I attached the defaults if you wanna use it.
Others look like this:
Back to object isolation. Yes this is the problem I felt as well McNistor: in object level the “hide other object” display mode doesn't work.
Sekrom, please check this video where is demonstrated XSI's much used Object View, starting at 00:45 : https://www.youtube.com/watch?v=_k7nwJ8tNY8 [youtube.com]
Sekrom, please check this video where is demonstrated XSI's much used Object View, starting at 00:45 : https://www.youtube.com/watch?v=_k7nwJ8tNY8 [youtube.com]
-Presets in a human readeable format (ascii, xml , json …)
grendizer
Back to object isolation. Yes this is the problem I felt as well McNistor: in object level the “hide other object” display mode doesn't work.
Sekrom, please check this video where is demonstrated XSI's much used Object View, starting at 00:45 : https://www.youtube.com/watch?v=_k7nwJ8tNY8 [youtube.com]
I was using and still use few 3D apps including XSI, and I exactly know what are you talking about. Isolate in XSI is exactly what you have already in Houdini, it is on object level. Also you can hide not just on object level, but also in Edit/Component mode and that is what is required here.
I am not saying this is not good to have, I was just asking how this will be implemented into Houdini way of work.
I usually walk through nodes and if do not remember where I hit Isolate …. that is why I like Visibility, exactly know where it is hidden.
I guess this is because most of users are working entirely in one SOP. Like this character, one would import/create into one SOP and work like that. So what you have in Houdini already, will not work as you need. If this is done in XSI, Isolate would not work there, correct?
grendizer +1 for Visibility SOP. I have simple script that create visibility SOP based on selection.
1. First script call -> add Visibility SOP
2. Second call -> replace it
Have no problem with isolation when I'm modelling in SOP context
1. First script call -> add Visibility SOP
2. Second call -> replace it
Have no problem with isolation when I'm modelling in SOP context
1. Easy visibility control for parameter handles in 3D viewport at the UI level.
When you set up the UI for your HDA you should be able to add control buttons that will turn off visibility for specified handles in the 3D viewport or whole groups of handles. Handles should also be automatically grouped with the parameters they control.
2. Easy adding of parameter handles in 3D viewport via UI creation menu.
I am aware that you can create 3D viewport handles in a separate area of HDA UI, but I think that misses the point. Handles drive parameters. So they should be part of their parameters. If you have to create 40+ handles -been there, done that- in the current system you completely loose any kind of overview. Of course you still might have naming to distinguish the handles, but really it gets impossible to find anything because you barely have any (visual) separation. Also controlling the visibility of 3D viewport handles is currently unnecessarily complicated and seems broken and unresponsive and uninteractive.
New workflow example: Let's say you have a plane and you want to give a user control over the positions of the corner-points of that plane in the 3D viewport.
- You make 4 “float vector 3” parameters
- While still in UI creation mode, you select them all and right-click on the parameters -> 3D viewport handle creation -> transform arrows
OR
While still in UI creation mode, you go to the (new) “3D handle tab” in each parameter and click the plus symbol -> transform arrows
- Apply changes. Now in the 3D viewport you see transform arrows at the points specified by the parameters.
- In each parameter in the (new) “3D handle tab” you now have an additional sub-tab for each of the parameter's handles. Here you can change the script that drives each handle's, position, rotation, scale, visibility etc. There is also an option (checkbox) next to the visibility that says “deactivate when parameter invisible”
and another that says “deactivate when parameter inactive”. Activate the second option and if the parameter is minimized in the UI or the user is in another tab of the UI, the corresponding handles disappear.
———–
On a somewhat related note: I think the Channel tab options should be fused into the Parameter tab. It's good practice to always specify defaults.
When you set up the UI for your HDA you should be able to add control buttons that will turn off visibility for specified handles in the 3D viewport or whole groups of handles. Handles should also be automatically grouped with the parameters they control.
2. Easy adding of parameter handles in 3D viewport via UI creation menu.
I am aware that you can create 3D viewport handles in a separate area of HDA UI, but I think that misses the point. Handles drive parameters. So they should be part of their parameters. If you have to create 40+ handles -been there, done that- in the current system you completely loose any kind of overview. Of course you still might have naming to distinguish the handles, but really it gets impossible to find anything because you barely have any (visual) separation. Also controlling the visibility of 3D viewport handles is currently unnecessarily complicated and seems broken and unresponsive and uninteractive.
New workflow example: Let's say you have a plane and you want to give a user control over the positions of the corner-points of that plane in the 3D viewport.
- You make 4 “float vector 3” parameters
- While still in UI creation mode, you select them all and right-click on the parameters -> 3D viewport handle creation -> transform arrows
OR
While still in UI creation mode, you go to the (new) “3D handle tab” in each parameter and click the plus symbol -> transform arrows
- Apply changes. Now in the 3D viewport you see transform arrows at the points specified by the parameters.
- In each parameter in the (new) “3D handle tab” you now have an additional sub-tab for each of the parameter's handles. Here you can change the script that drives each handle's, position, rotation, scale, visibility etc. There is also an option (checkbox) next to the visibility that says “deactivate when parameter invisible”
and another that says “deactivate when parameter inactive”. Activate the second option and if the parameter is minimized in the UI or the user is in another tab of the UI, the corresponding handles disappear.
———–
On a somewhat related note: I think the Channel tab options should be fused into the Parameter tab. It's good practice to always specify defaults.
grendizer
Back to object isolation. Yes this is the problem I felt as well McNistor: in object level the “hide other object” display mode doesn't work.
Sekrom, please check this video where is demonstrated XSI's much used Object View, starting at 00:45 : https://www.youtube.com/watch?v=_k7nwJ8tNY8 [youtube.com]
The viewport has two ways to do this:
- The Visible Objects field in the display options, Optimization tab. This probably needs an easy workflow to set it (selection > visible only field, clear visible only field)
- The Data Tree, Object Appearance mode, “Display Type” can also hide objects, but also make them bounding boxes, point clouds, etc. It's more of an advanced workflow, I'd think.
1. Add an expression to randomize values based on a ramp
randramp(value, ramp_path)
Values become more or less likely depending on the shape of the ramp. (The “value” is the seed.)
- There are various workarounds to get this effect, but the simple fact that there are multiple workarounds means that this is something people really would like to be able to do. And workarounds seem rather inefficient and clumsy.
2. Add a convenient expression to randomize between two extremes:
rand01(value, newmin, newmax)
which is exactly the same as:
fit01(rand(value), newmin, newmax)
- I know it is possible to do this myself, but it seems such an easy thing to add and such a convenient thing to have. So why not?
randramp(value, ramp_path)
Values become more or less likely depending on the shape of the ramp. (The “value” is the seed.)
- There are various workarounds to get this effect, but the simple fact that there are multiple workarounds means that this is something people really would like to be able to do. And workarounds seem rather inefficient and clumsy.
2. Add a convenient expression to randomize between two extremes:
rand01(value, newmin, newmax)
which is exactly the same as:
fit01(rand(value), newmin, newmax)
- I know it is possible to do this myself, but it seems such an easy thing to add and such a convenient thing to have. So why not?
jason_iversen
What Houdini really is missing that other packages have are easy material properties like:
- Visible In Camera Rays
- Visible In Reflection Rays
- Visible In Refraction Rays
- Visible In Shadow Rays
+1 For this. Got my hands dirty in H rendering lately and although Mantra and shading in Houdini are extremely versatile, a little work on the easiness of use is needed.