tjeeds Posted October 30, 2012 Share Posted October 30, 2012 Smarter auto-layout for VOP networks. As I am terribly lazy at organizing how I put out nodes i am a heavy user of the layout command. Unfortunately in VOPs it creates a bigger mess than I do. Have you tried this lately? I recently gave it a shot and it actually works great now. Might stick you global somewhere funny but otherwise it's totally working. Quote Link to comment Share on other sites More sharing options...
tjeeds Posted October 30, 2012 Share Posted October 30, 2012 Crazy Idea... Have a details style menu for groups. So when you have a long list you don't need to drop down a delete node or other node with a group listing option. If you right click on the node and choose 'Extended Information' it brings up a window which is exactly that. Quote Link to comment Share on other sites More sharing options...
LaidlawFX Posted November 2, 2012 Author Share Posted November 2, 2012 If you right click on the node and choose 'Extended Information' it brings up a window which is exactly that. Wicked... now just need that as a pane option along side details view to toggle back and forth between. Quote Link to comment Share on other sites More sharing options...
LaidlawFX Posted November 2, 2012 Author Share Posted November 2, 2012 Have you tried this lately? I recently gave it a shot and it actually works great now. Might stick you global somewhere funny but otherwise it's totally working. Close to every day. It's better for a very small shader but, when dealing with uber-studio size shaders it's still very unhelpful. It needs several more layers of logic in it. For instance in something the size on the surface model vop, it can't just array every parameter in a vertical order, somethign alogn the lines of a grid that is only as tall of the adjoining otl, but makes up for the vertical in depth. Or you can be creative and do a series of arrows. Also in a chain on node it limits the vertical height of the organization at certain level like a collumn newspaper. Additionally organizing output parameters, too like from a direct lighting vop that has like 9 output parameters. Quote Link to comment Share on other sites More sharing options...
symek Posted November 2, 2012 Share Posted November 2, 2012 (...) but, when dealing with uber-studio size shaders it's still very unhelpful. It needs several more layers of logic in it. Why not using code for a big shaders? It's a clean approach, easy to maintain and version control, great for keeping stuff organized and additionally fits well to Vops as a source of building block components. Isn't a code better suited for shaders development? Quote Link to comment Share on other sites More sharing options...
graham Posted November 2, 2012 Share Posted November 2, 2012 Why not using code for a big shaders? It's a clean approach, easy to maintain and version control, great for keeping stuff organized and additionally fits well to Vops as a source of building block components. Isn't a code better suited for shaders development? Unfortunately some people don't like/know how to code. We have some people here who build their shaders in VOPs and some who write them purely in VEX. Quote Link to comment Share on other sites More sharing options...
symek Posted November 4, 2012 Share Posted November 4, 2012 Does Sesi intend to reimplement voplib or physicalsss in vops any soon? I don't have an issues with Vops, except I prefer to use them when they fit, specially that I have that luxury being Houdini user, to switch to vex in cases things get messy. Perfect match for a "uber studio size" shaders as it was called. It's not a matter of the preference, it's a rationale. 1 Quote Link to comment Share on other sites More sharing options...
LaidlawFX Posted November 5, 2012 Author Share Posted November 5, 2012 Why not using code for a big shaders? It's a clean approach, easy to maintain and version control, great for keeping stuff organized and additionally fits well to Vops as a source of building block components. Isn't a code better suited for shaders development? Technical-ly/Houdini-wise it doesn't matter whether you work in vex or vops. I've worked on the proof in a big studio and in small shops. It can be just as clean, and organized. This may have not been the case 5yrs ago, and there are many thanks involved, to graham, to everyone at SESI, and many, many others. There is also plenty of room for improvement. VEX is vops, and vops is vex. You will allways need to hybridize some portions, as the heart of all software is code, but as a whole it is more of a beer side discussion for friendly egos... like politics... My bias, and my personal preference will allways be towards nodal workflow if given a choice, it's how I tick. I can look at a nodal network and it make sense like no other thing. I can update, organize, maintain, and bug fix my code extremely quickly, but it is a personal thing each persons brain tick different, some people like code, others like nodes. Quote Link to comment Share on other sites More sharing options...
csp Posted November 5, 2012 Share Posted November 5, 2012 (edited) What about true edge support? A minor request from me +1000 , I think its time! Edited November 6, 2012 by cparliaros 1 Quote Link to comment Share on other sites More sharing options...
symek Posted November 8, 2012 Share Posted November 8, 2012 (edited) @LaidlawFX: I haven't said anything against nodal workflow, just pointed out that the moment you feel unconformable with it, may be a moment to move to vex. Developing uber algorithm for laying down huge-endless-spaghetti vops is wasting of development time - I think. Vex doesn't even have a proper syntax coloring up to now, its GUI support is extremely lame, the same as support for layered shaders pipeline (which would involve full support for co-shaders in vex !and! vops I presume), not to mention vops support for arrays, structs, and a couple of missing vex functions. Also there is a lot to be done with wiring nodes with a mouse (precision, smart connections between, say, vector_to_float and matrix node). Fortunately for you SESI seems to share your ideas. Making Houdini more approachable requires developing alternatives to "technical" workflows. I suppose it's a fief paid to make Houdini survivor, but it doesn't make some choices more sensible. Of course Vops could be better, anything could, the discussion starts when one needs to prioritetize its tasks. Technical-ly/Houdini-wise it doesn't matter whether you work in vex or vops. I've worked on the proof in a big studio and in small shops. It can be just as clean, and organized. I don't think that's not true. Hence that discussion. It's cool to say that, specially paired with greetings to developers, I understand, but it's clearly not that simple. I'm not really sure if personal preference should an excuse for using the wrong tool for a job. In a big studio or not, doesn't matter. Edited November 8, 2012 by SYmek 2 Quote Link to comment Share on other sites More sharing options...
abvfx Posted November 8, 2012 Share Posted November 8, 2012 As an artist I would have to agree with Symek here. The more and more i delve deeper into vops the crazier it becomes, and most of the time its just simple task being executed. The one improvement i would like to see in VOP's is a visual isolation (some sort of dimming effect) when you Alt or Ctrl click a node etc. Just to see where is goes and what is connected to, but that could be applied to Houdini as a whole. But the more i get experienced in VOPs the greater i want to learn VEX just for the sheer speed and ease it would be to create and maintain large processes. So in my opinion i would be all for VEX getting a bit of a boost on the priority list. 1 Quote Link to comment Share on other sites More sharing options...
magneto Posted November 9, 2012 Share Posted November 9, 2012 I also use 99% VEX. Reading a large VOP network is so much slower for me than reading code, as I read code fast. I think the problem with reading VOP networks is that, it means not only backtracking everything but also "cache" those in your memory so you know what the whole network does, which is pretty difficult IMO. I am talking about 50+ VOPs. Quote Link to comment Share on other sites More sharing options...
abvfx Posted November 9, 2012 Share Posted November 9, 2012 Yeah ive been ripping the mantra surface material apart recently and re-working a lot of sections and i have noticed a considerable performance hit in just connect/reconnecting things (maybe i broke something im not sure). And right now sitting in a bunch of noodles, VEX looks so appealing. But dont get me wrong VOP's certainly is super useful. 1 Quote Link to comment Share on other sites More sharing options...
magneto Posted November 9, 2012 Share Posted November 9, 2012 (edited) Also I agree with Symek's suggestions of improving VEX development. The syntax highlighting does not exist for VEX SOPs, only Inline VEX VOP from what I have seen. The syntax coloring is also not complete. For example "int" type is not highlighted like other types. More editorial features would also be a huge workflow boost all across the board. Actually SESI should just hire Symek. I trust his judgement 100%. Then I wouldn't have to worry about these details as he would have already taken care of them Edited November 9, 2012 by magneto Quote Link to comment Share on other sites More sharing options...
LaidlawFX Posted November 10, 2012 Author Share Posted November 10, 2012 My apologies Symex, didn't mean to stir you up. For discussion sake, it would be cool alongside the vex and vop road if one could work with vex and vops alongside each other in separate panes from within a Houdini session, updating either if you wish and they be linked, like a better version of dreamweaver or a certain C compiler my brain is farting on now. So no outside code management software is needed, that way vops and nodes would have to be linked in almost all parts, structs, etc. Also if vex coding were in a pane you could have sesi support and design on code layout and highlight support on both sides linked. That would require some heavy work on their end albeit. @ phrenzy48, The mantra surface material stinks, decent learning tool, but you need to start from scratch with the code for vops to create useful sub tools. As for the vops running longer, if you do not save cached code, mantra needs to compile prior to rendering, if the temp directory .vfl has changed, so this is a usual hit for slowness. Once the nodes are compiled mantra has pretty efficient optimization code for all shaders. So there is probably something cross wired to give you a longer render. For instance, when you use if blocks that dead end into constant nodes, mantra will optimize out these code blocks not being used, like reflection, refraction, diffuse, etc... Quote Link to comment Share on other sites More sharing options...
Hello world Posted November 10, 2012 Share Posted November 10, 2012 paint sop with different brush styles 1 Quote Link to comment Share on other sites More sharing options...
symek Posted November 12, 2012 Share Posted November 12, 2012 My apologies Symex, didn't mean to stir you up. O boy, my turn, sorry for being edgy! My point was just to remind that we already have a tools for resolving complexity, that is vex and vex generated vops. They may not be one's favorite, but they are there, and took considerably amount of time to develop, giving Houdini's users great advantage over pure node-based shader authoring tool sets. Quote Link to comment Share on other sites More sharing options...
magneto Posted November 12, 2012 Share Posted November 12, 2012 What about having the ability to define custom paint SOPs? Is that possible? To be able to mimic some of the sculpting brushes available in mudbox, etc. Quote Link to comment Share on other sites More sharing options...
ethervoid Posted November 13, 2012 Share Posted November 13, 2012 From a short usage experience, maybe the possiblity of customizing/switch the space key with alt, navigation-wise and the whole E,R,T model to the classic Q,W,E,R , all with simple toggle buttons in the options menu so new users dont have headaches working with multiple programs at the same time? Quote Link to comment Share on other sites More sharing options...
LaidlawFX Posted November 21, 2012 Author Share Posted November 21, 2012 GPU based chops... 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.