abvfx Posted March 19, 2014 Share Posted March 19, 2014 If an uber modelling node came out i would be all over that in a heartbeat. But something like that requires more than tooling. Manipulators and general interaction needs fixing/tweaking. Having pre-selection highlighting is nice but you need it to be able to select components from a distance, not with the cursor is over the element. Middle mouse button need more functionality. I like using "ladder" but if i could tweak elements (just translating) with the middle mouse button (with pre-selection highlighting) it would allow for a lot of saved clicks. Same goes when using the Channel Listing. Using ladders in those arent very fast because you MMB > Move upto the increment you want > then horizontal to add your value. Also you have to make sure you know your original value as the value displayed is added not the final result. It would be great to be able to click drag as many parameters you want in the List, MMB and drag horizontal to adjust your values. Quote Link to comment Share on other sites More sharing options...
kev2 Posted March 19, 2014 Share Posted March 19, 2014 If an uber modelling node came out i would be all over that in a heartbeat. But something like that requires more than tooling. Manipulators and general interaction needs fixing/tweaking. Having pre-selection highlighting is nice but you need it to be able to select components from a distance, not with the cursor is over the element. Middle mouse button need more functionality. I like using "ladder" but if i could tweak elements (just translating) with the middle mouse button (with pre-selection highlighting) it would allow for a lot of saved clicks. Same goes when using the Channel Listing. Using ladders in those arent very fast because you MMB > Move upto the increment you want > then horizontal to add your value. Also you have to make sure you know your original value as the value displayed is added not the final result. It would be great to be able to click drag as many parameters you want in the List, MMB and drag horizontal to adjust your values. I find the ladder a pain with a pen. I like Nuke's arrow up/down to iterate through parameters. Very fast, easy to tweak long floating point values. I also wish they would steal Nuke's node connectors. SESI's node connectors just feel comparatively clumsy. 2 Quote Link to comment Share on other sites More sharing options...
kev2 Posted March 19, 2014 Share Posted March 19, 2014 Also now with VEX expression being heavily in the mix, in order to use Houdini at a mid level user, you need to know HScript, expression, VEX Expression, VEX, Python, and god forbid you dive into HDK just to use their software on a daily basis...Sorry for the series of rants today. I'm having to touch all the fun problems today. Houdini is like hosting a large dinner party where you have to get each fork and spoon, glass of bubbly, table cloth, candle and water from a different room, while the room is being remodeled, then take it all to the kithen for prepation before serving in the Mantra dining hall with a caterer, waiters and bartenders who all speak different languages and guests who take forever to get seated. It makes for a difficult UX on a lot of levels. For example, I like having the VEX snippets and the wrangle nodes but why not just one superWrangle, smart enough to know what's connected and which context it's in (not that I in any way want to keep the confusing OPs contexts, I'm all for a unified node tree/network) but do we really need an attributewrangle and a pointwrangle? If you are going to use snippets, why not have them on the node itself? Why make me go to the parameter pane at all? As far as I'm concerned a node network could just be collapsed parameter panes. Somewhere in the deep dark of SESI there must be some fun whiteboards on these things. Quote Link to comment Share on other sites More sharing options...
Guest tar Posted March 19, 2014 Share Posted March 19, 2014 Would hope so... and I am really behind it, but as far as the rant and this should no way detract from the creation of this specific modeling tool... is that SideFX will only create more nodes to solve their solution. And if you've seen the pipeline of a large scale studio that has been around for years, you can see the tool bloat associated with it. Sometimes in the magnitude of a thousands otls. Which SideFX instead of maintaining their library of internal nodes are leaving these tools in their package as of now nearly 1500+ nodes. So I hope they create that tool, but they need to do a separate house cleaning of their old nodes and re-evaluate their usefulness and the extreme piecemeal nature they now represent. Aren't all large scale studio solutions 'bloated' for each software that has been in the pipeline for years? Quote Link to comment Share on other sites More sharing options...
magneto Posted March 19, 2014 Share Posted March 19, 2014 Bringing dops to the sop level... I'm a fan of using one context and not needing to dive in and out of multiple contexts. I appreciate the need for organization, but that's a poor sole excuse. As far as dops is many third party dynamic build there dynamics structure into sops. Many big companies(Sony is one of the top of my head, and there is another person to do that there is a thread on here about) have built there bullet solvers at the sop level with great success. What are the advantages of having bullet or other dynamics in SOPs? I am asking because I don't know but do we really need an attributewrangle and a pointwrangle? They are using different VEX contexts so they can't get rid of PointWrangle until AttribWrangle catches up. Node consolidation would be nice though Quote Link to comment Share on other sites More sharing options...
Alexey Vanzhula Posted March 19, 2014 Share Posted March 19, 2014 (edited) What are the advantages of having bullet or other dynamics in SOPs? Working in one context to modify geometry, like animation with expressions, VEX, etc in SOP context. Just modify geometry shape with time in one place (all nodes on a look). For this purpose it isn't obligatory to move dynamic operations to separate container, especially for not very large sims. Edited March 19, 2014 by Alexey Vanzhula 1 Quote Link to comment Share on other sites More sharing options...
altbighead Posted March 19, 2014 Share Posted March 19, 2014 improved brush tool for model sclupting,hair sculpting and painting) (I am still on Houdini 12.1 so not sure it has improved) 1 Quote Link to comment Share on other sites More sharing options...
LaidlawFX Posted March 20, 2014 Author Share Posted March 20, 2014 Aren't all large scale studio solutions 'bloated' for each software that has been in the pipeline for years? It's not really the studio that is the issue or how it got there. It's been around for years, changed were made for many good reasons, but years later a clean sweep needs to be made to curtail that bloat. Houdini itself reflect this issue, just the nature of something that's been around for a while. Sometimes this is just hiding redundant features until a few years laters like pops can be done away with. A.k.a prism stuff should no longer be backwards compatible in Houdini if there even is anymore, and be cut out of the program. It's certainly always easier to rebuild from scratch with that in mind like Modo. But it can't be ignored just because it's been around then you turn into Maya, or Houdini. In the end it doesn't really matter how the bloat got there, it's more of the fact who in their right mind has the capacity to know what all 1500+ nodes do within Houdini. If it's curtailed down to a few hundred bigger nodes, it be more easier to manage and work with them. Here are some nodes that could be merged into a single node. Also pretty much any node that literally does a single code line... You can always leave the code more modular at the developer level, but it the user nodal level that needs to be shifted. Duplicate Nodes: Sop 1. Copy, Duplicate 2. PolyExtrude, Extrude, 3. Connecitvity, Partition, Assemble 5. Point, Vertex, Primitive 6. Facet, Vertex 7. Volume Mix, Volume Merge Vops 1. a. Multiply, Multiply Constant, Multiply Add Constant, b. Divide, Divide Constant c. Add, Add Constant d. Subtract, Subtract Constant 2. Since, Cosine, Tangent, 3. Color Mix, Mix 4. Average, Minimum, Maximum 5. Global Properties, Import Attribute, Parameter, Get Attribute 2 Quote Link to comment Share on other sites More sharing options...
Guest tar Posted March 20, 2014 Share Posted March 20, 2014 That's a fair call, could be time to clean the house, prune the tree etc. Quote Link to comment Share on other sites More sharing options...
sebkaine Posted March 20, 2014 Share Posted March 20, 2014 (edited) i don't want to start a civil war But i'm wondering if people really need predifined context ? i find flexible to have only one root / directory then you can arrange your context the way you want with subcontext. I never use SHOP/PART/IMG/CH/VEX context i prefer to put all my stuff in /OBJ then i use subcontext the way i want. Thus i don't have to switch panel each time i want to access my SHOP or ROP. Erasing this and only starting with root / at houdini start , is quite a radical move , and i guess 50% at min will not agree with this. - But one root / then build and organise your subcontext the way you want + - a consolidated node network like nuke with ability to put dot on connection and avoid to build a nice spiderman web when things get bigger Would be cool ... Edited March 20, 2014 by sebkaine 1 Quote Link to comment Share on other sites More sharing options...
abvfx Posted March 20, 2014 Share Posted March 20, 2014 I can understand your thinking but it is something that you can do right now. What benefit would it be to remove it? Some like to get to certain parts of the scene using via the root, some prefer sub-contexts. If you talking about merging contexts like dops/sop/parts also the amount of nodes presented, you would need another layer of menus when you type tab. Maybe im just not understanding the real benefit of it. Im sure some pruning can be done to speed the workflow but it doesnt seem that tough to plop down a chopnet or dopnet from to switch between sop and chops or objs and rops etc. I would like to see more redundant nodes either be consolidated or removed. texture/textureMap, bind,import attr, get attr, parm just makes me wonder what is more efficient and why should i be using it. Quote Link to comment Share on other sites More sharing options...
Gyroscope Posted March 20, 2014 Share Posted March 20, 2014 (edited) I am beginning to detest in h13 every wrangle node I see... They are f-ing everywhere. If I wanted to code my software this much why use nodes? I wholeheartedly agree. Don't get me wrong, power to those who can but, I'm more of a generalist on the artist side rather than the programming side. When SideFX's tutorials went into wrangle nodes and VEX expressions, my eyes started to gloss over. I'm learning Python and general programing, implementing it as projects see fit but, slow going overall. I actually chose to learn Houdini after being disgruntled with Autodesks practices. No regrets there but from the recent talk on the official forums about Softimage, makes me wish I got to learn XSI and ICE, as it was touted as more artist friendly. Ironically started it all in Softimage|3D. Agree again with Node bloat and multiple languages. It's prime time to make Houdini more artist friendly and maybe shake off that TD Centric image a bit. Edited March 20, 2014 by Gyroscope Quote Link to comment Share on other sites More sharing options...
Guest tar Posted March 20, 2014 Share Posted March 20, 2014 Agree again with Node bloat and multiple languages. It's prime time to make Houdini more artist friendly and maybe shake off that TD Centric image a bit. No matter how good nodal programming gets it just never can be as efficient as texture coding. It's a pretty good mix right now. It may be tilting towards TD-ism with the wrangles currently but the speed gains are worth it, sure update the other nodes but give us speed first! Quote Link to comment Share on other sites More sharing options...
sebkaine Posted March 20, 2014 Share Posted March 20, 2014 (edited) I can understand your thinking but it is something that you can do right now. What benefit would it be to remove it? Some like to get to certain parts of the scene using via the root, some prefer sub-contexts. Honestly i have join the Houdini ship very lately (1.5 years) and i guess many houdini user that start houdini long time ago , love the various context , it's one of the first thing you learn in tutorials and it's a big part of the houdini ID. Your point is also very true if you want use them you can and vice versa ! But i would prefer to start from a blank page and build the tree of my scene as i want , i would like to have a total control on my scene tree, and how i want to build it. and thus start to create at root level / But i'm picky here and i guess not very convincing Edited March 20, 2014 by sebkaine 2 Quote Link to comment Share on other sites More sharing options...
Gyroscope Posted March 20, 2014 Share Posted March 20, 2014 (edited) No matter how good nodal programming gets it just never can be as efficient as texture coding. It's a pretty good mix right now. It may be tilting towards TD-ism with the wrangles currently but the speed gains are worth it, sure update the other nodes but give us speed first! No doubt, and I wouldn't want to get rid of the capabilities and gains. But do you agree with LaidlawFX's assessment of HScript, expression, VEX Expression, VEX, Python, HDK? I'd agree with him and sebkain if it was just Python and VEX. I have to do web work too and it's ridiculous language wise there too. Edited March 20, 2014 by Gyroscope Quote Link to comment Share on other sites More sharing options...
Guest tar Posted March 20, 2014 Share Posted March 20, 2014 No doubt, and I wouldn't want to get rid of the capabilities and gains. But do you agree with LaidlawFX's assessment of HScript, expression, VEX Expression, VEX, Python, HDK? I'd agree with him and sebkain if it was just Python and VEX. I have to do web work too and it's ridiculous language wise there too. Yup - but first I want an updated Color Picker Quote Link to comment Share on other sites More sharing options...
Alexey Vanzhula Posted March 20, 2014 Share Posted March 20, 2014 (edited) if it was just Python and VEX Hscript expressions a bit faster than python expressions. But Python more powerful Edited March 20, 2014 by Alexey Vanzhula Quote Link to comment Share on other sites More sharing options...
magneto Posted March 20, 2014 Share Posted March 20, 2014 In an ideal world, IMO it should be a standard language for scripting: Python, VEX as internal language, then HDK and managed HDK Quote Link to comment Share on other sites More sharing options...
Alexey Vanzhula Posted March 20, 2014 Share Posted March 20, 2014 AND WELL DOCUMENTED HDK Quote Link to comment Share on other sites More sharing options...
Guest tar Posted March 20, 2014 Share Posted March 20, 2014 AND WELL DOCUMENTED HDK Out of interest, is there any well documented SDK for any software? Almost every forum has someone complaining about a badly documented SDK for their software. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.